Cookie

概要

Cookieは、サーバがブラウザに預ける小さなデータ（キーと値の組）です。サーバがレスポンスで「これを保存しておいて」と渡すと、ブラウザはそれを保存し、以後同じサイトへのリクエストに毎回自動で添えて送り返します。一度ログインすればページを移動してもログイン状態が続くのは、この仕組みのおかげです。

HTTP は本来、一回のリクエストとレスポンスで完結し、サーバは前回の相手を覚えていません（ステートレス）。Cookieはこの性質を変えずに、「覚えておくべきことをクライアント側に持たせ、毎回提示してもらう」ことで状態を実現します。ログイン状態の維持、セッションの識別、ユーザー設定の保存、そしてアクセス解析や広告のトラッキング——Webの「あなたを覚えている」体験のほとんどの裏にCookieがいます。

なぜ生まれたか

1994年、Netscape社のエンジニアだったルー・モントゥリは、ECサイトの「買い物かご」を実装するという課題に直面していました。ステートレスなHTTPでは、商品をかごに入れた人と、次のページを開いた人が同一人物だとサーバには分かりません。全ユーザーの状態をサーバ側で持ち続けるのは当時の計算資源では負担が大きく、かといってURLに識別子を埋め込む方法は共有やブックマークで破綻します。

そこで考案されたのが、「サーバが渡した小さなデータを、ブラウザが同じサイトへのリクエストに自動で付け返す」という仕組みでした。名前は、プログラム間で受け渡す小さなデータを指す既存の用語「magic cookie」に由来します。HTTPのステートレス性を壊さずに継続的な対話を可能にしたこの発明は、ログインもECも成立させた一方、サイトを横断してユーザーを追跡する手段にもなり、後年のプライバシー議論の火種にもなりました。

詳細

Set-Cookie と Cookie ヘッダの往復

仕組みの正体は、たった2つのHTTPヘッダです。サーバはレスポンスに Set-Cookie: session_id=abc123 を付けて保存を指示し、ブラウザは以後のリクエストに Cookie: session_id=abc123 を自動で付けます。

重要なのは「ブラウザが自動で送る」という点です。開発者がコードを書かなくても、条件を満たすリクエストにはCookieが付いて飛んでいきます。この自動性こそがCookieの便利さの源泉であり、同時に後述する CSRF のようなセキュリティ問題の根源でもあります。

セッションCookieという代表的な使い方

もっとも典型的な用途がセッション管理です。ログイン成功時にサーバが推測不能なランダムなセッションIDを発行してCookieで渡し、サーバ側でそのIDとユーザー情報を紐付けて保管します。以後はCookieのIDを見るだけで「誰のリクエストか」が分かる。Cookie自体にはIDしか入っておらず、実体はサーバ側にあるのがポイントです。対照的に、JWT のように署名付きのデータそのものをCookieに入れて、サーバ側に状態を持たない方式もあります。認証後の状態をどちらの方式で保つかは、Webアプリ設計の定番の分かれ道です。

スコープと寿命を決める属性

Set-Cookie には、Cookieの効く範囲と寿命を制御する属性を付けられます。Domain と Path は「どのリクエストに添付するか」の範囲を決め、Expires / Max-Age は有効期限を決めます（指定がなければブラウザを閉じると消える「セッションCookie」になります）。範囲は必要最小限に、寿命は用途に応じて——が原則です。

セキュリティ属性——攻撃の歴史への回答

残りの属性は、Cookieが攻撃の標的になってきた歴史そのものです。Secure を付けると HTTPS の通信でしか送信されなくなり、平文の通信路での盗聴を防ぎます。HttpOnly を付けると JavaScript の document.cookie から読めなくなり、XSS が成立してもセッションIDの窃取までは許しません。そして SameSite は、他サイト発のリクエストにCookieを添付するかを制御する属性で、「ブラウザが自動で送る」性質を悪用する CSRF への対策として導入されました。現在の主要ブラウザは SameSite=Lax をデフォルトにしています。セッションIDを運ぶCookieには Secure; HttpOnly; SameSite=Lax（またはStrict）を揃えるのが今日の基本形です。

サードパーティCookieとプライバシー

表示中のサイトと異なるドメインに送られるCookieを「サードパーティCookie」と呼びます。複数のサイトに同じ広告配信ドメインのタグが埋まっていると、そのドメインのCookieを軸にサイト横断でユーザーの行動を追跡できてしまう——これが長年ターゲティング広告を支えてきた仕組みです。GDPRや改正個人情報保護法などの規制で「Cookie同意バナー」が一般化し、Safari や Firefox はサードパーティCookieを既定でブロック、Chrome も制限を進めるなど、この用途のCookieは終わりに向かっています。「状態維持のためのファーストパーティCookie」と「追跡のためのサードパーティCookie」は、同じ技術のまったく別の顔だと区別して理解しておきましょう。

実務での落とし穴

Cookieには1つあたり約4KBというサイズ上限があり、しかも対象ドメインへの全リクエストに毎回載って往復します。大きなデータを詰め込むと通信を無駄に太らせるので、単なるクライアント側の保存が目的なら localStorage などの Web Storage が適します（ただし Web Storage には HttpOnly がなく XSS に弱いため、認証情報の置き場としては Cookie に分があります）。ほかにも、Domain を広く取りすぎてサブドメイン全体にCookieが漏れる、有効期限を長くしすぎてセッションハイジャックの窓を広げる、といった設定ミスが定番です。「何を・どの範囲に・いつまで持たせるか」を意識して設計することが、Cookieを安全に使う鍵になります。