「同一サイト」の定義は URL スキームを含むように進化しており、サイトの HTTP バージョンと HTTPS バージョン間のリンクはクロスサイト リクエストとしてカウントされるようになりました。可能な限り問題を回避するために、デフォルトで HTTPS にアップグレードするか、必要な SameSite 属性値の詳細をご覧ください。
計画的 Same-Site は(ウェブサイト)の定義を、登録可能なドメインから スキーム + 登録可能なドメインです。詳細と例については、 「同一サイト」についておよび "same-origin"。
ただし、ウェブサイトがすでに HTTPS に完全にアップグレードされている場合は、 何も気にする必要はありません。これについては何も変更されません。
ウェブサイトを完全にアップグレードしていない場合は、こちらを選択してください。
しかし、ユーザーが HTTP と HTTP の 2 つのパスの間で
HTTPS の場合、これらの一般的なシナリオの一部と、関連する SameSite
Cookie
概要を以下に示します。
これらの変更は、Chrome と Firefox の両方でテストするために有効にできます。
- Chrome 86 以降では、
about://flags/#schemeful-same-site
を有効にしてください。進捗状況の管理 Chrome のステータス ページをご覧ください。 - Firefox 79 から、
network.cookie.sameSite.schemeful
をtrue
に設定します。about:config
。Bugzilla で進捗を確認 確認します。
デフォルトとして SameSite=Lax
に変更した主な理由の 1 つは、
Cookie は、クロスサイト リクエスト フォージェリ(偽のサイト リクエスト フォージェリ)から
(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 は許可されます。](https://web.dev/static/articles/schemeful-samesite/image/a-cross-scheme-navigation-209071cf80318.png?authuser=0000&hl=ja)
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
が必要です。
![サイトの安全な HTTPS バージョンが安全でない HTTP バージョンに含まれているリソースから生成されるクロススキーム サブリソース。SameSite=Strict と SameSite=Lax Cookie をブロック、SameSite=None;安全な Cookie は許可されます。](https://web.dev/static/articles/schemeful-samesite/image/a-cross-scheme-subresourc-ee291fec730b8.png?authuser=0000&hl=ja)
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ ブロック | ⛔ ブロック |
SameSite=Lax
|
⛔ ブロック | ⛔ ブロック |
SameSite=None;Secure
|
✓ 許可 | ⛔ ブロック |
フォームの POST
複数のスキームにまたがるバージョンのウェブサイト間で投稿する場合、以前は許可されていました。
SameSite=Lax
または SameSite=Strict
で設定された Cookie を送信します。これで、
クロスサイト POST として扱われます。送信できる Cookie は SameSite=None
件のみです。。
安全でないバージョンをデフォルトで表示しているサイトで、このシナリオが発生する
ただし、ログインまたは認証の送信時に、ユーザーを安全なバージョンにアップグレードする
。
サブリソースと同様に、リクエストが安全なもの(たとえば、HTTPS 経由で
安全性が低い、たとえばHTTP、コンテキストの場合は、これらのリクエストですべての Cookie がブロックされます。
サードパーティ Cookie またはクロスサイト Cookie には Secure
が必要です。
![サイトの安全でない HTTP バージョンのフォームから安全な HTTPS バージョンに送信されることによる、クロス スキーム フォーム送信。SameSite=Strict と SameSite=Lax Cookie をブロック、SameSite=None;安全な Cookie は許可されます。](https://web.dev/static/articles/schemeful-samesite/image/a-cross-scheme-form-submi-528e4c1eb4c83.png?authuser=0000&hl=ja)
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ ブロック | ⛔ ブロック |
SameSite=Lax
|
⛔ ブロック | ⛔ ブロック |
SameSite=None;Secure
|
✓ 許可 | ⛔ ブロック |
サイトをテストするにはどうすればよいですか?
デベロッパー ツールとメッセージは Chrome と Firefox で利用できます。
Chrome 86 以降では、[問題] タブを DevTools が スキームによる Same-Site の問題を含める。以下の問題がハイライト表示される可能性があります おすすめします
ナビゲーションに関する問題:
- 「同じサイトで Cookie を引き続き送信できるように、完全に HTTPS に移行する 」 - 今後のバージョンで Cookie がブロックされるという警告 説明します。
- 「同一サイトのリクエストで Cookie が送信されるように、完全に HTTPS に移行する」 Cookie がブロックされたという警告が表示される。
サブリソースの読み込みに関する問題:
- 「Cookie が引き続き同じサイトに送信されるように、完全に HTTPS に移行する サブリソース」または「完全に HTTPS に移行して Cookie の許可を継続する」 同じサイトのサブリソースによって設定される」 - Cookie が 今後のバージョンでブロックされます。
- 「Cookie を同じサイトのサブリソースに送信するため、完全に HTTPS に移行する」 または「完全に HTTPS に移行して同じサイトで Cookie を設定できるようにする subresources" - Cookie がブロックされているという警告が表示されます。後者 フォームを POST する際にも警告が表示されることがあります。
詳しくは、スキームのテストとデバッグのヒントをご覧ください。 Same-Site をご覧ください。
Firefox 79 から、network.cookie.sameSite.schemeful
を true
に設定、
about:config
: コンソールにスキームフル Same-Site の問題に関するメッセージが表示されます。
サイトには以下のように表示されます。
- "Cookie
cookie_name
はまもなくクロスサイト Cookie としてhttp://site.example/
」と表示されます。 - "Cookie
cookie_name
はに対してクロスサイトとして扱われていますhttp://site.example/
」と表示されます。
よくある質問
サイトはすでに HTTPS で完全に利用可能になっていますが、ブラウザの DevTools で問題が発生するのはなぜですか?
一部のリンクとサブリソースが、保護されていないリンクやサブリソースを指している可能性があります。 できます。
この問題を解決する方法の一つは、HTTP
Strict-Transport-Security
(HSTS)と includeSubDomain
ディレクティブ。HSTS + includeSubDomain
あり
いずれかのページに誤って安全でないリンクが含まれていた場合、ブラウザは
代わりに安全なバージョンが自動的に使用されます。
HTTPS にアップグレードできない場合はどうすればよいですか?
サイトを完全に HTTPS にアップグレードして、 ユーザーを保護します。ご自身で実施できない場合は、 ホスティング プロバイダに相談して、このオプションを提供できるかどうかを確認してください。セルフホストの場合は Let's Encryptでは 構成する必要があります。サイトの移転について調査することも HTTPS 接続を提供できる CDN やその他のプロキシの背後に配置できます。
それでもできない場合は、SameSite
の保護を緩和してみてください
できます。
SameSite=Strict
個の Cookie しかブロックされていない場合は、次の値を下げることができますLax
への保護。Strict
とLax
の両方の Cookie がブロックされており、 セキュア URL に送信される(またはセキュア URL から設定される)Cookie をNone
への保護。- この回避策は失敗: Cookie の送信先 URL(または
安全ではありません。これは、
SameSite=None
では次が必要となるためです。 Cookie のSecure
属性により、それらの Cookie の送信や削除が セキュリティで保護されません。この場合 その Cookie をクロールしないようご注意ください。 - なお、これは一時的なものであり、最終的にサードパーティ Cookie は 完全に廃止されました
- この回避策は失敗: Cookie の送信先 URL(または
安全ではありません。これは、
SameSite
属性を指定していない場合、Cookie にどのように影響しますか?
SameSite
属性のない Cookie は、指定されたものとして扱われます。
SameSite=Lax
と同じクロススキーム動作がこれらの Cookie に適用されます。
あります安全でないメソッドに対する一時的な例外は引き続き適用されます。詳しくは以下をご覧ください。
Chromium の Lax + POST 軽減策SameSite
よくある質問をご覧ください。
WebSocket への影響
WebSocket 接続が同じ場合は、引き続き同じサイトとみなされる 重要です
同一サイト:
https://
からのwss://
の接続http://
からのws://
の接続
クロスサイト:
http://
からのwss://
の接続https://
からのws://
の接続
写真提供: Julissa Capdevilla オン スプラッシュを解除