SameSite属性とは?Cookie送信制御でCSRFを防ぐ仕組み

SameSite属性は、Cookieをどんな場面で送るかをブラウザ側で制御し、CSRFの成立条件を崩すための重要な仕組みです。
本記事では、Strict/Lax/Noneの違いと使い分けを図解で整理し、ログイン・決済・外部埋め込みなど用途別にどれを選ぶべきかを解説します。
そもそもCSRFが何か知りたいという方は下記の記事も読んでみてください。
参考記事:【図解】CSRF(クロスサイトリクエストフォージェリ)とは?攻撃の流れと被害例を解説
目次
- SameSite属性とは?
- SameSite属性の基本:Strict/Lax/Noneと使い分けを図解
- SameSite=Lax/Strict/Noneを理解する:CSRF対策と注意点
- SameSite=Noneは要注意:Secure必須とログイン不具合の原因
- まとめ
SameSite属性とは?
SameSite属性とは、Cookieの「他サイトからのリクエストでも送るか」を制御し、csrfを成立しにくくする仕組みです(読み方:セイムサイト)。
HTTPレスポンスヘッダのSet-Cookieに下記の様に設定します。
# Java系などでよくあるセッションCookie例(サーバが発行) Set-Cookie: JSESSIONID=abc; Path=/; HttpOnly; SameSite=Lax # 外部連携・埋め込み等で“クロスサイトでも送る”必要があるCookie例 Set-Cookie: session=xyz; Path=/; Secure; SameSite=None
SameSite属性には設定できる値がいくつかあるので、確認していきましょう。
SameSite属性の基本:Strict/Lax/Noneと使い分けを図解
SameSite属性には、Strict・Lax・Noneの3つの値を設定できます。
SameSite=Strictとは
SameSite=Strictは、クロスサイトではCookieを送らずCSRF攻撃を強く抑止する属性です。

SameSite=Strictは、上の図のように他サイトからのリクエストの場合はCookieを送らないため、一番制御が強い設定値となっています。
SameSite=Laxとは
SameSite=Laxは、クロスサイトでも"リンク遷移など一部"ではCookie送信を許しつつ、他サイト起点のPOST送信など典型的なCSRF攻撃を抑える属性です。

リンク遷移はCookie送信を許可するため、Strictほど厳しくなく、Noneよりは安全寄りの設定値となっています。
SameSite=Noneとは
SameSite=Noneは、クロスサイトでもcookie送信を許可する属性で、strictやlaxでは動かない外部連携・iframe埋め込み等で必要になります。

クロスサイトでもcookie送信を許可するため、CSRF攻撃耐性は下がります。
SameSite=Lax/Strict/Noneを理解する:CSRF対策と注意点
ここまでの説明を読むと、一番CSRF攻撃耐性が強いSameSite=Strictを使用すればよいと思う方も多いかと思いますが、全ての場合においてStrictを使用すればよいという単純な話ではありません。
それぞれの設定値を使用するケースと使い方を覚えておくことが重要です。
Strictで防げること/困ること(UXとのトレードオフ)
SameSite=Strictは、クロスサイトではcookieが送られないため、他サイト起点のリクエストでCSRFが成立しにくいのが強みですが、一方でUX(ユーザー体験)の面では、外部サイトのリンク経由で戻ってきた直後にログインが維持できない等の不具合が起き得ます。
多くのログイン系サイトは、セッションCookieはLaxを基本にし、重要操作はCSRFトークン等と併用して守ります。
Laxで防げること(典型的なフォーム送信の話)
SameSite=Laxとは、他サイト起点のリクエストではcookie送信を制限し、典型的なフォーム送信CSRF(攻撃サイトからPOSTで送金・退会などを実行)を起こしにくくする属性です。
StrictほどUXを壊しにくいので、基本はSameSite=Laxを使用することが推奨されます。
Noneが必要になるケース(外部連携・サードパーティCookie)
SameSite=Noneが必要になるのは、決済・SSO・埋め込みiframeなど外部連携で、別ドメインからでもcookieを送る必要があるケースです。
Noneを使うとCSRF耐性が下がるため、設定する場合はSecure属性を付与することが前提になります。
SameSite=Noneは要注意:Secure必須とログイン不具合の原因
SameSite=NoneはクロスサイトでもCookieを送る設定なので、通信中に盗まれるリスクを下げるためSecure(HTTPS通信のときだけ送信)属性が必須です。
Secure属性がないSameSite=Noneは多くのブラウザで拒否され、Cookieが保存・送信されません。HTTPリクエストヘッダーを設定する際は必ずSameSite=None; Secureのセットで行いましょう。
まとめ
ここまでの内容をまとめると下記の通りです。
- SameSite属性は、Cookieの他サイトからのリクエストでも送るかを制御する仕組み
- Cookieの設定値は、Strict > Lax > None の順番でセキュリティが強い
- StrictはUXの問題があるので、基本はLaxを使用するのが推奨される
- Noneを使用しなければならない場合はSecure属性を付与する
CSRF攻撃対策をする際は、HTTPリクエストヘッダーにSameSite属性付与することも考えていきましょう。





