「同一サイト」の定義は URL スキームを含むように進化しており、サイトの HTTP バージョンと HTTPS バージョン間のリンクはクロスサイト リクエストとしてカウントされます。可能な限り問題を回避するために、デフォルトで HTTPS にアップグレードしてください。必要な SameSite 属性値の詳細については、以下をご確認ください。
スキームフル 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 | 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 がブロックされます。
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 | 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 は最終的に完全に廃止されるため、これは一時的なものです。
- Cookie の送信先(または設定元)の URL が安全でない場合、この対応策は失敗します。これは、
SameSite
属性を指定していない場合、Cookie にはどのような影響がありますか?
SameSite
属性のない Cookie は、SameSite=Lax
が指定されているかのように扱われ、これらの Cookie に同じスキーム間の動作が適用されます。なお、安全でないメソッドに対する一時的な例外は引き続き適用されます。詳しくは、Chromium の SameSite
に関するよくある質問の Lax + POST の軽減策をご覧ください。
WebSocket への影響
WebSocket 接続は、ページと同じセキュリティであれば、同一サイトとみなされます。
同一サイト:
https://
からwss://
接続http://
からws://
接続
クロスサイト:
http://
からwss://
接続https://
からws://
接続
撮影者: Julissa Capdevilla、出典: Unsplash より