ファーストパーティの Cookie のレシピ

セキュリティを確保し、ブラウザ間の互換性を確保し、サードパーティ Cookie の段階的廃止後の破損の可能性を最小限に抑えるために、ファーストパーティの Cookie を設定する方法について説明します。

Milica Mihajlija

Cookie には、その時点でユーザーがアクセスしているサイトに応じて、ユーザーのコンテキストに応じてファーストパーティ製とサードパーティ製のものがあります。Cookie の登録可能なドメインとスキームが現在のトップレベル ページ、つまりブラウザのアドレスバーに表示されているページと一致する場合、その Cookie はそのページと同じサイトのものと見なされ、一般的に「ファーストパーティ Cookie」と呼ばれます。

一般的に、現在のサイト以外のドメインからの Cookie はサードパーティ Cookie と呼ばれます。

設定している Cookie が複数のサイト間で使用されていない場合（たとえば、サイトのセッションの管理に使用され、クロスサイト iframe では使用されない場合）、その Cookie は常にファーストパーティのコンテキストで使用されます。

デフォルトでは、Cookie はサイト間で共有され、JavaScript によってアクセスされ、HTTP 接続を介して送信されますが、これにはプライバシーとセキュリティ上のリスクが伴います。現在、デフォルトの動作を改善する取り組みがプライバシー サンドボックスやオリジン バインド Cookie などの提案を通じて行われていますが、現在は Cookie に追加属性を設定することでできることが多数あります。

次の設定は、ほとんどのファーストパーティ Cookie のセキュリティとクロスブラウザ互換性を確保するためのベスト プラクティスです。これにより、安全な基盤が提供され、必要な場合にのみ権限を開くように調整できます。この記事では、特定のユースケースにおけるレシピのバリエーションについても説明します。

レシピ

Set-Cookie:
__Host-cookie-name=cookie-value;
Secure;
Path=/;
HttpOnly;
Max-Age=7776000;
SameSite=Lax;
詳細

Host は省略可能な接頭辞で、一部の属性を必須にし、その他の属性を禁止します。

  • Secure は必須です
  • Domain は省略する必要があります
  • Path は / にする必要があります。

Host を追加すると、これらの属性が __Host ルールに沿って設定されているかどうかを確認し、正しく設定されていない場合は Cookie を拒否できます。

Secure は、HTTPS 接続経由での Cookie の送信のみを許可するため、安全でないネットワーク上での Cookie の盗難を防ぎます。サイトを HTTPS に完全に移行していない場合は、移行を優先してください。

Domain 属性では、Cookie を受信できるホストを指定します。このポリシーを省略すると、Cookie は現在のドキュメント ホスト（サブドメインを除く）に限定されます。example.com の Cookie は example.com へのリクエストのたびに送信されますが、images.example.com へのリクエストでは送信されません。サブドメインごとに異なるアプリを運用している場合、1 つの侵害されたドメインが他のドメインに侵入するリスクを軽減できます。

Path は、ブラウザから Cookie ヘッダーを送信するために、リクエストされた URL に存在する必要があるパスを示します。Path=/ を設定すると、そのドメインのすべての URL パスに Cookie が送信されます。Domain と Path=/ の組み合わせでは、Cookie がオリジンに可能な限り近くバインドされるため、LocalStorage などの他のクライアントサイド ストレージと同様に動作します。example.com/a が example.com/b と異なる値を受け取る可能性があるという混乱はありません。

HttpOnly 属性を使用すると、JavaScript のアクセスを制限することで、悪意のあるサードパーティ スクリプトからサイトを守ることができます。これにより、リクエスト ヘッダーでのみ Cookie が送信され、document.cookie を使用して JavaScript で使用できなくなります。

Max-Age は、ブラウザ セッションがかなり長く持続することがあり、古い Cookie を永久に残す必要がないため、Cookie の寿命を制限します。ユーザー セッションなどの短期間の Cookie や、フォーム送信用のトークンなどの短時間の Cookie に適しています。Max-Age は秒単位で定義され、上記の例では 7776,000 秒（90 日）に設定されています。これは妥当なデフォルト値であり、ユースケースに応じて変更できます。

SameSite=Lax は、同一サイトのリクエストでのみ Cookie が送信されるよう制限します。つまり、リクエストが現在の閲覧コンテキスト（ユーザーが現在アクセスしていて、ロケーション バーに表示されている最上位のサイト）に一致する場合です。最新のブラウザでは SameSite=Lax がデフォルトですが、異なるデフォルトが異なる複数のブラウザ間で互換性を保つため、指定することをおすすめします。Cookie を同一サイトのみとして明示的にマークすると、ファーストパーティのコンテキストに限定され、サードパーティ Cookie がなくなった際にその Cookie に変更を加える必要がなくなります。

Cookie のさまざまな属性について詳しくは、MDN の Set-Cookie ドキュメントをご覧ください。

サブドメインを持つサイトにサブドメイン全体で 1 回のセッションを行う場合、Host プレフィックスは制限が厳しすぎる可能性があります。たとえば、news.site に finance.news.site や sport.news.site といったトピックのサブドメインがあり、それらすべてで 1 つのユーザー セッションが必要になるとします。その場合は、__Host ではなく __Secure 接頭辞を使用して Domain を指定します。

レシピ

Set-Cookie:
__Secure-cookie-name=cookie-value;
Secure;
Domain=news.site;
Path=/;
HttpOnly;
Max-Age=7776000;
SameSite=Lax;
詳細

Secure は、Host よりも少ない要件を示すオプションの接頭辞です。Secure 属性で Cookie を設定するだけで済みます。

SameSite=Lax Cookie は、クロスサイト サブリクエスト（サードパーティのサイトで埋め込み画像や iframe を読み込むときなど）では送信されませんが、ユーザーが元のサイトに移動したとき（別のサイトからのリンクをたどるときなど）に送信されます。

SameSite=Strict を使用して、Cookie へのアクセスをさらに制限したり、サードパーティのウェブサイトから送信されるリクエストとともに Cookie を送信できないようにしたりできます。これは、パスワードの変更や購入など、常に最初のナビゲーションで実行される機能に関連する Cookie がある場合に役立ちます。

レシピ

Set-Cookie:
__Host-cookie-name=cookie-value;
Secure;
Path=/;
HttpOnly;
Max-Age=7776000;
SameSite=Strict;