SameSite Cookie とは何か - Lax / Strict / None の違い

SameSite とは

SameSite は、Cookieをクロスサイトリクエストで送るかどうかを制御する属性です。

Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax

CSRF対策やサードパーティCookie制限を理解するうえで重要な属性です。

site と origin の違い

SameSite を理解するには、site と origin の違いが重要です。

たとえば、次の2つはオリジンは違います。

• https://app.example.com
• https://api.example.com

しかし、どちらも example.com 配下なので、同一siteとして扱われる場面があります。

Strict

SameSite=Strict は、もっとも厳しい設定です。

Set-Cookie: session_id=abc123; SameSite=Strict

別サイトからの遷移やリクエストでは、Cookieを送らない方向に働きます。

セキュリティは強いですが、外部リンクからログイン済みページへ遷移したときにログイン状態が反映されないなど、ユーザー体験に影響が出ることがあります。

Lax

SameSite=Lax は、現実的によく使われる設定です。

Set-Cookie: session_id=abc123; SameSite=Lax

多くのクロスサイトPOSTではCookieを送りません。一方、トップレベルのGETナビゲーションではCookieを送る場面があります。

通常のログインセッションでは、Lax が使いやすい初期値になります。

None

SameSite=None は、クロスサイトでもCookieを送る設定です。

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

SameSite=None を使う場合、多くのブラウザでは Secure が必須です。つまりHTTPSでのみ送る必要があります。

外部IdP、埋め込みウィジェット、別サイトをまたぐSSOなどで必要になることがあります。ただし、サードパーティCookie規制の影響を受けやすい領域です。

CSRF 対策としての SameSite

CSRFは、Cookieが自動送信される性質を利用する攻撃です。

SameSite=Lax や Strict は、クロスサイトからのCookie送信を抑えることでCSRFを軽減します。

ただし、SameSiteだけに依存するのは危険です。

• GETで状態変更する設計は危険
• OAuthコールバックなどはトップレベル遷移になりやすい
• login CSRF のような問題は残る
• ブラウザや構成によって挙動を理解する必要がある

CSRFトークンや Origin 検証も併用します。

どれを選ぶべきか

一般的な目安は次の通りです。

アプリの構成によって正解は変わります。特に、フロントエンドとAPIが同一siteか、完全に別siteかで判断が変わります。

まとめ

SameSite は、Cookieをクロスサイトリクエストで送るかを制御する属性です。

• Strict は厳しいがUXに影響することがある
• Lax は多くの通常セッションで使いやすい
• None はクロスサイト送信を許可し、Secure が必要
• SameSite はCSRFを軽減するが万能ではない
• CSRFトークンやOrigin検証も併用する

参考リソース

• 公式ドキュメント - SameSite Cookie とは何か - Lax / Strict / None の違い を確認するための一次情報

次に読む記事

• CSRF とは何か
• CORS と Cookie
• Cookie の仕組み

×

PR

×

PR