スキームフル Same-Site

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

Steven Bingler
Steven Bingler
GitHub
Rowan Merewood

計画的 Same-Site は（ウェブサイト）の定義を、登録可能なドメインから スキーム + 登録可能なドメインです。詳細と例については、 「同一サイト」についておよび "same-origin"。

ただし、ウェブサイトがすでに HTTPS に完全にアップグレードされている場合は、 何も気にする必要はありません。これについては何も変更されません。

ウェブサイトを完全にアップグレードしていない場合は、こちらを選択してください。 しかし、ユーザーが HTTP と HTTP の 2 つのパスの間で HTTPS の場合、これらの一般的なシナリオの一部と、関連する SameSite Cookie 概要を以下に示します。

これらの変更は、Chrome と Firefox の両方でテストするために有効にできます。

デフォルトとして SameSite=Lax に変更した主な理由の 1 つは、 Cookie は、クロスサイト リクエスト フォージェリ（偽のサイト リクエスト フォージェリ）から （CSRF）。ただし、 安全でない HTTP トラフィックは、ネットワーク攻撃者にとって Cookie を改ざんして、その Cookie を安全な HTTPS バージョンの サイトをご覧ください。スキーム間にこの追加のクロスサイト境界を作成することで、 これらの攻撃に対する防御を強化する必要があります。

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

ウェブサイトのクロス スキーム バージョン間の移動（例: http://site.example を https://site.example にマッピング）にすることで、 SameSite=Strict 個の Cookie が送信されます。現在はクロスサイトとして 移動され、SameSite=Strict 個の Cookie がブロックされます。

<ph type="x-smartling-placeholder">
</ph> サイトの安全でない HTTP バージョンから安全な HTTPS バージョンへのリンクをたどることによってトリガーされるクロス スキーム ナビゲーション。SameSite=Strict Cookie をブロック、SameSite=Lax、SameSite=None;安全な Cookie は許可されます。 <ph type="x-smartling-placeholder">
</ph> 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 が必要です。

<ph type="x-smartling-placeholder">
</ph> サイトの安全な HTTPS バージョンが安全でない HTTP バージョンに含まれているリソースから生成されるクロススキーム サブリソース。SameSite=Strict と SameSite=Lax Cookie をブロック、SameSite=None;安全な Cookie は許可されます。 <ph type="x-smartling-placeholder">
</ph> HTTPS によるクロス スキーム サブリソースを含む HTTP ページ。
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 が必要です。

で確認できます。 <ph type="x-smartling-placeholder">
</ph> サイトの安全でない 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 が スキームによる 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 は 完全に廃止されました

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

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

WebSocket への影響

WebSocket 接続が同じ場合は、引き続き同じサイトとみなされる 重要です

同一サイト:

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

クロスサイト:

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

写真提供: Julissa Capdevilla オン スプラッシュを解除