この記事は Chrome およびウェブ プラットフォーム パートナーシップ、Barb Palser による Chromium Blog の記事 "Developers: Get Ready for New SameSite=None; Secure Cookie Settings" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
5 月に Chrome から Cookie をデフォルトで安全な状態にするモデルについてお知らせしました。これは、新しい Cookie 分類システム（仕様）によって実現されます。この取り組みは、ウェブのプライバシーとセキュリティを改善するための継続的な作業の一部です。
Chrome は、2020 年 2 月の Chrome 80 でこの新しいモデルを実現する予定です。Mozilla と Microsoft も、それぞれのタイムラインでこの新しいモデルを Firefox と Edge に実装する予定であることを表明しています。Chrome の変更はまだ数か月先のことですが、Cookie を管理しているデベロッパーの皆さんはすぐに準備状況を評価することが重要です。本ブログ投稿では、大まかな考え方について説明します。デベロッパー向けのガイダンスについては、web.dev の SameSite Cookie の説明をご覧ください。
わかりにくいクロスサイトの例として、複数のウェブサイトを所有するエンティティが複数のサイトをまたぐ Cookie を使う場合などがあげられます。この場合、Cookie とウェブサイトは同じエンティティが所有しています。しかし、Cookie のドメインがその Cookie にアクセスするサイトのドメインと一致しなければ、クロスサイトすなわち「サードパーティ」コンテキストという扱いになります。
一方、Cookie のドメインがユーザーのアドレスバーに表示されているウェブサイトのドメインと一致する場合は、同一サイト（すなわち「ファースト パーティ」）コンテキストによる Cookie アクセスとなります。同一サイトの Cookie は、個々のウェブサイトでログイン状態を維持する、ユーザー設定を保存する、サイトのアナリティクスを行う、といった目的でよく使用されています。
そこで、ウェブサイトとユーザーを保護するため、デフォルトで安全な状態にする新しいモデルでは、明示的な指定がない限り、すべての Cookie を外部アクセスからの保護対象と見なします。デベロッパーは新しい Cookie 設定SameSite=Noneを使い、Cookie をクロスサイト アクセスの対象として指定する必要があります。SameSite=None属性が存在する場合は、クロスサイト Cookie に HTTPS 接続のみでアクセスできるように、Secure属性も追加する必要があります。これでクロスサイト アクセスに関連するすべてのリスクが緩和されるわけではありませんが、ネットワーク攻撃に対する保護は実現できます。
このようにクロスサイト Cookie を明示的に宣言すると、すぐにセキュリティを向上できるだけでなく、透過性が高まり、ユーザーの選択肢も増えます。たとえば、1 つのサイトからアクセスされる Cookie と複数のサイトからアクセスされる Cookie を分けて管理するなど、ブラウザで Cookie の細やかな制御を行えるようになります。
Mozilla は、Firefox でクロスサイト Cookie の SameSite=None; Secure要件を実装する予定で、新しい Cookie 分類モデルのサポートを確約しています。Microsoft は先日、Microsoft Edge 80 より試験運用版としてこのモデルの実装を開始する計画を発表しました。
管理しているサイトや Cookie に対する Chrome の新しい動作の影響をテストしたい場合は、Chrome 76 以降で chrome://flags を開き、試験運用版機能である [SameSite by default cookies] と [Cookies without SameSite must be secure] を有効にします。また、一部の Chrome 79 ベータ版ユーザーは、これらの試験運用版機能が自動的に有効になります。試験運用版機能を有効にしたベータ版ユーザーによっては、新しいモデルをまだサポートしていないサービスによって互換性に関する問題が起きることがあります。ユーザーは、chrome://flags に移動してベータ版の試験運用を無効にすることで、対象の機能をオプトアウトできます。
同一サイト コンテキストのみでアクセスされる Cookie（同一サイト Cookie）を管理している場合、何もする必要はありません。SameSite 属性がない、または値が設定されていない場合でも、Chrome は外部エンティティからこれらの Cookie へのアクセスを自動的にブロックします。ただし、すべてのブラウザがデフォルトで同一サイト Cookie を保護するとは限らないため、適切な SameSite 値（Laxまたは Strict）を設定し、デフォルトのブラウザの動作に依存しないことを強くお勧めします。
最後に、皆さんのウェブサイトにサービスを提供しているベンダーなどの対応を懸念している方へお伝えします。必要な設定が行われていないクロスサイト Cookie がページに含まれる場合、Chrome 77 以降のデベロッパー ツールのコンソールに次の警告が表示されます。この警告を確認してください。
![]()
2 月の Chrome 80 のリリースまでの数か月間で必要な変更を実装するプロバイダ（一部の Google 製サービスを含む）もあります。対応状況を確認するために、パートナーに連絡してみるのもよいでしょう。
Reviewed by Eiji Kitamura - Developer Relations Team![]()
5 月に Chrome から Cookie をデフォルトで安全な状態にするモデルについてお知らせしました。これは、新しい Cookie 分類システム（仕様）によって実現されます。この取り組みは、ウェブのプライバシーとセキュリティを改善するための継続的な作業の一部です。
Chrome は、2020 年 2 月の Chrome 80 でこの新しいモデルを実現する予定です。Mozilla と Microsoft も、それぞれのタイムラインでこの新しいモデルを Firefox と Edge に実装する予定であることを表明しています。Chrome の変更はまだ数か月先のことですが、Cookie を管理しているデベロッパーの皆さんはすぐに準備状況を評価することが重要です。本ブログ投稿では、大まかな考え方について説明します。デベロッパー向けのガイダンスについては、web.dev の SameSite Cookie の説明をご覧ください。
クロスサイトおよび同一サイトの Cookie コンテキストを理解する
広告、お勧めコンテンツ、サードパーティ製ウィジェット、ソーシャル メディアの埋め込みなどの機能を実現するため、ウェブサイトに外部サービスが組み込まれることがよくあります。ウェブサイトをブラウジングすると、こういった外部サービスが皆さんのブラウザに Cookie を保存し、のちほどその Cookie にアクセスしてユーザーに応じた内容を表示したり、エンゲージメントを計測したりすることがあります。すべての Cookie には、ドメインが関連付けられています。Cookie に関連付けられたドメインが外部サービスに一致し、ユーザーのアドレスバーに表示されているウェブサイトには一致しない場合、クロスサイト（すなわち「サードパーティ」）コンテキストと見なされます。わかりにくいクロスサイトの例として、複数のウェブサイトを所有するエンティティが複数のサイトをまたぐ Cookie を使う場合などがあげられます。この場合、Cookie とウェブサイトは同じエンティティが所有しています。しかし、Cookie のドメインがその Cookie にアクセスするサイトのドメインと一致しなければ、クロスサイトすなわち「サードパーティ」コンテキストという扱いになります。
一方、Cookie のドメインがユーザーのアドレスバーに表示されているウェブサイトのドメインと一致する場合は、同一サイト（すなわち「ファースト パーティ」）コンテキストによる Cookie アクセスとなります。同一サイトの Cookie は、個々のウェブサイトでログイン状態を維持する、ユーザー設定を保存する、サイトのアナリティクスを行う、といった目的でよく使用されています。
Cookie のセキュリティと透過性を実現するための新しいモデル
現在のところ、Cookie がファースト パーティ コンテキストからのみアクセスできるようにする場合、デベロッパーは 2 つの設定（SameSite=Laxまたは SameSite=Strict）のいずれかを選んで外部アクセスを防ぐことができます。しかし、この推奨手法に従っているデベロッパーはほとんどおらず、大多数の同一サイト Cookie はクロスサイト リクエスト フォージェリ攻撃などの脅威に不要にさらされています。そこで、ウェブサイトとユーザーを保護するため、デフォルトで安全な状態にする新しいモデルでは、明示的な指定がない限り、すべての Cookie を外部アクセスからの保護対象と見なします。デベロッパーは新しい Cookie 設定SameSite=Noneを使い、Cookie をクロスサイト アクセスの対象として指定する必要があります。SameSite=None属性が存在する場合は、クロスサイト Cookie に HTTPS 接続のみでアクセスできるように、Secure属性も追加する必要があります。これでクロスサイト アクセスに関連するすべてのリスクが緩和されるわけではありませんが、ネットワーク攻撃に対する保護は実現できます。
このようにクロスサイト Cookie を明示的に宣言すると、すぐにセキュリティを向上できるだけでなく、透過性が高まり、ユーザーの選択肢も増えます。たとえば、1 つのサイトからアクセスされる Cookie と複数のサイトからアクセスされる Cookie を分けて管理するなど、ブラウザで Cookie の細やかな制御を行えるようになります。
Chrome は 2020 年 2 月より新しいモデルを適用
2 月の Chrome 80 以降、SameSite 値が宣言されていない Cookie は SameSite=Laxとして扱われます。外部アクセスは、SameSite=None; Secure設定のある Cookie のみ可能になります。ただし、これらが安全な接続からアクセスされることが条件です。Chrome プラットフォームの SameSite=Noneと Secureの Status Tracker は、最新のリリース情報に基づいて今後もアップデートが継続されます。Mozilla は、Firefox でクロスサイト Cookie の SameSite=None; Secure要件を実装する予定で、新しい Cookie 分類モデルのサポートを確約しています。Microsoft は先日、Microsoft Edge 80 より試験運用版としてこのモデルの実装を開始する計画を発表しました。
準備方法と既知の複雑なケース
クロスサイト Cookie を管理している方は、Cookie に SameSite=None; Secure 設定を適用する必要があります。ほとんどのデベロッパーは簡単な実装で済むはずです。しかし、以下のような複雑なケースや特殊なケースを判別するため、すぐにテストを開始することを強くお勧めします。- 現時点で、すべての言語やライブラリが None 値をサポートしているわけではありません。サポートされていない場合は、デベロッパーは直接 Cookie ヘッダーを設定する必要があります。こちらの Github リポジトリには、さまざまな言語、ライブラリ、フレームワークで SameSite=None; Secureを実装する手順が示されています。
- 特定のバージョンの Chrome、Safari、UC Browser など、一部のブラウザは None 値を意図しない方法で処理する可能性があります。その場合、デベロッパーはそのようなクライアント向けに例外処理をコーディングする必要があります。これには、古いバージョンの Chrome が提供している Android の WebView も含まれます。既知の互換性のないクライアントの一覧はこちらです。
- アプリ デベロッパーは、None 値と互換性のある Chrome のバージョンに基づいて Android WebView 用に適切な SameSite Cookie 設定を宣言するようにします。これは、HTTP（S）ヘッダーを通してアクセスされる Cookie と、Android WebView の CookieManager APIを通してアクセスされる Cookie の両方について行う必要があります。ただし、新しいモデルによって Android WebView が影響を受けるようになるのはまだ先のことです。
- シングル サインオンなどのサービスや社内アプリケーションが 2 月のリリースに対応できない場合、企業の IT 管理者が特別なポリシーを実装し、Chrome ブラウザを一時的に以前の動きに戻す必要があるかもしれません。
- ファースト パーティ コンテキストとサードパーティ コンテキストの両方でアクセスする Cookie がある場合、ファースト パーティ コンテキストで別の Cookie を使って SameSite=Lax によるセキュリティのメリットを得ることを検討してください。
管理しているサイトや Cookie に対する Chrome の新しい動作の影響をテストしたい場合は、Chrome 76 以降で chrome://flags を開き、試験運用版機能である [SameSite by default cookies] と [Cookies without SameSite must be secure] を有効にします。また、一部の Chrome 79 ベータ版ユーザーは、これらの試験運用版機能が自動的に有効になります。試験運用版機能を有効にしたベータ版ユーザーによっては、新しいモデルをまだサポートしていないサービスによって互換性に関する問題が起きることがあります。ユーザーは、chrome://flags に移動してベータ版の試験運用を無効にすることで、対象の機能をオプトアウトできます。
同一サイト コンテキストのみでアクセスされる Cookie（同一サイト Cookie）を管理している場合、何もする必要はありません。SameSite 属性がない、または値が設定されていない場合でも、Chrome は外部エンティティからこれらの Cookie へのアクセスを自動的にブロックします。ただし、すべてのブラウザがデフォルトで同一サイト Cookie を保護するとは限らないため、適切な SameSite 値（Laxまたは Strict）を設定し、デフォルトのブラウザの動作に依存しないことを強くお勧めします。
最後に、皆さんのウェブサイトにサービスを提供しているベンダーなどの対応を懸念している方へお伝えします。必要な設定が行われていないクロスサイト Cookie がページに含まれる場合、Chrome 77 以降のデベロッパー ツールのコンソールに次の警告が表示されます。この警告を確認してください。
2 月の Chrome 80 のリリースまでの数か月間で必要な変更を実装するプロバイダ（一部の Google 製サービスを含む）もあります。対応状況を確認するために、パートナーに連絡してみるのもよいでしょう。
Reviewed by Eiji Kitamura - Developer Relations Team