HTTP Cookieは、Webサーバがクライアント側に小さなテキストデータを保存させ、以降のリクエストに自動的に添付させることで「状態」を維持する仕組みです。1994年にNetscape Communications社のLou Montulli氏が考案し、ショッピングカートの維持を目的に実装されました。その後IETFで標準化が進み、最新仕様はRFC 6265（2011年）として定められています。サーバはレスポンスでSet-Cookieヘッダを送り、ブラウザはそれを保存して以降のリクエストにCookieヘッダで送り返します。セッション管理・ログイン状態・カート保持・トラッキングなど、現代Webのほぼすべての状態管理の土台として動き続けている要素です。
この記事の目次
- Set-Cookieとリクエスト時の返送
- 1994年Montulli発案からRFC 6265まで
- 実用シナリオと典型的な使い分け
- LocalStorage・JWT・サーバセッションとの比較
- まとめ
Set-Cookieとリクエスト時の返送
Cookieの仕組みは、サーバとブラウザの2者の役割分担で動きます。サーバはHTTPレスポンスにSet-Cookie: session=abc123; Path=/; Secure; HttpOnlyのようなヘッダを含めて送信し、ブラウザはこれを受け取って自身のCookieストアに保存します。次回以降、同じドメインにリクエストする際、ブラウザは自動的にCookie: session=abc123の形でCookieヘッダを付与し、サーバは値を読み取って「このリクエストは先ほどログインしたユーザーのもの」と判定できる仕組みです。
Cookieには名前・値のペアに加え、ExpiresまたはMax-Age（有効期限）、Domain（送信対象ドメイン）、Path（送信対象パス）、Secure（HTTPSのみ送信）、HttpOnly（JavaScriptからの読取禁止）、SameSite（クロスサイト送信制御）といった属性が付けられます。RFC 6265ではCookieは最大4096バイト、1ドメインあたり50件、合計3000件程度というブラウザ実装の実用的な上限が示されています。ブラウザの開発者ツールのApplication / Storageタブで保存中のCookie一覧を確認でき、デバッグや挙動確認の現場でも頻繁に参照されます。
1994年Montulli発案からRFC 6265まで
Cookieはネット黎明期の1994年、Netscape Navigator 0.9beta開発中にエンジニアのLou Montulli氏が、MCI社のショッピングサイト試作で「カート情報をサーバに保持しすぎるのを避けたい」という要望に応える形で考案しました。当初は仕様書ではなくNetscapeのプレリリースノートに記載される非公式仕様でしたが、ブラウザ標準として急速に広まり、HTTPの実質的な拡張機能になりました。
1997年にIETFがRFC 2109としてCookieを公式に標準化しましたが、実装と齟齬がある部分が多く、2000年のRFC 2965でも完全な置換には至らずに併存する状態が続きました。現実のブラウザの挙動を改めて文書化したのが2011年4月発行のRFC 6265で、現在のCookieの基準仕様です。その後はSameSite属性をはじめとするセキュリティ強化が中心の議論となり、2024年現在はRFC 6265bisとして改訂作業が進められています。30年以上にわたって基本構造を保ち続けつつ、安全性に関する属性が継続的に追加されてきた歴史を持ちます。
実用シナリオと典型的な使い分け
Cookieの最も典型的な用途はログインセッションIDの保持で、サーバ側のセッションストア（Redis等）の鍵をCookieに入れて運ぶ「セッションCookie」と呼ばれるパターンが定石です。HttpOnly属性を付けてJavaScriptから読めなくし、Secure属性でHTTPSのみに限定し、SameSite=LaxやStrictでCSRF耐性を高める運用がベストプラクティスとして定着しています。ショッピングカートのアイテム一覧をログイン前から維持する用途や、ダークモードや言語設定などサイト固有の好みをサーバ越しに記憶する用途にも使われます。
A/Bテストツールはユーザーを「Aパターン群」と「Bパターン群」に振り分けた結果をCookieに書き込み、リロード後も同じ体験を提供します。Google AnalyticsやMeta Pixelのような解析・広告系ツールでは、ユーザー識別用のID（_gaなど）を1〜2年の有効期限でCookieに保存し、行動ログを横断的にひも付ける用途で使われてきました。ただし2020年代に入りChromeのサードパーティCookie廃止議論や各国の個人情報保護法強化を受けて、トラッキングCookieの使い方は大きく見直されつつある領域です。
LocalStorage・JWT・サーバセッションとの比較
LocalStorageはCookieと違ってブラウザ側に5〜10MB保存でき、JavaScriptで明示的に読み書きします。リクエストへ自動で乗らないためHTTP通信量が増えない反面、JavaScriptからアクセスできることでXSS（クロスサイトスクリプティング）攻撃時にトークンを抜かれるリスクが高くなります。セッションIDのような機微な値はLocalStorageではなくHttpOnly Cookieに置く方が、現代のセキュリティ常識に沿った設計です。
JWTはCookieとは独立した概念で、トークン形式の話です。JWTをCookieに入れて運ぶ方法と、AuthorizationヘッダにBearerで載せる方法があり、それぞれ得手不得手があります。サーバ側にセッションストアを持つ古典的なセッション管理は、Cookieにセッションキーだけ載せて中身はサーバ側DBに置く構成で、ログアウト時の即時無効化が容易な反面、スケール時の同期コストがあります。IndexedDBは大容量データの永続化向けで、Cookieの守備範囲とは異なります。現代の認証設計ではこれらの組み合わせを使い分けるのが定石となっています。
まとめ
HTTP CookieはLou Montulli氏が1994年に考案し、現在はRFC 6265（2011年）で標準化されたWebの状態管理基盤です。Set-Cookieによる発行とCookieヘッダによる自動送信、Domain/Path/Secure/HttpOnly/SameSiteといった属性で、セッション・好み・トラッキングまで幅広く扱います。LocalStorageやJWTと棲み分けながら、HttpOnly+Secure+SameSiteの組み合わせを軸に、現代Web認証の中核として長く使われ続けている仕組みです。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント