図解 SameSite@Set-Cookie

こんにちは、プラットフォームエンジニアの中山です。

詳細な仕様は RFC 等を参照頂くとして、今回は記憶と印象への残りやすさを目標に図解シリーズ（… といっても 2 本ですが）なるスタイルの試みです。

図解 Domain@Set-Cookie
図解 SameSite@Set-Cookie ※ 本記事

早速ですが応答ヘッダの Set-Cookie に付随する SameSite 属性の値と User-Agent（ブラウザ）から送信される Cookie の関係性を図にしてみました。矢印上にお菓子のクッキーが記載されているリクエストは Cookie が送信されることを示しています。

ここまでで大事な部分はお伝えできましたので笑、残りは細かなユースケースで悩みをお持ちの方に読んで頂ければと思います。

SameSite=Strict における GET での流入

図の赤い背景部分について補足します。

SameSite の判定には以下のルールがあります。

The request is not the result of a cross-site redirect. That is, the origin of every url in the request's url list is same-site with the request's current url's origin.

The request is not the result of a reload navigation triggered through a user interface element (as defined by the user agent; e.g., a request triggered by the user clicking a refresh button on a toolbar).

The request's current url's origin is same-site with the request's client's "site for cookies" (which is an origin), or if the request has no client or the request's client is null.

そこでこちらのテストを試してみたところ、以下のような結果でした。

SameSite=Strict を用いつつも一部の流入経路で暫定的に Cookie を送信させたい、という場合には location.href を用いた client-side redirect（表の 1-4）の利用をご検討ください。

その他のユースケースについては以下のような結果でした。

POST での流入

図の赤い背景部分について補足します。

外部サイトからも POST を許可したいフォームがあった場合、SameSite=Strict なログインセッション Cookie や SameSite=Lax なトラッキング Cookie がフォームに送信されません。加えて流入のタイミングでトラッキング Cookie が上書きされてしまう場合があります。

POST での流入時に Cookie を送信させたい場合のアイデアは GET の場合と同様で、ステータスコード 307 / 308 の server-side redirect を経由しても Cookie は送信されないため client-side redirect（表の 4-4）の利用をご検討ください。流入元で POST された情報を埋め込んだフォームを生成し HTMLFormElement.submit() する … というのが GET の場合と比較すると面倒ですね。

その他のユースケースについては以下のような結果でした。

SameSite=None なら機会損失なし？

図の赤い背景部分について補足します。

遠からず 3rd-party Cookie が廃止され CSRF のリスクも小さくなるので、今は制約条件の少ない SameSite=None にしておけばいいじゃないか … という考え方もあるかもしれませんが、ブラウザのプライバシー関連機能で SameSite=None は不利な扱いを受ける可能性があります。例えば Cookie 削除の UI に「全ての Cookie」と「3rd-party Cookie」の 2 つを設け、後者については SameSite=None の Cookie を削除する、といった具合です。

こちらの記事もご参考まで。

このようなリスクも考慮の上で採用をご検討ください。

p.s.

蛇足ですが 4 年前にもこんな予想をしていました ^^;