HTTP Cookie の使用

HTTP リクエストを受け取った後、サーバーはレスポンスで Set-Cookie ヘッダーを送信することができます。通常 Cookie はブラウザーに保存され、また Cookie は同じサーバーに対して行われるリクエストと共に HTTP の Cookie ヘッダーの中で送信されます。有効期限や期間を設定することができ、その後は Cookie が送信されなくなります。特定のドメインやパスへの追加の制約を設定することができ、Cookie をどこに送信するかを制限することができます。以下で言及されているヘッダー属性の詳細については、 Set-Cookie のリファレンス記事を参照してください。

HTTP の Set-Cookie レスポンスヘッダーは、サーバーがユーザーエージェントへ Cookie を送信するために使用します。単純な Cookie は次のように設定されます。

Set-Cookie: <cookie-name>=<cookie-value>

これは、サーバーからクライアントへ Cookie の組み合わせを保存するよう指示することを表します。

HTTP/2.0 200 OK
Content-Type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[ページの内容]

また、そのサーバーへのその後のすべてのリクエストにおいて、ブラウザーは以前格納されたすべての Cookie を、 Cookie ヘッダーを使用してサーバーへ送信します。

GET /sample_page.html HTTP/2.0
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

Note: 様々なサーバー側アプリケーションにおける Set-Cookie ヘッダーの使い方を紹介します。

• PHP
• Node.JS
• Python
• Ruby on Rails

Cookie の持続時間は 2 通りの方法で定義することができます。

• セッション Cookie は現在のセッションが終了すると削除されます。ブラウザーはいつ「現在のセッション」が終わったと見なすかを定義し、ブラウザーによっては再起動時にセッションの復元を使用することができます。そのため、結果的にセッション Cookie が無期限に持続することがあります。
• 持続的 Cookie は、 Expires 属性で指定された時刻、または Max-Age で指定された期間が経過した後に削除されます。

例を示します。

Set-Cookie: id=a3fWa; Expires=Thu, 31 Oct 2021 07:28:00 GMT;

Note: Expires の日付を設定した場合、設定された日時はサーバーではなく、Cookie が設定されるクライアントの日時に関連します。

サイトがユーザーを認証する場合、ユーザーが認証するたびに、すでに存在するセッション Cookie も含めて、セッション Cookie を再生成して再送する必要があります。この手法は、第三者がユーザーのセッションを再利用するセッション固定攻撃を防ぐのに役立ちます。

Cookie が安全に送信され、意図しない第三者やスクリプトからアクセスされないようにするには、 Secure 属性と HttpOnly 属性の 2 つの方法があります。

Secure 属性がついた Cookie は HTTPS プロトコル上の暗号化されたリクエストでのみサーバーに送信され、安全でない HTTP では決して送信されないため、中間者攻撃者が簡単にアクセスすることはできません。(URL に http: を含む) 安全でないサイトは、 Secure 属性を使用して Cookie を設定することができません。ただし、Secure によって Cookie 内の機密情報へのアクセスをすべて防げると思ってはいけません。例えば、クライアントのハードディスクへアクセスすることで読み取られる可能性があります。

HttpOnly 属性を持つ Cookie は、 JavaScript の Document.cookie API にはアクセスできません。サーバーに送信されるだけです。例えば、サーバー側のセッションを持続させる Cookie は JavaScript が利用する必要はないので、 HttpOnly 属性をつけるべきです。この予防策は、クロスサイトスクリプティング (XSS) 攻撃を緩和するのに役立ちます。

例を示します。

Set-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly

Domain および Path 属性は、Cookie のスコープ、つまり Cookie を送信する対象の URL を定義します。

Domain 属性

Domain 属性は、Cookie を受信することができるホストを指定します。指定されていない場合は、既定で Cookie を設定したのと同じホストとなり、サブドメインは除外されます。 Domain が指定された場合、サブドメインは常に含まれます。したがって、 Domain を指定すると省略時よりも制限が緩和されます。ただし、サブドメイン間でユーザーに関する情報を共有する場合は有用になるでしょう。

例えば、Domain=mozilla.org を設定すると、developer.mozilla.org のようなサブドメインも含まれます。

Path 属性

Path 属性は、 Cookie ヘッダーを送信するためにリクエストされた URL の中に含む必要がある URL のパスを示します。 %x2F ("/") の文字はディレクトリー区切り文字として解釈され、サブディレクトリーにも同様に一致します。

例えば、Path=/docs を設定すると、以下のリクエストパスに一致します。

• /docs
• /docs/
• /docs/Web/
• /docs/Web/HTTP

ただし、これらのリクエストパスには一致しません。

• /
• /docsets
• /fr/docs

SameSite 属性

SameSite 属性により、サーバーがサイト間リクエスト (ここでサイトは登録可能なドメインによって定義されます) と一緒に Cookie を送るべきではないことを要求することができます。これは、クロスサイトリクエストフォージェリー攻撃 (CSRF) に対していくらかの防御となります。取ることができる値は Strict, Lax, None の 3 つです。

Strictでは、 Cookie は発生したサイトのみに送信されます。 Lax も同様ですが、ユーザーが Cookie のオリジンのサイトに「移動」したときにも Cookie が送信されます。 例えば、外部サイトからリンクをたどった場合です。 None は Cookie を発生元サイトへリクエストとサイト間のリクエストの両方で送信されますが、安全なコンテキストでのみ送信されます（つまり、 SameSite=Noneなら Secure 属性も設定する必要があります）。 もし SameSite 属性が設定されていない場合、 Cookie は Lax として扱われます。

次に例を示します。

Set-Cookie: mykey=myvalue; SameSite=Strict

Note: SameSite に関する標準規格が最近変更されました（MDN で文書化している上記の動作は新しい動作です）。 ブラウザーの特定の版がこの属性をどのように扱うかの情報については、 Cookie のブラウザー互換性一覧表を参照してください。

• SameSite=Lax は SameSite が指定されなかった場合の新しい既定値です。 以前は、 Cookie は既定ですべてのリクエストに送信されていました。
• Cookie に SameSite=None が付いた場合は、 Secure 属性も指定することになりました（安全なコンテキストが必要になりました）。
• 同じドメインの Cookie であっても、異なるスキーム (http: か https: か) を使用して送信された場合は同じサイトと見なされなくなりました。

Cookie の接頭辞

Cookie の仕組みの設計では、 Cookie が安全なオリジンに設定されているかどうか、 Cookie が当初はどこに設定されたのかをサーバーが確認することができないようになっています。

サブドメイン上にある脆弱性のあるアプリケーションが Domain 属性を使用して Cookie を設定すると、ほかのすべてのサブドメインで Cookie にアクセスできるようにすることができます。この仕組みはセッション固定攻撃で悪用される可能性があります。主な対策方法はセッション固定化を参照してください。

しかし、多層防御として、 Cookie に関する特定の事実を主張するために Cookie の接頭辞を使うことが可能です。以下の 2 つの接頭辞が利用可能です。

__Host-

Cookie 名にこの接頭辞がついている場合、 Set-Cookie ヘッダーが受け入れられるのは Secure 属性で指定されており、安全なオリジンから送信されており、 Domain 属性を含んでおらず、 Path 属性が / に設定されている場合のみです。この場合、これらの Cookie は「ドメインにロックされている」と見なすことができます。

__Secure-

Cookie 名にこの接頭辞がある場合、 Set-Cookie ディレクティブが受け入れられるのは、 Secure であり、安全なオリジンから送信されている場合のみです。これは __Host- 接頭辞よりも弱いものです。

これらの接頭辞が付いていて、制約に適合していない Cookie は、送られてもブラウザーが拒否します。これにより、仮にサブドメインで接頭辞の付いた Cookie を作成した場合、サブドメインに限定されるか、完全に無視されるかします。アプリケーションサーバーは、ユーザーが認証されているか、あるいは CSRF トークンが正しいかどうかを判断するときに、特定の Cookie 名をチェックするだけなので、これはセッションの固定化に対する防御手段として効果的に機能します。

Note: アプリケーションサーバ上では、ウェブアプリケーションは接頭辞を含む完全な Cookie 名をチェックしなければなりません。—ユーザーエージェントは、リクエストの Cookie ヘッダーを送信する前に Cookie から接頭辞を削除しません。

Cookie の接頭辞とブラウザー対応の現在の状態については、 [Set-Cookie リファレンス記事の接頭辞の節](/ja/docs/Web/HTTP/Headers/Set-Cookie# Cookie の接頭辞)を参照してください。

JavaScript での Document.cookies を使用したアクセス

Document.cookie プロパティを使用して新しい Cookie を作成することができますし、 HttpOnly フラグが設定されていない限り、既存の Cookie に JavaScript からアクセスすることもできます。

document.cookie = "yummy_cookie=choco";
document.cookie = "tasty_cookie=strawberry";
console.log(document.cookie);
// "yummy_cookie=choco; tasty_cookie=strawberry" とログ出力

JavaScript で生成された Cookie は HttpOnly フラグを含むことができません。

後述するセキュリティの節に記載したとおり、セキュリティの影響に注意してください。JavaScript で使用できる Cookie は、XSS によって盗まれる可能性があります。

Note: 情報を Cookie に保存するときは、すべての Cookie の値がエンドユーザーから見え、変更できることを理解しておいてください。アプリケーションによっては、サーバー側で検索される不透明な識別子を使用するか、 JSON ウェブトークンのような代替の認証/機密性メカニズムを調べたほうが良いかもしれません。

Cookie への攻撃を緩和する方法には次のようなものがあります。

• HttpOnly 属性を使用して、 JavaScript から Cookie の値にアクセスすることを防ぎます。
• 機密情報 (認証を示す場合など) のために使用された Cookie は、持続時間を短く、 SameSite 属性を Strict または Lax に設定してください。 (上記の SameSite Cookie を参照。) SameSite に対応しているブラウザーでは、これは、認証 Cookie がオリジン間リクエストと一緒に送信されないようにする効果があるので、そのようなリクエストはそのアプリケーションサーバーに対して事実上認証されていないことになります。

Cookie はドメインとスキーム（http や https など）に関連付けられ、 Set-Cookie の Domain 属性が設定された場合はサブドメインにも関連付けられます。 Cookie のドメインとスキームが現在のページと一致している場合、その Cookie はこのページと同じサイトからのものと見なされ、ファーストパーティ Cookie と呼ばれます。

ドメインとスキームが異なる場合、そのクッキーは同じサイトのものとはみなされず、サードパーティ Cookie と呼ばれます。 ウェブページをホスティングしているサーバーがファーストパーティ Cookie を設定する一方で、ページには他のドメインのサーバーに保存されている画像やその他のコンポーネント (例えば、広告バナー) が含まれている場合があり、サードパーティ Cookie を設定することがあります。 これらは主にウェブ上での広告やトラッキングに使用されます。 例えば Google が使用している Cookie の種類を参照してください。

サードパーティのサーバーは、複数のサイトにアクセスした際に同じブラウザーから送信された Cookie に基づいて、ユーザーの閲覧履歴や習慣のプロファイルを構築することができます。 Firefox は既定で、トラッカーを含むことが知られているサードパーティの Cookie をブロックします。サードパーティの Cookie (またはトラッキング Cookie ) は、他のブラウザーの設定や拡張機能によってもブロックされる場合があります。 Cookie をブロックすると、一部のサードパーティ製コンポーネント (ソーシャルメディアウィジェットなど) が意図した通りに機能しなくなることがあります。

Note: サーバーは Cookie を設定する際、 SameSite 属性を使用して第三者のサイトに Cookie を送信してよいかどうかを指定することができます（また、指定すべきです）。

Cookie の使用を対象とした法規制には、以下のようなものがあります。

• EU の 一般データ保護規則 (GDPR)
• EU の ePrivacy 指令
• カリフォルニア州消費者プライバシー法

これらの規制は、これらの管轄区域（EU とカリフォルニア州、特にカリフォルニア州の法律は総収入が 2,500 万ドルを超える事業体にのみ適用されるという注意事項がある）のユーザーがアクセスする全世界のウェブ上のあらゆるサイトに適用されるため、世界的な広がりを持っています。

これらの規制の要件には次のようなものがあります。

• サイトが Cookie を使用することをユーザーに通知すること。
• ユーザーが一部またはすべての Cookie をオプトアウトできるようにすること
• ユーザーが Cookie を受け取らなくても、サービスの大部分を利用できるようにすること。

地域によっては、他にも Cookie の使用を管理する規制があるかもしれません。これらの規制を理解し遵守することは、自分自身の責任となります。これらの規制を遵守するのに役立つ「Cookie 禁止」コードを提供している会社もあります。

ブラウザーにデータを保存する別のアプローチとして、 Web Storage API があります。 window.sessionStorage と window.localStorage プロパティはセッション Cookie と持続的 Cookie に対応していますが、ストレージの容量制限が Cookie より大きく、サーバーに送信されることはありません。より構造化された大量のデータは、 IndexedDB API またはその上に構築されたライブラリを使用して保存することができます。

「ゾンビ」 Cookie と呼ばれる、 Cookie が削除された後に再作成されるようにするための他の技術が作成されています。これらの技術は、ユーザーのプライバシーとユーザー制御の原則に違反し、データプライバシー規制に違反する可能性があり、これらの技術を使用しているウェブサイトが法的責任にさらされる可能性があります。

• Set-Cookie
• Cookie
• Document.cookie
• Navigator.cookieEnabled
• ストレージインスペクターを使った Cookie の調査
• Cookie specification: RFC 6265
• HTTP cookie on Wikipedia
• Cookies, the GDPR, and the ePrivacy Directive