SameSite 属性とは何か？Strict/Lax/None の挙動と実務での最適運用ガイド
エバープレイ編集部SameSite属性とは何か — 背景と目的
SameSite（サムサイト）属性は、HTTP Cookie に付与できるセキュリティ制御の一つで、ブラウザがどのようなリクエストに対して Cookie を送信するか（送信の可否）を指定します。主な目的は Cross-Site Request Forgery（CSRF）などのクロスサイト攻撃の緩和で、意図しない第三者のウェブページ経由でユーザーの認証 Cookie 等が送信されることを防ぎます。
SameSite の値（Strict / Lax / None）と挙動の違い
SameSite=Strict
完全な同一サイトのみで Cookie を送信します。ユーザーが外部サイトからリンクをクリックして自サイトに遷移した場合でも、クロスサイトのコンテキストとみなされるため Cookie は送信されません。最も制限の強いモードで、CSRF に強い反面、外部サイトからのシングルサインオン（SSO）やページ遷移での利便性を損なうことがあります。SameSite=Lax
中間的なモードです。通常のクロスサイトリクエスト（たとえば、画像・iframe・XHR 等のサブリソース要求）では Cookie を送信しませんが、トップレベルのナビゲーション（ユーザーがリンクをクリックして遷移するような“安全な”GET系の遷移）については Cookie を送信します。多くのセッション Cookie の既定に適したバランスの取れた設定です。SameSite=None
クロスサイトのコンテキストでも常に Cookie を送信します。外部サイトから利用される SSO、埋め込みウィジェット、広告やサードパーティのトラッキングなど、サードパーティコンテキストで Cookie が必要な場合に指定します。ただし、SameSite=None を使う場合は必ずSecure属性を併用し、HTTPS 経由でのみ送信する必要があります（主要ブラウザの実装ルール）。
ブラウザの既定動作と最近の変更（互換性に関する注意）
過去は「SameSite 属性が指定されていない Cookie は明示的にクロスサイトで送信される（つまり “None” 相当）」という実装が一般的でした。しかし、プライバシーとセキュリティ強化のため、主要ブラウザは挙動を変更しました。代表的なものは Chrome によるポリシー変更で、Chrome 80（2020年）以降、SameSite を明示しない Cookie を既定で SameSite=Lax と扱う仕様変更が導入され、また SameSite=None とした Cookie は Secure を必須とする等の強化が行われました。
この変更に伴い、古いブラウザや一部の WebView、古い iOS / Safari などでは SameSite=None を正しく扱えない（あるいは拒否する）実装があり、互換性問題によるログイン切れや埋め込み機能の不具合が発生することがあります。導入時はターゲットとなるクライアント環境での検証が不可欠です。
実際のユースケースと推奨
サイトの一般的なセッション Cookie
多くの場合はSameSite=Laxを推奨します。トップレベルの通常のリンク遷移ではセッションが維持され、画像や埋め込みリクエスト等のサブリソースでは送信されないため、CSRF 緩和とユーザビリティの両立が図れます。SSO や外部ドメインとの連携が必須な Cookie
これらはSameSite=None; Secureを指定する必要があります。例：OAuth のコールバックやクロスサイト iframe 内の認証など。ただし、古いブラウザ互換性に注意。強力に保護したい場合
外部から一切アクセスさせたくない重要な認可用 Cookie などはSameSite=Strictを検討します（利便性とのトレードオフあり）。
Set-Cookie ヘッダ／JavaScript 設定の例
HTTP レスポンスヘッダで設定する例：
Set-Cookie: sessionid=abc123; Path=/; HttpOnly; Secure; SameSite=LaxSet-Cookie: sso=xyz; Path=/; Secure; SameSite=None
JavaScript で document.cookie を使う場合はブラウザ互換に注意し、以下のように属性を付与できます（ただし HttpOnly は JS からは設定不可）：
document.cookie = "name=value; path=/; SameSite=Lax; Secure";
よくある落とし穴と対処法
SameSite=None を指定したが Secure を付け忘れた
Chrome などのブラウザではこれを拒否または既定の挙動（Lax）にフォールバックするため、外部サイトからの呼び出しで Cookie が送られず動作しないことがあります。必ず HTTPS（Secure）を併用してください。古いブラウザの互換性
一部の古いブラウザや組み込み WebView はSameSite=Noneを誤解釈して Cookie を破棄することがあります。必要に応じて UA ベースの回避策（可能ならば）やフォールバック設計を検討します。Analytics / トラッキングとプライバシー
サードパーティ領域で Cookie を使ったトラッキングは SameSite 制限やブラウザのサードパーティ Cookie ブロックの影響を受けます。トラッキングのためにSameSite=Noneを安易に付けるとプライバシー規制やユーザーの信頼を損なう可能性があるため注意が必要です。
デバッグと確認方法
- Chrome DevTools → Application → Cookies の一覧で SameSite 列を確認する。
- レスポンスヘッダの Set-Cookie を確認し、意図した属性が付与されているか検証する。
- 異なるブラウザ・バージョンで実際にクロスサイト遷移／iframe／XHR 等を試し、Cookie が送信されるかを確認する。
実装チェックリスト（導入前に確認すべきこと）
- どの Cookie がクロスサイトで必要かを洗い出す（SSO / API / ウィジェット等）。
- 必要な Cookie には
SameSite=None; Secureを付与する。ただし互換性をテストする。 - セッション Cookie 等は原則
SameSite=Laxを検討。高保護が必要ならStrict。 - HTTP ヘッダの付与に際して HttpOnly / Secure の利用を考慮（XSS 対策や TLS 保護）。
- 主要ブラウザ（Chrome, Firefox, Safari, Edge）での動作確認と、問題が起きた場合のフォールバック設計を準備する。
まとめ
SameSite 属性は、Cookie の送信範囲を制御し CSRF 等のリスクを低減する強力な手段です。一般的なセッションには SameSite=Lax、クロスサイト連携が必要な Cookie には SameSite=None; Secure を使い分けるのが現実的な指針です。一方でブラウザ実装の差分や古い環境の互換性問題があるため、導入時は十分なテストと影響範囲の確認を行ってください。
参考文献
- MDN Web Docs — SameSite (Set-Cookie ヘッダー)
- web.dev — SameSite cookies explained
- Chromium Blog — Enforcing SameSite cookie changes in Chrome 80
- OWASP — CSRF Prevention Cheat Sheet
- Scott Helme — SameSite changes in Chrome 80（解説記事）
投稿者プロフィール
