この記事は Steven Bingler、Rowan Merewood による web.dev の記事 "Schemeful Same-Site" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

この記事は、SameSite Cookie 属性変更シリーズの一部です。

スキームフル Same-Site は、「サイト」の定義を、「登録可能ドメイン」のみから、「スキーム＋登録可能ドメイン」に変えるものです。詳細や例は、「同一サイト」と「同一オリジン」を理解するをご覧ください。

重要な用語: つまり、http://website.example のような安全でない HTTP バージョンのサイトと、https://website.example のような安全な HTTPS バージョンのサイトが、お互いにクロスサイトと見なされるということです。

うれしいのは、すべてのウェブサイトを既に HTTPS にアップグレードしている場合、何も心配することはない点です。その場合、何も変わることはありません。

まだウェブサイトを完全に HTTPS にアップグレードしていない場合は、この作業の優先度を上げる必要があります。ただし、サイトにアクセスするユーザーが HTTP と HTTPS を行き来している場合は、一般的なシナリオとその SameSite Cookie の動作について、以下をお読みください。

警告: 長期的に計画されているのは、サードパーティ Cookie のサポートを完全に廃止し、プライバシーを保護できる手法に置き換えることです。Cookie に SameSite=None; Secure を設定してスキームをまたいで送信できるようにする方法は、完全な HTTPS への移行に向けた一時的なソリューションとしてのみ検討してください。

以下の変更を有効化すると、Chrome と Firefox でテストできます。

  • Chrome 86 以降で、chrome://flags/#schemeful-same-site を有効にします。進捗状況は、Chrome ステータス ページでトラッキングしてください。
  • Firefox 79 以降で、about:config から network.cookie.sameSite.schemeful を true に設定します。進捗状況は、Bugzilla の問題でトラッキングしてください。

Cookie のデフォルトを SameSite=Lax に変更した主な理由の 1 つに、クロスサイト リクエスト フォージェリ（CSRF）に対する保護がありました。しかし、安全でない HTTP トラフィックが存在する場合、ネットワーク攻撃者が Cookie を改ざんし、それを使って安全な HTTPS バージョンのサイトに侵入するチャンスが残ることになります。スキーム間にクロスサイト境界を追加することで、このような攻撃に対する保護を強化できます。

一般的なクロススキーム シナリオ

重要な用語: 以下の例では、すべての URL で site.example などの同じ登録可能ドメインを使用していますが、http://site.example と https://site.example のようにスキームが異なっています。これを、お互いにクロススキームであるといいます。

これまで、クロススキームなウェブサイト間のナビゲーション（たとえば、http://site.example から https://site.example へのリンク）では、SameSite=Strict Cookie の送信が許可されていました。今後、これはクロスサイト ナビゲーションとして扱われます。つまり、SameSite=Strict Cookie はブロックされます。

安全でない HTTP バージョンのサイトから安全な HTTPS バージョンへのリンクを開くことによって発生するクロススキーム ナビゲーションSameSite=Strict Cookie はブロック、SameSite=Lax および SameSite=None; Secure Cookie は許可される。
HTTP から HTTPS へのクロススキーム ナビゲーション
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ ブロック ⛔ ブロック
SameSite=Lax ✓ 許可 ✓ 許可
SameSite=None;Secure ✓ 許可 ⛔ ブロック

サブリソースの読み込み

警告: すべての主要ブラウザは、スクリプトや iframe などのアクティブな Mixed Contents をブロックします。さらに、Chrome や Firefox などのブラウザでは、パッシブな Mixed Contents のアップグレードやブロックに向けた作業が進んでいます。

ここで行う変更は、完全な HTTPS へのアップグレードを進める間の一時的な修正としてのみ検討してください。

サブリソースの例として、イメージ、iframe、XHR や Fetch によるネットワーク リクエストなどがあげられます。

これまで、ページでクロススキーム サブリソースを読み込んだ場合、SameSite=Strict または SameSite=Lax の Cookie の送信や設定が許可されていました。今後、これは他のサードパーティまたはクロスサイトのサブリソースと同じように扱われます。つまり、SameSite=Strict や SameSite=Lax の Cookie はすべてブロックされます。

加えて、ブラウザが安全なページで安全でないスキームからのリソースの読み込みを許可したとしても、サードパーティまたはクロスサイト Cookie には Secure が必須なので、リクエストの Cookie はすべてブロックされます。

安全でない HTTP バージョンに、安全な HTTPS バージョンのサイトのリソースからのクロススキーム サブリソースが含まれている。SameSite=Strict および SameSite=Lax Cookie はブロック、SameSite=None; Secure Cookie は許可される。
HTTPS によるクロススキーム サブリソースを含む HTTP ページ
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ ブロック ⛔ ブロック
SameSite=Lax ⛔ ブロック ⛔ ブロック
SameSite=None;Secure ✓ 許可 ⛔ ブロック

フォームの POST

これまでは、クロススキーム バージョンのウェブサイト間で POST を行った場合、SameSite=Lax または SameSite=Strict が設定された Cookie の送信は許可されていました。今後、これはクロスサイト POST として扱われ、SameSite=None Cookie のみ送信できるようになります。このシナリオは、デフォルトで安全でないバージョンを表示し、ログインまたはチェックアウト用のフォームを送信する際にユーザーを安全なバージョンにアップグレードするサイトで使われている可能性があります。

サブリソースと同じく、リクエストが安全な HTTPS などのコンテキストから安全でない HTTP などのコンテキストに向かう場合、サードパーティまたはクロスサイトの Cookie には Secure が必要になるので、リクエストの Cookie はすべてブロックされます。

警告: ここでの最適なソリューションは、フォームのページと送信先ページの両方で HTTPS などの安全な接続を使うことです。この点は、ユーザーがフォームに機密性の高い情報を入力する場合に特に重要になります。

クロススキームでのフォーム送信。安全でない HTTP バージョンのサイトのフォームが安全な HTTPS バージョンに送信されている。SameSite=Strict および SameSite=Lax Cookie はブロック、SameSite=None; Secure Cookie は許可される。
HTTP から HTTPS へのクロススキーム フォーム送信
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ ブロック ⛔ ブロック
SameSite=Lax ⛔ ブロック ⛔ ブロック
SameSite=None;Secure ✓ 許可 ⛔ ブロック

サイトをテストする方法

Chrome と Firefox では、デベロッパー ツールやメッセージを利用できます。

Chrome 86 以降では、DevTools の [Issue] タブにスキームフル Same-Site の問題が表示されます。サイトで以下の問題が表示される可能性があります。

ナビゲーションに関する問題:

  • "Migrate entirely to HTTPS to continue having cookies sent on same-site requests"—将来のバージョンの Chrome で Cookie がブロックされる予定であることを示す警告。
  • "Migrate entirely to HTTPS to have cookies sent on same-site requests"—Cookie がブロックされたことを示す警告。

サブリソースの読み込みに関する問題:

  • "Migrate entirely to HTTPS to continue having cookies sent to same-site subresources" または "Migrate entirely to HTTPS to continue allowing cookies to be set by same-site subresources"—将来のバージョンの Chrome で Cookie がブロックされる予定であることを示す警告。
  • "Migrate entirely to HTTPS to have cookies sent to same-site subresources" または "Migrate entirely to HTTPS to allow cookies to be set by same-site subresources"—Cookie がブロックされたことを示す警告。後者の警告は、フォームを POST した場合にも表示される可能性があります。

詳しい内容は、スキームフル Same-Site のテストとデバッグに関するヒントにも掲載されています。

Firefox 79 以降で about:config から network.cookie.sameSite.schemeful を true に設定すると、スキームフル Same-Site の問題に関するメッセージがコンソールに表示されます。サイトで以下の内容が表示される可能性があります。

  • "Cookie cookie_name will be soon treated as cross-site cookie against http://site.example/ because the scheme does not match."
  • "Cookie cookie_name has been treated as cross-site against http://site.example/ because the scheme does not match."

FAQ

私のサイトは完全に HTTPS が利用できるようになっていますが、ブラウザの DevTools に問題が表示されるのはなぜですか？

一部のリンクやサブリソースが安全でない URL を指している可能性があります。

この問題を修正する方法の 1 つは、HTTP Strict-Transport-Security（HSTS）と includeSubDomain ディレクティブを使うことです。HSTS と includeSubDomain を使うと、ページに安全でないリンクが意図せずに含まれる場合でも、ブラウザが自動的に安全なバージョンを使ってくれます。

HTTPS にアップグレードできない場合はどうすればよいでしょうか？

サイトを完全に HTTPS にアップグレードしてユーザーを保護することを強くおすすめしますが、ご自身でアップグレードできない場合は、ホスティング プロバイダに相談してアップグレードのオプションを提供できるかを確認してください。セルフホストの場合は、Let's Encrypt が証明書をインストールして設定するためのさまざまなツールを提供しています。また、HTTPS 接続を提供できる CDN やその他のプロキシを経由してサイトにアクセスするように移行することも検討できます。

それでも難しい場合は、影響を受ける Cookie の SameSite 保護の緩和を試します。

  • SameSite=Strict Cookie のみがブロックされる場合は、保護を Lax に下げます。
  • Strict と Lax の両方の Cookie がブロックされ、Cookie が安全な URL に送信される（または安全な URL で設定される）場合は、保護を None に下げます。
    • この回避策は、Cookie の送信先 URL（または設定元 URL）が安全でない場合、失敗します。これは、SameSite=None の Cookie には Secure 属性が必要だからです。つまり、このような Cookie を安全でない接続で送信、設定することは許可されていません。この場合、サイトを HTTPS にアップグレードしなければ Cookie にアクセスすることはできません。
    • サードパーティ Cookie は将来的に廃止される予定なので、これは一時的な対策に過ぎないことを忘れないでください。

SameSite 属性を指定していない場合、Cookie にどのような影響が発生しますか？

SameSite 属性のない Cookie は、SameSite=Lax を指定した場合と同じように扱われ、それと同じクロススキーム動作が適用されます。なお、安全でない手法も一時的に例外として許可されています。詳しくは、SameSite FAQ の Chromium における Lax＋POST 対処法をご覧ください。

WebSocket はどのような影響を受けますか？

ページと同じ安全性が確保されている場合、WebSocket 接続は今後も同一サイトと見なされます。

同一サイト:

  • https:// からの wss:// 接続
  • http:// からの ws:// 接続

クロスサイト:

  • http:// からの wss:// 接続
  • https:// からの ws:// 接続

Reviewed by Eiji Kitamura - Developer Relations Team