SameSite Cookie について

Rowan Merewood

すべての Cookie には、Key-Value ペアと、その Cookie がいつどこで使用されるかを制御するいくつかの属性が含まれています。

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 を使用して意図を明確にします。

SameSite を指定しない場合のデフォルトの動作の変更

SameSite 属性は広くサポートされていますが、広く採用されていません。以前は、SameSite を指定せずに Cookie を設定すると、デフォルトですべてのコンテキストで Cookie が送信されるため、ユーザーは CSRF や意図しない情報漏洩に対して脆弱でした。デベロッパーが意図を表明し、ユーザーに安全なエクスペリエンスを提供することを促すため、IETF の提案である Incrementally Better Cookies では、次の 2 つの重要な変更が規定されています。

• SameSite 属性が設定されていない Cookie は SameSite=Lax として扱われます。
• SameSite=None を含む Cookie には Secure も指定する必要があります。つまり、セキュアなコンテキストが必要です。

どちらの変更も、以前のバージョンの SameSite 属性を正しく実装しているブラウザや、以前の SameSite バージョンをサポートしていないブラウザとの下位互換性があります。これらは、Cookie の動作と意図された用途を明示することで、ブラウザのデフォルトの動作へのデベロッパーの依存を減らすことを目的としています。SameSite=None を認識しないクライアントは、これを無視する必要があります。

デフォルトで SameSite=Lax

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

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

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

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

この動作は、Chrome 76 以降では about://flags/#cookies-without-same-site-must-be-secure を有効にすることで、Firefox 69 以降では about:config で network.cookie.sameSite.noneRequiresSecure を設定することでテストできます。

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

SameSite のクッキーのレシピ

SameSite=None の変更とブラウザの動作の違いに適切に対応するために Cookie を更新する方法について詳しくは、SameSite Cookie のレシピをご覧ください。

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