この記事は、SameSite Cookie 属性変更シリーズの一部です。
SameSite
スキームフル Same-Site は、「サイト」の定義を、「登録可能ドメイン」のみから、「スキーム＋登録可能ドメイン」に変えるものです。詳細や例は、「同一サイト」と「同一オリジン」を理解するをご覧ください。
重要な用語: つまり、http://website.example のような安全でない HTTP バージョンのサイトと、https://website.example のような安全な HTTPS バージョンのサイトが、お互いにクロスサイトと見なされるということです。
うれしいのは、すべてのウェブサイトを既に HTTPS にアップグレードしている場合、何も心配することはない点です。その場合、何も変わることはありません。
まだウェブサイトを完全に HTTPS にアップグレードしていない場合は、この作業の優先度を上げる必要があります。ただし、サイトにアクセスするユーザーが HTTP と HTTPS を行き来している場合は、一般的なシナリオとその SameSite Cookie の動作について、以下をお読みください。
警告: 長期的に計画されているのは、サードパーティ Cookie のサポートを完全に廃止し、プライバシーを保護できる手法に置き換えることです。Cookie に SameSite=None; Secure を設定してスキームをまたいで送信できるようにする方法は、完全な HTTPS への移行に向けた一時的なソリューションとしてのみ検討してください。
SameSite=None; Secure
以下の変更を有効化すると、Chrome と Firefox でテストできます。
chrome://flags/#schemeful-same-site
about:config
network.cookie.sameSite.schemeful
true
Cookie のデフォルトを SameSite=Lax に変更した主な理由の 1 つに、クロスサイト リクエスト フォージェリ（CSRF）に対する保護がありました。しかし、安全でない HTTP トラフィックが存在する場合、ネットワーク攻撃者が Cookie を改ざんし、それを使って安全な HTTPS バージョンのサイトに侵入するチャンスが残ることになります。スキーム間にクロスサイト境界を追加することで、このような攻撃に対する保護を強化できます。
SameSite=Lax
重要な用語: 以下の例では、すべての URL で site.example などの同じ登録可能ドメインを使用していますが、http://site.example と https://site.example のようにスキームが異なっています。これを、お互いにクロススキームであるといいます。
これまで、クロススキームなウェブサイト間のナビゲーション（たとえば、http://site.example から https://site.example へのリンク）では、SameSite=Strict Cookie の送信が許可されていました。今後、これはクロスサイト ナビゲーションとして扱われます。つまり、SameSite=Strict Cookie はブロックされます。
SameSite=Strict
SameSite=None;Secure
警告: すべての主要ブラウザは、スクリプトや iframe などのアクティブな Mixed Contents をブロックします。さらに、Chrome や Firefox などのブラウザでは、パッシブな Mixed Contents のアップグレードやブロックに向けた作業が進んでいます。
ここで行う変更は、完全な HTTPS へのアップグレードを進める間の一時的な修正としてのみ検討してください。
サブリソースの例として、イメージ、iframe、XHR や Fetch によるネットワーク リクエストなどがあげられます。
これまで、ページでクロススキーム サブリソースを読み込んだ場合、SameSite=Strict または SameSite=Lax の Cookie の送信や設定が許可されていました。今後、これは他のサードパーティまたはクロスサイトのサブリソースと同じように扱われます。つまり、SameSite=Strict や SameSite=Lax の Cookie はすべてブロックされます。
加えて、ブラウザが安全なページで安全でないスキームからのリソースの読み込みを許可したとしても、サードパーティまたはクロスサイト Cookie には Secure が必須なので、リクエストの Cookie はすべてブロックされます。
Secure
これまでは、クロススキーム バージョンのウェブサイト間で POST を行った場合、SameSite=Lax または SameSite=Strict が設定された Cookie の送信は許可されていました。今後、これはクロスサイト POST として扱われ、SameSite=None Cookie のみ送信できるようになります。このシナリオは、デフォルトで安全でないバージョンを表示し、ログインまたはチェックアウト用のフォームを送信する際にユーザーを安全なバージョンにアップグレードするサイトで使われている可能性があります。
SameSite=None
サブリソースと同じく、リクエストが安全な HTTPS などのコンテキストから安全でない HTTP などのコンテキストに向かう場合、サードパーティまたはクロスサイトの Cookie には Secure が必要になるので、リクエストの Cookie はすべてブロックされます。
警告: ここでの最適なソリューションは、フォームのページと送信先ページの両方で HTTPS などの安全な接続を使うことです。この点は、ユーザーがフォームに機密性の高い情報を入力する場合に特に重要になります。
Chrome と Firefox では、デベロッパー ツールやメッセージを利用できます。
Chrome 86 以降では、DevTools の [Issue] タブにスキームフル Same-Site の問題が表示されます。サイトで以下の問題が表示される可能性があります。
ナビゲーションに関する問題:
サブリソースの読み込みに関する問題:
詳しい内容は、スキームフル Same-Site のテストとデバッグに関するヒントにも掲載されています。
Firefox 79 以降で about:config から network.cookie.sameSite.schemeful を true に設定すると、スキームフル Same-Site の問題に関するメッセージがコンソールに表示されます。サイトで以下の内容が表示される可能性があります。
cookie_name
http://site.example/
一部のリンクやサブリソースが安全でない URL を指している可能性があります。
この問題を修正する方法の 1 つは、HTTP Strict-Transport-Security（HSTS）と includeSubDomain ディレクティブを使うことです。HSTS と includeSubDomain を使うと、ページに安全でないリンクが意図せずに含まれる場合でも、ブラウザが自動的に安全なバージョンを使ってくれます。
includeSubDomain
サイトを完全に HTTPS にアップグレードしてユーザーを保護することを強くおすすめしますが、ご自身でアップグレードできない場合は、ホスティング プロバイダに相談してアップグレードのオプションを提供できるかを確認してください。セルフホストの場合は、Let's Encrypt が証明書をインストールして設定するためのさまざまなツールを提供しています。また、HTTPS 接続を提供できる CDN やその他のプロキシを経由してサイトにアクセスするように移行することも検討できます。
それでも難しい場合は、影響を受ける Cookie の SameSite 保護の緩和を試します。
Lax
Strict
None
SameSite 属性のない Cookie は、SameSite=Lax を指定した場合と同じように扱われ、それと同じクロススキーム動作が適用されます。なお、安全でない手法も一時的に例外として許可されています。詳しくは、SameSite FAQ の Chromium における Lax＋POST 対処法をご覧ください。
ページと同じ安全性が確保されている場合、WebSocket 接続は今後も同一サイトと見なされます。
同一サイト:
https://
wss://
http://
ws://
クロスサイト:
