スキームフル Same-Site

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

Steven Bingler

Rowan Merewood

注: この記事は、SameSite Cookie 属性の変更に関するシリーズの一部です。これには以下が含まれます。

• Cookie について
• SameSite Cookie の説明
• SameSite Cookie の使用方法

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

重要な用語: これは、あるサイトの安全ではない HTTP バージョン（例: http://website.example）と安全な HTTPS バージョンであるサイト（https://website.example）が互いにクロスサイトと見なされることを意味します。

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

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

警告: 長期的な計画では、サードパーティ Cookie のサポートを段階的に廃止し、プライバシー保護の代替手段に置き換える予定です。Cookie に SameSite=None; Secure を設定してスキームをまたいで送信できるようにすることは、完全な HTTPS への移行における一時的な解決策と見なされます。

これらの変更は、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 バージョンの サイトをご覧ください。スキーム間にこの追加のクロスサイト境界を作成することで、 これらの攻撃に対する防御を強化する必要があります。

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

重要な用語: 以下の例では、URL がすべて同じ登録可能なドメイン（例:site.example はありますが、スキームが異なります（http://site.example と https://site.example など）。これらは互いにクロス スキームと呼ばれます。

ナビゲーション

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

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

</ph> HTTP から HTTPS へのクロススキーム ナビゲーション。

	HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ ブロック	⛔ ブロック
SameSite=Lax	✓ 許可	✓ 許可
SameSite=None;Secure	✓ 許可	⛔ ブロック

サブリソースを読み込んでいます

警告: すべての主要なブラウザでは、スクリプトや iframe などのアクティブな混合コンテンツがブロックされます。また、Chrome や Firefox などのブラウザでは、パッシブな混合コンテンツのアップグレードまたはブロックに取り組んでいます。

ここで加えた変更は、移行期間中の一時的な修正としてのみ 完全な HTTPS へのアップグレードを検討中です

サブリソースの例としては、画像、iframe、ネットワーク リクエストなど、 XHR または Fetch を使用します。

ページにクロススキーム サブリソースを読み込むと、これまでは SameSite=Strict または SameSite=Lax 個の Cookie を送信または設定します。これで、 他のサードパーティやクロスサイト サブリソースと同様に扱われ、 SameSite=Strict または SameSite=Lax の Cookie がすべてブロックされます。

また、たとえブラウザが安全でないスキームからリソースへのアクセスを 安全なページに読み込まれると、すべての Cookie がブロックされます。 サードパーティ Cookie またはクロスサイト Cookie を使用するには、Secure が必要です。

<ph type="x-smartling-placeholder">

</ph> <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 が必要です。

警告: この場合の最善の解決策は、フォームページとリンク先の両方が HTTPS などの安全な接続上にあることを確認することです。これは、ユーザーがフォームに機密情報を入力する場合に特に重要です。

で確認できます。 <ph type="x-smartling-placeholder">

</ph>

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 オン スプラッシュを解除