2020 年 1 月 16 日(木曜日)
この記事では、Chrome への変更が今後のウェブサイトの動作にどのように影響するかを説明します。同じ内容は Chromium デベロッパー ブログにも投稿されています。
昨年 5 月、Chrome は Cookie のセキュア バイ デフォルトを発表しました。これは新しい Cookie 分類システムにより実現されます(仕様)。このイニシアチブは、ウェブ全体でのプライバシーとセキュリティの改善に対する継続的な取り組みの一環です。
2020 年 2 月に、Chrome 80 でこの新しいモデルを実装する予定です。Mozilla と Microsoft も、独自のタイムラインに Firefox と Edge でこの新しいモデルを実装する意向を表しています。Chrome に対する変更は数か月後ですが、Cookie を管理するデベロッパーはすぐに準備することが重要です。このブログ投稿ではおおまかなコンセプトを概説します。デベロッパー向けのガイダンスについては、web.dev の SameSite Cookie の説明をご覧ください。
クロスサイト Cookie と同一サイト Cookie のコンテキストについて
ウェブサイトでは通常、広告、コンテンツのおすすめ、サードパーティのウィジェット、ソーシャル ネットワークの埋め込みなどの外部サービスを統合します。ウェブを閲覧する際、こうした外部サービスがブラウザに Cookie を保存し、その後に保存した Cookie にアクセスして、パーソナライズされたエクスペリエンスを提供したり、ユーザー エンゲージメントを測定したりすることがあります。すべての Cookie にはドメインが関連付けられています。Cookie に関連付けられたドメインが、ユーザーのアドレスバーのウェブサイトではなく外部サービスと一致する場合、クロスサイト(つまり「サードパーティ」)コンテキストだとみなされます。
これよりも不明確なクロスサイトのユースケースとしては、複数のウェブサイトを所有しているエンティティが、複数のプロパティで 1 つの Cookie を使用するといったものがあります。その Cookie とウェブサイトを同じエンティティが所有していても、Cookie のドメインが Cookie のアクセス元のサイトと一致しない場合は、クロスサイト(つまり「サードパーティ」)コンテキストとみなされます。

ウェブページ上の外部リソースがサイトドメインと一致しない Cookie にアクセスした場合は、クロスサイト(つまり「サードパーティ」)コンテキストです。
これに対して、同一サイト(つまり「ファースト パーティ」)コンテキストでの Cookie のアクセスは、Cookie のドメインがユーザーのアドレスバーのウェブサイト ドメインと一致する場合に発生します。同一サイト Cookie は、個々のウェブサイトでユーザーのログイン状態や好みを保存したり、サイト分析をサポートしたりするためによく使用されます。

ウェブページ上のリソースが、ユーザーがアクセスしているサイトに一致する Cookie にアクセスする場合は、同一サイト(つまり「ファースト パーティ」)コンテキストです。
Cookie のセキュリティと透明性に関する新しいモデル
現在、ファースト パーティ コンテキストでのみ Cookie にアクセスする場合は、2 つの設定(SameSite=Lax
または SameSite=Strict
)のいずれかを使って外部アクセスを禁止することが可能です。ただし、この手法を採用しているデベロッパーはごく少数に限られているため、多数の同一サイト Cookie がクロスサイト リクエスト フォージェリ攻撃などの脅威に不必要にさらされています。
より多くのウェブサイトとユーザーの安全を確保するため、新しいセキュア バイ デフォルト モデルでは、特に指定のない限りすべての Cookie を外部アクセスから保護する必要があると想定します。Cookie をクロスサイト アクセス用と指定するには、新しい Cookie の設定 SameSite=None
を使用する必要があります。SameSite=None
属性を使用する場合は、HTTPS 接続でのみクロスサイト Cookie にアクセスできるように、追加の Secure 属性を使用する必要があります。
これにより、クロスサイト アクセスに関連するすべてのリスクが軽減されるわけではありませんが、ネットワーク攻撃に対する保護となります。
クロスサイト Cookie を明示的に宣言することで、すぐにセキュリティが向上するだけでなく、透明性も向上して、ユーザーの選択肢も増えます。たとえば、ブラウザできめ細かな制御を行うことが可能となり、1 つのサイトからのみアクセスされる Cookie を複数のサイトからアクセスされる Cookie とは別に管理できるようになります。
2020 年 2 月以来の Chrome での違反措置
2 月導入の Chrome 80 では、SameSite 値が宣言されていない Cookie が SameSite=Lax
Cookie として扱われています。SameSite=None
; Secure 設定のある Cookie のみが外部アクセスから使用できます(それらの Cookie がセキュアな接続からアクセスされている場合に限る)。SameSite=None
と Secure に対する Chrome プラットフォーム ステータス トラッカーは、最新のリリース情報に従って継続的に更新されます。
Mozilla は、Firefox のクロスサイト Cookie に関して SameSite=None
; Secure の要件を実装する意向を示し、新しい Cookie 分類モデルのサポートを表明しました。Microsoft は先日、Microsoft Edge 80 で、このモデルの実装を実験的に開始する計画を発表しました。
準備方法、現在わかっている複雑な点
クロスサイト Cookie を管理する場合は、SameSite=None
; Secure 設定を Cookie に適用する必要があります。実装は大半のデベロッパーにとって簡単ですが、次のような複雑な点や特殊なケースを特定するために、今すぐテストを開始することを強くおすすめします。
-
一部の言語とライブラリでは None 値がまだサポートされていないため、デベロッパーが Cookie ヘッダーを直接設定する必要があります。こちらの GitHub リポジトリでは、さまざまな言語、ライブラリ、フレームワークで
SameSite=None
; Secure を実装する手順を説明しています。 -
Chrome、Safari、UC ブラウザの一部のバージョンなど、一部のブラウザでは、
None
値が意図しない方法で処理されるため、デベロッパーがそれらのクライアントのための例外処理をコーディングする必要があります。これには、古いバージョンの Chrome に搭載された Android WebView も含まれます。互換性のないクライアントのリストをご確認ください。 -
None
値と互換性のあるバージョンの Chrome をベースとした AndroidWebViews
には、HTTP(S)でアクセスさせる Cookie と、AndroidWebView
の CookieManager API でアクセスされる Cookie の両方に、適切なSameSite cookie
設定を宣言することをおすすめします。ただし、新しいモデルが Android WebView に適用されるのは、しばらく後になります。 - 企業の IT 管理者は、シングル サインオンや内部アプリケーションなどの一部のサービスが 2 月のリリースに対応していない場合、Chrome ブラウザを一時的に以前の動作に戻すために特別なポリシーを実装する必要があります。
-
ファーストパーティとサードパーティの両方のコンテキストでアクセスする Cookie がある場合、別々の Cookie を使用して、ファーストパーティのコンテキストに
SameSite=Lax
を使用すると、セキュリティ上のメリットを得られます。
SameSite Cookie の詳細では、上記の状況に対する具体的なガイダンスと、問題の報告や質問をするためのチャネルについて説明しています。
Chrome 76 以降では、chrome://flags
に移動して、[SameSite by default cookies] と [Cookies without SameSite must be secure] を有効にすると、新しい Chrome の動作がサイトまたは管理する Cookie に及ぼす影響をテストできます。また、Chrome 79 ベータ版のユーザーの一部では、これらの実験段階の機能が自動的に有効になります。これらの実験段階の機能が有効になっているベータ版では、新しいモデルをサポートしていないサービスとの非互換性の問題が発生する可能性があります。chrome://flags
に移動して無効にすれば、ベータ版の実験段階の機能を無効にできます。
同一サイトのコンテキストでのみアクセスされる Cookie(同一サイトの Cookie)を管理している場合、対応していただく必要はありません。SameSite 属性がない、または値が設定されていない場合でも、外部エンティティがこれらの Cookie にアクセスすることを Chrome が自動的にブロックします。ただし、すべてのブラウザがデフォルトで同一サイトの Cookie を保護するわけではないため、適切な SameSite 値(Lax または Strict)を適用し、デフォルトのブラウザ動作に依存しないようにすることを強くおすすめします。
最後に、ウェブサイトにサービスを提供しているベンダーやその他の事業者の準備状況を懸念されている場合、以下のように、サイトにクロスサイト Cookie がないときの Chrome 77 以降の警告をデベロッパー ツールのコンソールで確認できます。

一部のプロバイダ(一部の Google サービスを含む)では、2 月の Chrome 80 に向けて必要な変更が実施されます。パートナーに連絡して準備状況を確認することをおすすめします。