スキームフル Same-Site

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

スティーブン・ビングラー
Steven Bingler
GitHub
Rowan Merewood 氏

スキームフル 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 に変更した主な理由の 1 つは、クロスサイト リクエスト フォージェリ（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 Cookie または 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 ✓ 許可 ⛔ ブロック済み

フォームの POST

スキームをまたいだウェブサイトの投稿では、以前は 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 の問題が追加されます。サイトで次の問題がハイライト表示されている場合があります。

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

  • 「同じサイトのリクエストで引き続き Cookie が送信されるようにするには、HTTPS に完全に移行してください」- 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 にアップグレードできない場合はどうすればよいですか？

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

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

  • SameSite=Strict Cookie のみがブロックされている場合は、保護レベルを Lax に下げることができます。
  • Strict と Lax の両方の Cookie がブロックされており、Cookie が安全な URL に送信（または安全な 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 より