「同一サイト」の定義は 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
に変更した主な理由の一つは、クロスサイト リクエスト フォージェリ(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
または SameSite=Lax
Cookie を送信または設定できましたが、これは、他のサードパーティまたはクロスサイトのサブリソースと同様に扱われるため、SameSite=Strict
または SameSite=Lax
の Cookie がブロックされます。
また、ブラウザで安全でないスキームのリソースを安全なページに読み込むことを許可している場合でも、サードパーティ Cookie またはクロスサイト Cookie では Secure
が必要になるため、こうしたリクエストではすべての Cookie がブロックされます。

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 | 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 は最終的に完全に廃止されるため、これは一時的なものです。
- 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