SameSite Cookie について

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

すべての Cookie には、Key-Value ペアに加えて、 使用するタイミングと場所を制御します

SameSite 属性（ RFC6265bis） Cookie をファーストパーティまたは 同一サイト コンテキストです。どのような「サイト」が意味します。 サイトはドメインサフィックスと おすすめします。たとえば、www.web.dev ドメインは web.dev サイトの一部です。

重要な用語: ユーザーが www.web.dev にアクセスして、画像をリクエストする場合 static.web.dev は、同一サイト リクエストです。

公開サフィックス リストでは、 ユーザーです。.com などのトップレベル ドメインだけでなく、 github.io などのサービスを含めることができます。これにより、 your-project.github.io と my-project.github.io を別々のサイトとしてカウントします。

重要な用語: ユーザーが your-project.github.io にアクセスして、画像をリクエストする場合 my-project.github.io: クロスサイト リクエストです。

SameSite 属性を使用して Cookie の使用を宣言する

Cookie の SameSite 属性では、3 通りの方法で 指定できます。属性を指定しないか、 Strict または Lax: Cookie を同一サイト リクエストに制限します。

SameSite を Strict に設定した場合、Cookie は ファーストパーティのコンテキストつまり、Cookie のサイトと表示されたサイトが同じ をクリックします。たとえば、promo_shown Cookie が次のように設定されているとします。

Set-Cookie: promo_shown=1; SameSite=Strict

ユーザーがサイトにアクセスすると、想定どおり Cookie がリクエストとともに送信されます。 ただし、ユーザーが別のリンクからサイトにアクセスした場合は、この Cookie が 最初のリクエストで送信されません これは、機能に関連する Cookie で、常に初期状態のままである パスワードの変更や購入といった操作に加え、 promo_shown のような Cookie に対しては制限的です。読者がリンクをたどる場合 設定を適用できるように Cookie が送信されることを望んでいます。

SameSite=Lax を使用すると、ブラウザはこれらのトップレベルを使用して Cookie を送信できます。 便利です。たとえば、別のサイトがサイトのコンテンツを参照している場合、 猫の写真を使用して記事へのリンクを 次のようになります。

<p>Look at this amazing cat!</p>
<img src="https://blog.example/blog/img/amazing-cat.png" />
<p>Read the <a href="https://blog.example/blog/cat.html">article</a>.</p>

次のように Cookie を Lax に設定します。

Set-Cookie: promo_shown=1; SameSite=Lax

ブラウザが他のユーザーのブログに対する amazing-cat.png をリクエストすると、 サイトが Cookie を送信しないケースですしかし、読者が リンクがサイトの cat.html である場合、そのリクエストに Cookie が含まれます。

この方法で SameSite を使用し、ウェブサイトに影響する Cookie を設定することをおすすめします を Lax に、ユーザーの操作に関連する Cookie を Strict にそれぞれ設定します。

SameSite を None に設定して、Cookie が すべてのコンテキストで送信されます。他のサイトが利用するサービスを さまざまな場所でのウィジェット、埋め込みコンテンツ、アフィリエイト プログラム、広告、ログインを 複数のサイトがある場合は、None を使用してインテントを明確にします。

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

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

SameSite を使用しないデフォルトの動作に対する変更

SameSite 属性は広くサポートされていますが、まだ採用されていません。 これまでは、SameSite を指定せずに Cookie を設定すると、デフォルトで Cookie が送信されていました そのため、ユーザーが CSRF に対して脆弱になり、意図しない 防ぐことができます。デベロッパーに意図を述べてもらうため より安全なユーザーエクスペリエンスの提供 IETF の提案 Cookie の段階的な改善 主な変更点は次の 2 つです

• SameSite 属性が設定されていない Cookie は SameSite=Lax として扱われます。
• SameSite=None を使用する Cookie には、Secure も指定する必要があります。つまり、 保護します。

どちらの変更も、ブラウザが正しく動作するブラウザと下位互換性があります。 以前のバージョンの SameSite 属性が実装されており、 以前のバージョンの SameSite に対応していないブラウザ。その目的は 開発者の負担を減らすブラウザへの依存度をデフォルトの動作として 動作や使用目的が明示されたものであることを意味します。認識できないクライアントや SameSite=None はこれを無視します。

デフォルトで SameSite=Lax

SameSite 属性を指定せずに Cookie を送信すると、ブラウザは その Cookie は、SameSite=Lax が設定されたものとして扱われます。それでも SameSite=Lax を明示的に設定して、ユーザー エクスペリエンスの一貫性を高める ブラウザをまたいでアクセスできます。

SameSite=None は安全である必要があります

SameSite=None を使用してクロスサイト Cookie を作成する場合は、これらも設定する必要があります。 ブラウザが受け入れられるように、Secure にします。

Set-Cookie: widget_session=abc123; SameSite=None; Secure

この動作をテストするには、Chrome 76 の時点で about://flags/#cookies-without-same-site-must-be-secure、Firefox 69 から network.cookie.sameSite.noneRequiresSecure を about:config。

既存の Cookie をできるだけ早く Secure に更新することもおすすめします。 サイトで第三者のコンテンツを提供するサービスを利用している場合は、 サービスプロバイダが Cookie を更新し、スニペットや 新しい動作が使用されるようにします。

クッキーのレシピ SameSite

Cookie を更新してこれらの問題を適切に処理する方法について詳しくは、 SameSite=None への変更とブラウザの動作の違いについては、 フォローアップ記事、SameSite Cookie のレシピ

Lily Chen、Malte Ubl、Mike の協力とフィードバックに感謝します West、Rob Dodson、Tom Steiner、Vivek Sekhar。

Cookie ヒーロー画像 ピルリン プリスク オン スプラッシュを解除