HTTP
主要項目Persistence
Compression（英語版）
HTTPS
HTTP/2
ヘッダーフィールド（英語版）Cookie
ETag
Location（英語版）
Referer
DNT（英語版）
X-Forwarded-For
ステータスコード301 Moved Permanently（英語版）
302 Found（英語版）
303 See Other（英語版）
403 Forbidden
404 Not Found
503 Service Unavailable


表

話

編

歴

HTTP cookie（エイチティーティーピークッキー、単にクッキーとも表記される）は、RFC 6265などで定義されたHTTPにおけるウェブサーバとウェブブラウザ間で状態を管理するプロトコル、またそこで用いられるウェブブラウザに保存された情報のことを指す。ユーザ識別やセッション管理を実現する目的などに利用される。

目次

1 概要

2 仕様間の違い

3 用途

3.1 例

3.2 例：MediaWikiにおけるログイン情報


4 クライアント側スクリプトによるクッキーの操作

5 ブラウザの環境設定によるクッキーの操作

6 クッキーの適用範囲と有効期限

7 セキュリティ、プライバシーの問題

7.1 セッションハイジャック

7.2 トラッキング・クッキー


8 類似のトラッキング技術

9 脚注

10 関連項目

11 外部リンク

概要

HTTPは元来ハイパーテキストにおいて単にファイル転送を行うために開発されたため、同じURLへのアクセスならその状況によらず同一の資源[1]を提供することが前提となっている。動的なコンテンツ生成の仕組みとしてフォームが導入されているが、これは要求に直接対応する応答だけに影響をおよぼす。言い換えるとHTTPでは、同じ瞬間に同じ内容の要求を行っていれば、そのクライアントが以前にどのような通信を行っていても区別されない。HTTPはその意味で現在においてもステートレスなプロトコルである。

その一方でWorld Wide Webが普及するにつれ、状況によって異なる内容のページを提供したい[2]というニーズが生まれた。そのようなニーズをHTTPのみで満たすには、IPアドレスによって区別する、状態を表現したユニークなURLを生成するなどの方法がある。しかし、プライベートネットワークからのアクセスを区別できない、本来二度起きない状態が同じURLにアクセスすることで何度も発生する、セキュリティの問題などいずれも容易に解決できない欠点を抱えていた。

そこで、1994年にネットスケープコミュニケーションズ社によってクッキー[3] が提案・実装された。クッキーでは次のようにサーバとクライアント間の状態を管理する。
ウェブサーバがウェブブラウザにその状態を区別する識別子をHTTPヘッダに含める形で渡す。

ブラウザは次にそのサーバと通信する際に、与えられた識別子をHTTPヘッダに含めて送信する。

サーバはその識別子を元にコンテンツの内容をユーザに合わせてカスタマイズし、ブラウザに渡す。必要があれば新たな識別子もHTTPヘッダに含める。
以降2、3の繰り返し。

この仕組みによって、ステートレスなプロトコルであるHTTP上でステートフルなサービスを実現する。ここで注意すべき点は、一度設定されたクッキーは、条件を満たす限り何度でも要求に組み込まれるという点である。HTMLページの要求だけでなく、画像を含むすべての要求が対象となる。

その後クッキーは1997年にRFC 2109で初めて標準化され、2000年のRFC 2965、2011年のRFC 6265で更新された。2007年現在ほとんどのウェブサーバ、ウェブブラウザで利用可能である。
仕様間の違い

前述の通り、HTTP Cookie には幾つか仕様があるが、IETFの標準化したRFC 2109やRFC 2965は、ネットスケープ仕様とExpires属性からMax-Age属性への変更等互換性がないため、実際のウェブサイトではほとんど使われていない[4]。一方で、Expires属性等で用いられる日付形式は仕様外の記述が氾濫しているうえ[5]、セキュリティ上の理由からhttponly属性やsecure属性等が事実上追加されており、長らく文書の存在しない状態が続いていたが、RFC 6265 はこれらの問題を解消することを意図して制定されている。
用途

クッキーの最も代表的な用途は、ショッピングサイトにおけるカートやログイン状態の管理である。また、IPアドレスによらないクライアントの識別を可能にするため、ウェブサイト運営者やインターネット広告配信業者などがユーザの詳細なアクセス履歴を取得する用途にも使われる。

クッキーは毎回送られるものであり、またHTTPヘッダの一部なのでASCII文字列になっている必要がある。そのためクッキーでデータを直接扱うよりも、セッションIDを実装する手段として使うことが多い。この場合、実際のデータは、セッションIDをキーとしてサーバが保持することになる。
例

例えば特定のページの表示回数を、ウェブページ上に表示したいときには、おおむね次のようなやりとりが行われる。
ブラウザがサーバに閲覧を要求する。ここにはクッキーの情報はない。

サーバはブラウザに対し「1」回目というクッキー情報と、「1回目」と表示するようなデータを送信する。

ブラウザがサーバに閲覧を要求する。このときブラウザは、そのサーバから受け取ったクッキーを探して、「1」のクッキー情報をサーバに送信する。

サーバは「1」というクッキー情報に基づき、ブラウザに対し「2」回目というクッキー情報と、「2回目」と表示するようなデータを送信する。

例：MediaWikiにおけるログイン情報

例として、MediaWikiにおけるクッキーの使用をあげる。

MediaWikiソフトウェアでは、ログイン情報をクッキーで実現している。その方法はおおむね次のようである。
ログインページからユーザ名とパスワードをサーバに送信する。この時点でクッキーは使われていない。

サーバは、ユーザ名とパスワードを確認し、ユーザーにカスタマイズされた「ログイン成功」のページを送信するとともに、ユーザー名とパスワードを（そのままではないが）クッキーとして送信する。

次の閲覧からはブラウザがページ閲覧要求とともに先のクッキーを送信する。サーバはクッキー情報によってユーザにカスタマイズされたページを送信する。

ログアウトをクリックすると、「ログアウト」のページとともに、空のクッキー情報を送信する。ブラウザは、先のクッキー情報を空のクッキー情報で上書きする。これにより最初のクッキー情報は消去される。

クライアント側スクリプトによるクッキーの操作

クッキーは、HTML DOMの一部としてアクセスできる。JavaScriptをはじめとする、クライアント側のスクリプトは、クッキーを操作することができる。ただし後述のようにクッキーには有効範囲が設定されており、そのURLにおいて有効なクッキーだけがアクセス対象となる。
ブラウザの環境設定によるクッキーの操作

現在使われているウェブブラウザのほとんどはクッキーの送受信が可能であり、初期状態でクッキーを送受信する設定になっている。しかし、クッキーの送受信をするしない、またそのクッキーの内容は、ウェブ閲覧者の自由に置かれるべきものであるので、ブラウザの初期設定でそれらを操作できるようになっている。すなわち、クッキーの送受信を停止する、クッキーの内容を確認する、クッキーを消去するといった機能がウェブブラウザに備わっている。
クッキーの適用範囲と有効期限

クッキーを設定する際、どの要求に対してクッキー情報を送り返すのか、URLの範囲を指定する。規定値は、クッキーを設定したサーバに対するすべての要求であり、対象を広げることも狭めることもできる。ただし広げる場合でも、トップレベルドメインより狭い範囲でなければならない。

またクッキーの有効期限は、通常はブラウザを終了するまでだが、指定した期限まではブラウザを再度起動しても保持されるように設定することができる。有効期限の情報も、サーバからブラウザにクッキー情報を送信する段階で付加される。 無期限という設定は出来ない。遥か未来を指定することで半永久的に有効にすることも可能だが、ブラウザやサーバが2038年問題で不具合を起こす場合があることから[6]、2038年1月19日3時14分07秒(UTC)以降の時間を期限とすることはあまりない。