ファーストパーティの 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 へのリクエストでは送信されません。複数のアプリを異なるサブドメインで実行すれば、侵害されたドメインが他のドメインに侵入するリスクを軽減できます。

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

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

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 を読み込む場合など）、ユーザーが元のサイトに移動したとき（別のサイトからリンクをたどるときなど）に送信されます。

Cookie へのアクセスをさらに制限し、SameSite=Strict でサードパーティのウェブサイトから開始されたリクエストとともに Cookie を送信できないようにすることが可能です。これは、パスワードの変更や購入など、最初のナビゲーションの背後に必ず存在する機能に関連する Cookie がある場合に有効です。

レシピ

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