スキームフル Same-Site

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

Steven Bingler
Steven Bingler
GitHub
Rowan Merewood

スキームによる同一サイトの判断では、サイト（ウェブサイト）の定義が登録可能なドメインのみからスキーム + 登録可能なドメインに変更されます。詳細と例については、「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 に変更した主な理由の 1 つは、クロスサイト リクエスト フォージェリ（CSRF）から保護するためです。ただし、安全でない HTTP トラフィックは、ネットワーク攻撃者がサイトの安全な HTTPS バージョンで使用される Cookie を改ざんする機会を依然として提供します。スキーム間にこの追加のクロスサイト境界を作成することで、これらの攻撃に対する防御を強化できます。

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

以前は、ウェブサイトのクロススキーム バージョン間を移動する（たとえば、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 ✓ 許可 ⛔ ブロック

サブリソースの読み込み

ここで行う変更は、完全な HTTPS へのアップグレードに取り組む間の一時的な修正と見なす必要があります。

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

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

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

安全でない 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

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

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

安全でない 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 の [問題] タブにスキームによる同一サイトの判断に関する問題が表示されます。サイトで次の問題がハイライト表示されることがあります。

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

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

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

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

詳しくは、Schemeful Same-Site のテストとデバッグに関するヒントをご覧ください。

Firefox 79 以降では、about:config を介して network.cookie.sameSite.schemeful が true に設定されている場合、コンソールに Schemeful 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 を使用すると、ページに安全でないリンクが誤って含まれていても、ブラウザは自動的に安全なバージョンを使用します。

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

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

それでも問題が解決しない場合は、影響を受ける Cookie の SameSite 保護を緩和してみてください。

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

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

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

WebSocket にはどのような影響がありますか？

WebSocket 接続は、ページと同じセキュリティ レベルであれば、引き続き同一サイトと見なされます。

Same-site:

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

クロスサイト:

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