スキームフル Same-Site

「同一サイト」の定義は URL スキームを含むよう進化しており、サイトの HTTP バージョンと HTTPS バージョン間のリンクはクロスサイト リクエストとしてカウントされるようになりました。可能な限り問題を回避するためにデフォルトで HTTPS にアップグレードするか、必要な SameSite 属性値の詳細を確認してください。

スティーブン ビングラー
Steven Bingler
GitHub
Rowan Merewood 氏
Rowan Merewood
Twitter GitHub Glitch Mastodon

スキームフル Same-Site は、（ウェブ）サイトの定義を、登録可能なドメインのみからスキーム + 登録可能なドメインに変更します。詳細と例については、「same-site」と「same-origin」についてをご覧ください。

幸いなことに、ウェブサイトがすでに HTTPS に完全にアップグレードされている場合は、何も心配する必要はありません。何も変更されません。

まだウェブサイトを完全にアップグレードしていない場合は、このアップグレードを優先してください。ただし、サイトを訪れたユーザーが HTTP から HTTPS に移行する場合のよくあるケースと、それに関連する SameSite Cookie の動作について以下に説明します。

これらの変更は、Chrome と Firefox の両方でテストするために有効にできます。

  • Chrome 86 以降、about://flags/#schemeful-same-site を有効にします。Chrome のステータス ページで、進行状況を確認できます。
  • Firefox 79 以降では、about:config を使用して network.cookie.sameSite.schemeful を true に設定します。Bugzilla の問題で進捗状況を追跡します。

Cookie のデフォルトを SameSite=Lax に変更した主な理由の一つは、クロスサイト リクエスト フォージェリ（CSRF）を防ぐためです。ただし、安全でない HTTP トラフィックでも、ネットワーク攻撃者が Cookie を改ざんする機会があります。Cookie は、安全な HTTPS バージョンのサイトで使用されます。スキーム間にクロスサイト境界を追加することにより、こうした攻撃に対する防御を強化できます。

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

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

サイトの安全でない HTTP バージョン上のリンクをたどって、安全な HTTPS バージョンに移動することでトリガーされる、スキーム間のナビゲーション。SameSite=Strict Cookie をブロック、SameSite=Lax、SameSite=None。セキュア Cookie を許可。
HTTP から HTTPS へのスキームをまたいだナビゲーション。
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ ブロック済み ⛔ ブロック済み
SameSite=Lax ✓ 許可 ✓ 許可
SameSite=None;Secure ✓ 許可 ⛔ ブロック済み

サブリソースを読み込んでいます

ここで行った変更は、完全な HTTPS にアップグレードする際の一時的な修正とみなす必要があります。

サブリソースの例としては、XHR または Fetch で作成された画像、iframe、ネットワーク リクエストなどがあります。

これまでは、ページでクロススキーム サブリソースを読み込むと、SameSite=Strict または SameSite=Lax Cookie を送信または設定できましたが、これは、他のサードパーティまたはクロスサイトのサブリソースと同様に扱われるため、SameSite=Strict または SameSite=Lax の Cookie がブロックされます。

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

セキュリティで保護された HTTPS バージョンのリソースが安全でない HTTP バージョンに含まれていることに起因するクロススキーム サブリソース。SameSite=Strict と SameSite=Lax Cookie をブロックし、SameSite=None; セキュア Cookie を許可する。
HTTPS を介した、クロススキーム サブリソースを含む HTTP ページ。
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ ブロック済み ⛔ ブロック済み
SameSite=Lax ⛔ ブロック済み ⛔ ブロック済み
SameSite=None;Secure ✓ 許可 ⛔ ブロック済み

フォームの送信

以前は、ウェブサイトのクロススキーム バージョン間で投稿を行うと、SameSite=Lax または SameSite=Strict で設定された Cookie を送信できました。現在、これはクロスサイト POST として扱われ、SameSite=None Cookie のみを送信できます。このシナリオは、デフォルトで安全でないバージョンを提示しているサイトで、ログインまたはチェックアウト フォームの送信時にユーザーを安全なバージョンにアップグレードする場合に発生することがあります。

サブリソースと同様に、安全なリクエスト（HTTPS など）から安全でない場所（HTTP など）に送信されるリクエストでは、サードパーティ Cookie またはクロスサイト Cookie で Secure が必要になるため、すべての Cookie がブロックされます。

安全でない HTTP バージョンのフォームから安全な HTTPS バージョンに送信される、クロススキーム フォームの送信。SameSite=Strict と SameSite=Lax Cookie をブロックし、SameSite=None; セキュア Cookie を許可する。
HTTP から HTTPS へのクロススキーム フォーム送信。
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ ブロック済み ⛔ ブロック済み
SameSite=Lax ⛔ ブロック済み ⛔ ブロック済み
SameSite=None;Secure ✓ 許可 ⛔ ブロック済み

サイトをテストする方法

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

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

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

  • 「HTTPS に完全移行して、同一サイトのリクエストで引き続き Cookie を送信する」 - Chrome の今後のバージョンでは Cookie がブロックされるという警告が表示されます。
  • 「完全に HTTPS に移行して、同じサイトのリクエストで Cookie を送信する」 - Cookie がブロックされているという警告が表示されます。

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

  • 「HTTPS に完全移行して、引き続き同じサイトのサブリソースに Cookie を送信する」または「HTTPS に完全移行して、同一サイトのサブリソースによる Cookie の設定を引き続き許可する」- Chrome の今後のバージョンでは Cookie がブロックされるという警告が表示されます。
  • 「HTTPS に完全に移行して、Cookie を同じサイトのサブリソースに送信する」または「完全に HTTPS に移行して、同じサイトのサブリソースで Cookie を設定できるようにする」- Cookie がブロックされているという警告が表示されます。後者の警告は、フォームを POST する際にも表示されます。

詳しくは、スキームフルな同一サイトのテストとデバッグのヒントをご覧ください。

Firefox 79 以降では、about:config で network.cookie.sameSite.schemeful を true に設定すると、スキームフル Same-Site の問題に関するメッセージがコンソールに表示されます。サイトに次のように表示されます。

  • 「Cookie cookie_name は、スキームが一致しないため、http://site.example/ に対するクロスサイト Cookie としてすぐに扱われます。」
  • 「Cookie cookie_name は http://site.example/ に対するクロスサイトとして扱われています（スキームが一致しないため）。」

よくある質問

サイトはすでに HTTPS で利用可能です。ブラウザの DevTools に問題があります。なぜですか？

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

この問題を解決する 1 つの方法は、HTTP Strict-Transport-Security（HSTS）と includeSubDomain ディレクティブを使用することです。HSTS + includeSubDomain を使うと、安全ではないリンクがページの 1 つに誤って含まれていたとしても、ブラウザは自動的に安全なバージョンを使用します。

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

Google は、ユーザーを保護するためにサイトを完全に HTTPS にアップグレードすることを強くおすすめしますが、ご自身でアップグレードできない場合は、ホスティング プロバイダに相談して、HTTPS へのアップグレードが可能かどうか確認することをおすすめします。セルフホストの場合、Let's Encrypt には証明書をインストールして構成するためのさまざまなツールがあります。HTTPS 接続を提供できる CDN やその他のプロキシの背後にサイトを移動する調査もできます。

それができない場合は、影響を受ける Cookie に対する SameSite の保護を緩和してみてください。

  • SameSite=Strict Cookie のみがブロックされている場合は、保護を Lax に下げることができます。
  • Strict と Lax の両方の Cookie がブロックされ、Cookie が安全な URL に送信（または設定）されている場合は、保護機能を None に下げることができます。
    • Cookie の送信先（または設定元）の URL が安全でない場合、この回避策は失敗します。これは、SameSite=None では Cookie に Secure 属性が必須であるため、そうした Cookie が安全でない接続を介して送信または設定されることはないからです。この場合、サイトが HTTPS にアップグレードされるまで、その Cookie にはアクセスできません。
    • なお、サードパーティ Cookie は最終的に完全に廃止されるため、これは一時的なものです。

SameSite 属性を指定していない場合の Cookie への影響

SameSite 属性がない Cookie は SameSite=Lax を指定したものとして扱われ、これらの Cookie にも同じクロススキームの動作が適用されます。なお、安全でないメソッドに対する一時的な例外は引き続き適用されます。詳しくは、Chromium の SameSite に関するよくある質問の Lax + POST の軽減策をご覧ください。

WebSocket への影響

WebSocket 接続は、ページと同じ安全性であれば、引き続き同一サイトとみなされます。

同一サイト:

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

クロスサイト:

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

写真撮影: Julissa Capdevilla、出典: Unsplash