HTTP cookie（エイチティーティーピークッキー）は、ユーザがウェブサイトをブラウジングしている間にウェブサーバによって作成され、ユーザのウェブブラウザによってユーザのコンピュータやその他のデバイスに保存されるマジッククッキー（小さなデータのブロック）である。単にクッキー（cookie）、あるいはウェブクッキー、ブラウザクッキーとも表記される。HTTP cookieは、などで定義されており、ステートレスなHTTPプロトコルにおいて、ウェブサーバとウェブブラウザ間でログイン状態などを管理するための仕組み、およびその情報のことを指す。
概要 HTTPは元来ハイパーテキストにおいて単にファイル転送を行うために開発された。そのため、同じURLへのアクセスならその状況によらず同一の情報源を提供すること、つまり「ステートレスなプロトコル」が前提となっている。例えば、動的なコンテンツ生成の仕組みとしてフォームが導入されているが、これは要求に直接対応する応答だけに影響をおよぼす。言い換えると同じ瞬間に同じ内容の要求を行っていれば、そのクライアントが以前にどのような通信を行っていても区別されない。HTTPはその意味で現在においてもステートレスなプロトコルである。
一方、World Wide Webが普及するにつれ、「ユーザーのログイン状態を維持したい」「オンラインストアのショッピングカートに追加された商品などの情報を保存したい」など、状況によって異なる内容のページを提供したいというニーズが生まれた。IPアドレスによる識別や、URLにその状態を表現しするなどの方法があるが、プライバシーやセキュリティの観点から容易に解決できない欠点を抱えていた。
そこで、1994年にネットスケープコミュニケーションズ社によってクッキー が提案・実装された。クッキーでは次のようにサーバとクライアント間の状態を管理する。 ウェブサーバがウェブブラウザにその状態を区別する識別子をHTTPヘッダに含める形で渡す。 ブラウザは次にそのサーバと通信する際に、与えられた識別子をHTTPヘッダに含めて送信する。 サーバはその識別子を元にコンテンツの内容をユーザに合わせてカスタマイズし、ブラウザに渡す。必要があれば新たな識別子もHTTPヘッダに含める。 以降2、3の繰り返し。 この仕組みによって、ステートレスなプロトコルであるHTTP上でステートフルなサービスを実現する。ここで注意すべき点は、一度設定されたクッキーは、条件を満たす限り何度でも要求に組み込まれるという点である。この仕組みによって、ショッピングカートの維持、ログイン認証、ユーザー設定の保存、さらには行動トラッキングといったウェブ上で不可欠な機能が実現されている。
構造 クッキーは以下のコンポーネントで構成される。
Name - クッキーの名前 Value - クッキーに保存されている値（データ） Domain - このクッキーが有効なドメイン Path - このクッキーが有効なパス（「/」ならサイト全体） Expires / Max-Age - クッキーの有効期限。セッション終了時に消えるものは「Session」と表示されます Size - クッキーのサイズ（バイト） HttpOnly - チェックが入っている場合に、JavaScript（document.クッキーなど）からのアクセスを禁止し、クロスサイトスクリプティング攻撃による盗難を防いでいる状態 Secure - チェックが入っている場合に、HTTPS（暗号化通信）のときのみサーバーに送信される状態 SameSite - 外部サイトからの遷移時にクッキーを送信するかどうか（Strict / Lax / None） Partition Key - CHIPS（正当なサードパーティクッキー）として分割されている場合のキー
名前の由来 「クッキー」という言葉は、ウェブブラウザのプログラマであるルー・モントゥリによって作られた。これは、UNIXプログラマが使用する、プログラムが受信して変更せずに送り返すデータのパケットである「マジッククッキー」という言葉に由来している。
クッキーの用途
クッキーの送受信 クッキーは毎回送られるものであり、またHTTPヘッダの一部なのでASCII文字列になっている必要がある。そのためクッキーでデータを直接扱うよりも、セッションIDを実装する手段として使うことが多い。この場合、実際のデータは、セッションIDをキーとしてサーバが保持することになる。
例：特定のページの表示回数をウェブページ上に表示したいとき 例えば特定のページの表示回数を、ウェブページ上に表示したいときには、おおむね次のようなやりとりが行われる。
ブラウザがサーバに閲覧を要求する。ここにはクッキーの情報はない。 サーバはブラウザに対し「1」回目というクッキー情報と、「1回目」と表示するようなデータを送信する。 ブラウザがサーバに閲覧を要求する。このときブラウザは、そのサーバから受け取ったクッキーを探して、「1」のクッキー情報をサーバに送信する。 サーバは「1」というクッキー情報に基づき、ブラウザに対し「2」回目というクッキー情報と、「2回目」と表示するようなデータを送信する。
セッション管理 クッキーの最も代表的な用途は、ショッピングサイトにおけるカートやログイン状態の管理などに見られる「セッション管理」である。今日ではショッピングカートの中身は、クライアント側のクッキーではなくサーバ上のデータベースに保存されることが多い。クッキーには「どのユーザーが、どのカートに紐づいているか」を示すセッションIDだけを記録し、実際のデータはサーバ側で管理するという方法が広く使われている。
例：MediaWikiにおけるログイン情報 例として、MediaWikiにおけるクッキーの使用をあげる。
MediaWikiソフトウェアでは、ログイン情報をクッキーで実現している。その方法はおおむね次のようである。
ログインページからユーザ名とパスワードをサーバに送信する。この時点でクッキーは使われていない。 サーバは、ユーザ名とパスワードを確認し、ユーザーにカスタマイズされた「ログイン成功」のページを送信するとともに、ユーザー名とパスワードを（そのままではないが）クッキーとして送信する。 次の閲覧からはブラウザがページ閲覧要求とともに先のクッキーを送信する。サーバはクッキー情報によってユーザにカスタマイズされたページを送信する。 ログアウトをクリックすると、「ログアウト」のページとともに、空のクッキー情報を送信する。ブラウザは、先のクッキー情報を空のクッキー情報で上書きする。これにより最初のクッキー情報は消去される。
トラッキング ウェブサイトの運営者やインターネット広告配信業者が、ユーザーの詳細なアクセス履歴を取得・追跡するためにクッキーを使用することがある。これにより収集されたデータは、販売やターゲティング広告に利用されることがある。また、ウェブサイト運営者やインターネット広告配信業者などがIPアドレスによらないクライアントの識別を可能にするために用いることがある。ただし、ユーザーが意図しない場所で行動が記録されるため、プライバシー侵害の懸念が強く、近年では世界中で法的な規制が進んでいる。
パーソナライゼーション クッキーはユーザの好みに基づいてパーソナライズするためにも使用される。ユーザーが選択した「ダークモード表示」「言語設定」「1ページあたりの表示件数」などの設定値がクッキーにエンコードされ、ブラウザに保存される。次にサイトを訪れた際にも、サーバがそのクッキーを読み取ることで、最初からユーザー好みのレイアウトでページを表示することができる。
適用範囲と有効期限 クッキーを設定する際、どの要求に対してクッキー情報を送り返すのか、URLの範囲を指定する。規定値は、クッキーを設定したサーバに対するすべての要求であり、対象を広げることも狭めることもできる。ただし広げる場合でも、トップレベルドメインより狭い範囲でなければならない。
またクッキーの有効期限は、通常はブラウザを終了するまでだが、指定した期限まではブラウザを再度起動しても保持されるように設定することができる。有効期限の情報も、サーバからブラウザにクッキー情報を送信する段階で付加され、無期限という設定は出来ない。遥か未来を指定することで半永久的に有効にすることも可能だが、ブラウザやサーバが2038年問題で不具合を起こす場合があることから、2038年1月19日3時14分07秒(UTC)以降の時間を期限とすることはあまりない。
クッキーの種類
セッションクッキー セッションクッキー（インメモリクッキー、一時クッキー、非永続的クッキーとも呼ばれる）は、ユーザがウェブサイトをナビゲートしている間のみ一時メモリに存在する。 セッションクッキーは、ユーザがウェブブラウザを閉じたときに期限切れになるか削除される。セッションクッキーは、有効期限が割り当てられていないことによってブラウザに識別される。
永続的クッキー 永続的クッキーは、特定の日付または特定の期間の後に期限切れになる。作成者によって設定された永続的クッキーの寿命の間、ユーザがそのクッキーが属するウェブサイトにアクセスするたびに、または別のウェブサイトからそのウェブサイトに属するリソース（広告など）を表示するたびに、その情報はサーバに送信される。
このため、永続的クッキーはトラッキングクッキーと呼ばれることもある。これは、広告主が長期間にわたってユーザのウェブブラウジングの習慣に関する情報を記録するために使用できるためである。永続的クッキーは、ユーザをウェブサイト上のアカウントにログインさせたままにし、訪問のたびにログイン認証情報を再入力しなくて済むようにするためにも使用される。
セキュアクッキー セキュアクッキーは、暗号化された接続（すなわちHTTPS）を介してのみ送信できる。暗号化されていない接続（すなわちHTTP）を介して送信することはできない。これにより、盗聴によるクッキーの盗難に対してより安全になる。クッキーに `Secure` フラグを追加することで安全に設定できる。
HttpOnlyクッキー HttpOnlyクッキーは、JavaScriptなどのクライアント側APIからはアクセスできない。この制限により、クロスサイトスクリプティング（XSS）によるクッキー盗難の脅威が排除される。ただし、クッキーはクロスサイトトレーシング（XST）およびクロスサイトリクエストフォージェリ（CSRF）攻撃に対しては依然として脆弱である。クッキーに `HttpOnly` フラグを追加することで設定できる。
SameSiteクッキー 2016年にGoogle Chromeバージョン51は、`Strict`、`Lax`、または `None` の可能な値を持つ属性 `SameSite` を持つ新しい種類のクッキーを導入した。属性 `SameSite=Strict` の場合、ブラウザはオリジンドメインと同じターゲットドメインにのみクッキーを送信する。これにより、クロスサイトリクエストフォージェリ（CSRF）攻撃を効果的に軽減できる。`SameSite=Lax` の場合、ターゲットドメインがオリジンドメインと異なる場合でもクッキーをリクエストとともに送信するが、GETなどの安全なリクエストのみであり、サードパーティークッキーとしては送信されない。`SameSite=None` の場合はサードパーティー（クロスサイト）クッキーを許可するが、多くのブラウザでは `SameSite=None` のクッキーにSecure属性を要求する。
スーパークッキー スーパークッキーとは、トップレベルドメイン（`.com` など）またはパブリックサフィックス（`.co.uk` など）をオリジンとするクッキーである。対照的に、通常のクッキーは `example.com` などの特定のドメイン名をオリジンとする。 パブリックサフィックスリストは、スーパークッキーがもたらすリスクを軽減するのに役立つ。スーパークッキーという用語は、HTTPクッキーに依存しないトラッキング技術にも使用される。
ゾンビクッキー ゾンビクッキーとは、ウェブサーバによって訪問者のコンピュータ等の隠し場所に配置され、元のクッキーが削除された後に自動的にHTTPクッキーとして再作成されるデータとコードのことである。
クッキーの制御と操作
クライアント側スクリプトによるクッキーの操作 クッキーは、HTML DOMの一部としてアクセスできる。JavaScriptをはじめとする、クライアント側のスクリプトは、クッキーを操作することができる。ただし後述のようにクッキーには有効範囲が設定されており、そのURLにおいて有効なクッキーだけがアクセス対象となる。
ブラウザの環境設定によるクッキーの操作 現在使われているウェブブラウザのほとんどはクッキーの送受信が可能であり、初期状態でクッキーを送受信する設定になっている。しかし、クッキーの送受信をするしない、またそのクッキーの内容は、ウェブ閲覧者の自由に置かれるべきものであるので、ブラウザの初期設定でそれらを操作できるようになっている。すなわち、クッキーの送受信を停止する、クッキーの内容を確認する、クッキーを消去するといった機能がウェブブラウザに備わっている。
セキュリティの問題 クッキーを運用する際、クロスサイトスクリプティングやセッションハイジャックのセキュリティ上のリスクが存在する。Webサイトの管理者は、推奨されている対策を行うことが重要である。
クロスサイトスクリプティングによる窃盗 クッキー情報を不正に得る手段としてクロスサイトスクリプティングが挙げられる。クッキーには有効範囲が設定されているが、その有効範囲内にクロスサイトスクリプティング脆弱性を持つページがある場合、JavaScript等を併用して、他のサーバにクッキー情報を（URLの一部に組み込むなどして）送信させることが可能になる。対策としては、クッキーに HttpOnly 属性を付与し、JavaScriptからのアクセスを完全に遮断する方法がある。
通信の傍聴によるセッションハイジャック
クッキーでセッション管理を行う場合、もし第三者がセッションIDを知ることができれば、そのIDを名乗ることで本来のユーザになりすますことができる。このような「なりすまし」行為をセッションハイジャックと呼ぶ。
例として、以下のような通信を行うシステムがあるとする。 トップページでユーザIDとパスワードの入力を求める。 認証に成功するとサーバはセッションIDを割り当て、クッキーとしてクライアントに通知する。 クライアントは以降の要求にクッキーとしてセッションIDを付加する。サーバは対応するセッション情報にアクセスし、どのユーザであるか識別する。 もし第三者が盗聴や中間者攻撃によりセッションIDを知ることができれば、そのセッションが有効な間だけとはいえ、1～2を飛ばして3から開始することができる。すなわち、パスワードを知らなくても「なりすまし」が可能となる。
第三者のクッキー情報を知る方法のひとつは盗聴である。盗聴を防ぐ対策として、Webサイト全体をHTTPS（常時SSL化）にし、クッキーに Secure 属性を付与することで、暗号化通信のときだけクッキーを送信するように制限する方法がある。
クロスサイトリクエストフォージェリ
ユーザーがログインした状態で、悪意のあるリクエストを送信させるためのWebサイトにアクセスさせることで、本人の意図しない操作（送金など）をさせる攻撃である。属性をStrictやLaxに設定することで、意図しない別サイトからのリクエストによるセッションの悪用を防ぐ。
セッションフィクセーション
攻撃者が事前に用意したクッキー内のセッションIDを強制的に利用者に使わせることで、ログイン後のアカウントを乗っ取る攻撃である。クッキー内のセッションIDをリクエストごとに新しいものを生成することで、対策することができる。
サードパーティクッキー
サードパーティクッキー（トラッキング・クッキー） クッキーは本来、ショッピングカートの維持などウェブサイトを便利にするための技術だが、ユーザーの行動を追跡（トラッキング）するためにも悪用・活用される。この手法は、アドネットワーク（Google AdSenseなど）を利用するウェブ広告業者によってよく用いられている。
インターネット広告の配信において、バナー広告は、業者のサーバ（サードパーティー）へのリンクを介して画像を取得する形式が一般的である。クッキーはHTMLに限らず、画像にも設定することができるため、クッキーは画像ファイルにも設定できるため、広告業者は自社の広告が埋め込まれたあらゆるウェブサイトを横断して、同一ユーザーのブラウジング履歴（アクセス履歴）を長期的に記録・統合できる。ユーザのアクセス履歴を追跡するという意味からトラッキング・クッキーと呼ばれたり、メインのHTMLではなく画像の提供元が設定するという意味からサードパーティークッキーと呼ばれたりする。これらは、行動ターゲティング広告やコンテンツ連動型広告および検索連動型広告などに活用され、時にフィルターバブルの原因ともなっている。
プライバシー上の懸念とユーザーの対策 ユーザーの知らないところで詳細な行動履歴が収集・関連付けられるため、これをプライバシーの権利の侵害と捉える懸念が世界中で高まった。多くのクライアント向けセキュリティ対策ソフトの多くは、トラッキング・クッキーを検出・除去する機能を備えている 。また、サードパーティークッキーに対する批判から、近年ではプライバシーを保護しつつ広告を配信する代替技術（Federated Learning of Cohortsなどのプライバシーサンドボックス技術）への移行が進んでいる。
類似のトラッキング技術 通常のクッキーが拒否・削除されるようになったため、クッキーを用いずにユーザーを追跡する代替技術や、より巧妙な追跡手法が登場している。一般的には、サードパーティーのGoogle Analytics等に見られるIPアドレス・ユーザーエージェント・ウェブビーコン・HTTPリファラなどを利用してアクセス解析をおこないをする方法である。
フィンガープリントと呼ばれる方法もある。これは、JavaScriptおよびHTML5（WebGL、canvas要素、Webフォントなど）を利用し、ブラウザの設定や端末の固有構成から端末の識別子を生成して識別する。
Adobe Flashで使われるLocal Shared Object（フラッシュ・クッキーとも呼ばれる）やSilverlightの保存領域、HTML5（インストール済みのWebフォントなど）、Faviconなどを利用してクッキーと同様のトラッキングをすることが可能である。ユーザには非常に気づかれにくい上に、クッキーが拒否あるいは削除されてもそれらの情報から容易に生成・復元することもできる。これらを総称して、ゾンビクッキーやスーパークッキーと呼ばれる。
これらの技術への対策には、サードパーティー製ブラウザアドオンの使用とJavaScriptの制御や無効化、ウェブブラウザのプライバシーモードやCCleanerを用いたキャッシュおよび閲覧履歴の完全な削除などの対策が必要である。なお、匿名ブラウザであるTor BrowserやOnion Browserに関しては、いまのところウェブトラッキングやキャンバス・フィンガープリンティングなどの回避に有効であるFingerprint解説サイト - 明治大学 情報セキュリティ研究室。
法的規制 トラッキング技術によるプライバシー侵害に対し、国内外の法律で規制が強化されている。
eプライバシー指令 サードパーティークッキーによる、個人のブラウジング履歴の長期的な記録は、潜在的なプライバシーの懸念であり、2011年には欧州および米国の議員が行動を起こすきっかけとなった。2011年以降、欧州連合加盟国を対象とするすべてのウェブサイトにおいて、サイト運営に不可欠ではないクッキー（トラッキング目的など）をユーザーのデバイスに保存する前に、事前の同意を得るオプトインが義務付けられた。これにより、欧州のサイトにアクセスすると「クッキーの受け入れを許可するか」を選択するポップアップが広く表示されるようになった。
EU一般データ保護規則（GDPR） 2018年施行されたEU一般データ保護規則（GDPR）により、クッキーIDやIPアドレス自体が個人データと明確に定義された。ユーザーはデータポータビリティ権や消去権が保障されており、違反した企業には莫大な制裁金が科される。
個人情報保護法 2019年にリクナビの運営会社が目的を十分に説明しないまま、クッキーで得られた情報を外部に販売した問題が発覚したことを受けて、2022年4月1日施行の個人情報の保護に関する法律によって、クッキーの活用に規制がかけられるようになった。
改正電気通信事業法 2023年6月施行の改正電気通信事業法（第27条の12）において、Webサイトやアプリからクッキーなどを外部の第三者へ送信させる際、その送信先や目的などを利用者に通知・公表することを義務付ける規制（外部送信規律）が義務付けられた。
歴史 1994年6月、ネットスケープコミュニケーションズの従業員であり、MCI向けの電子商取引アプリケーションを開発していたルー・モントゥリが、すでにコンピューティングで使用されていたマジッククッキーをウェブ通信で使用することを提唱。ヴィントン・サーフとジョン・クレンシンは、ネットスケープコミュニケーションズとの技術的な話し合いでMCIを代表していた。MCIは、自社のサーバが部分的なトランザクションの状態を保持する必要がないようにしたかったため、ネットスケープに各ユーザのコンピュータにその状態を保存する方法を見つけるように依頼した。クッキーは、仮想ショッピングカートを確実に実装するという問題に対する解決策を提供した。
モントゥリはジョン・ジャナンドレアと共に、同年最初のネットスケープのクッキー仕様を書いた。1994年10月13日にリリースされたMosaic Netscapeのバージョン0.9betaはクッキーをサポートしていた。ラボ外でのクッキーの最初の使用例は、Netscapeのウェブサイトへの訪問者がすでにサイトを訪問したことがあるかどうかを確認することであった。モントゥリは1995年にクッキー技術の特許を出願し、1998年に付与された。クッキーのサポートは、1995年10月にリリースされたInternet Explorerバージョン2に統合された。
当時、クッキーの導入は一般には広く知られていなかった。特に、クッキーはデフォルトで受け入れられており、ユーザにはその存在が通知されていなかった。1996年2月12日にフィナンシャル・タイムズがクッキーに関する記事を掲載した後、一般大衆はクッキーについて知ることとなった。同年、クッキーは特にプライバシーへの潜在的な影響のためにメディアから多くの注目を集めた。クッキーは1996年と1997年の2回の米国連邦取引委員会の公聴会で議論された。
正式なクッキー仕様の開発はすでに進行中であった。特に、正式な仕様に関する最初の議論は1995年4月にwww-talkメーリングリストで始まっていた。IETF内に特別なワーキンググループが結成された。ブライアン・ベーレンドルフとデビッド・クリストルは、HTTPトランザクションに状態を導入するため代替案を提案した。しかし、クリストル自身とルー・モントゥリが率いるグループはすぐに、Netscapeの仕様を出発点として使用することを決定した。1996年2月、ワーキンググループはサードパーティークッキーを重大なプライバシーの脅威として特定した。同グループによって作成された仕様は、最終的に1997年2月にとして公開された。そこでは、サードパーティークッキーは全く許可されないか、少なくともデフォルトでは有効にされないことが指定されていた。この時期、広告会社はすでにサードパーティークッキーを使用していた。のサードパーティークッキーに関する推奨事項は、NetscapeやInternet Explorerでは従われなかった。は2000年10月にに置き換えられた。は `Set-Cookie2` HTTPヘッダフィールドを追加した。しかし `Set-Cookie2` はめったに使用されず、現実世界で使用されるクッキーの決定的な仕様として書かれたで2011年4月に非推奨となった。最新のブラウザは `Set-Cookie2` ヘッダフィールドを認識しない。
仕様の変遷 その後クッキーは1997年にで初めて標準化され、2000年の、2011年ので更新された。2007年現在ほとんどのウェブサーバ、ウェブブラウザで利用可能である。
前述の通り、 には幾つか仕様があるが、IETFの標準化した や は、ネットスケープ仕様とExpires属性からMax-Age属性への変更等互換性がないため、実際のウェブサイトではほとんど使われていない。一方で、Expires属性等で用いられる日付形式は仕様外の記述が氾濫しているうえ、セキュリティ上の理由からhttponly属性やsecure属性等が事実上追加されており、長らく文書の存在しない状態が続いていたが、 はこれらの問題を解消することを意図して制定されている。
2016年頃から、の改訂作業が行われているdraft-ietf-httpbis-rfc6265bis-06。クッキープレフィックスSameSite属性の追加などが行われる予定で、すでにウェブブラウザでの実装も並行して進められている。
ネットスケープ仕様（1994年） - ネットスケープ社のルー・モントゥリらによって記述された最初期の独自仕様である。Expires属性などが定義され、長年デファクトスタンダード（業界標準）となった。 （1997年） - IETFによる初の正式な標準化仕様である。Max-Age属性が導入されたほか、この時点でサードパーティークッキーがプライバシーの脅威として特定された。 （2000年） - 新たに Set-Cookie2 というHTTPヘッダフィールドが導入された。これは「Netscapeスタイルのクッキー」と呼ばれた元の `Set-Cookie` ヘッダフィールドに対して非公式に「スタイルのクッキー」と呼ばれるようになった。既存のネットスケープ仕様との互換性の低さから主要ブラウザにはほとんど普及しなかった。 （2011年） - 普及しなかった Set-Cookie2 を正式に非推奨とし、広く使われていた元の Set-Cookie をベースにブラウザの現実の実装と仕様を一致させた現代の基本標準である。セキュリティ対策のhttponly属性やsecure属性などが事実上追加され、正式に標準化された。 RFC 6265bis（2016年〜現在） - 変化するセキュリティとプライバシー要件に対応するための改訂版仕様である。CSRF対策の SameSite 属性や、不正上書きを防ぐクッキープレフィックス（__Secure-と__Host-）などが追加されたCan I use: headers HTTP header: Set-Cookie: Cookie prefixesCan I use: 'SameSite' cookie attribute。 主要ブラウザによるサードパーティクッキーの段階的廃止（2020年〜2024年） - プライバシー保護の観点から仕様の制限が進んだ。AppleのSafari（ITP）に続き、Google Chromeも2024年初頭から全ユーザーの1%を対象にサードパーティークッキーの廃止テストを開始するなど、原則ブロックへの移行が決定づけられた。