SameSiteとは

詳細な図解

SameSiteを読むときの前提

SameSiteは、別サイトからのリクエストでCookieを送るかを制御するCookie属性です。CSRF対策、外部IdP連携、決済、SaaS埋め込み、認証付きCORSで重要になります。

実務では、Strict、Lax、Noneの違い、Secure必須条件、トップレベル遷移、POST戻り、iframe、ブラウザ仕様差、CSRFトークンとの併用を確認します。

証跡には、Set-Cookieヘッダー、SameSite値、Secure有無、ログイン/決済/IdP戻りの遷移、Cookie送信有無、ブラウザとバージョンを残します。

Strict、Lax、Noneを使い分ける

SameSite=Strictは別サイト経由の送信を強く抑えます。Laxは通常のリンク遷移などでは送られる場合があり、Noneはクロスサイトでも送る設定です。

防御だけを見てStrictへ寄せると、外部IdPからの戻り、決済完了後の戻り、外部ポータル連携が壊れることがあります。利用者の導線で確認します。

• 認証フローごとにCookie送信を確認する。
• Strict/Lax/Noneの理由を残す。
• NoneにはSecureを付ける。

CSRF対策と混同しない

SameSiteはCSRFリスクを下げる有効な手段ですが、単独で万能ではありません。重要操作ではCSRFトークン、再認証、Origin/Referer確認、認可チェックと組み合わせます。

古いブラウザや特殊なWebViewでは挙動が異なる場合があります。利用者端末が限定される業務アプリでは、実端末で確認します。

• CSRFトークンとの併用を確認する。
• 重要操作で追加確認を設ける。
• 対象ブラウザの挙動を確認する。

SSOとiframeへの影響を見る

SSO、外部IdP、SaaS埋め込み、iframe内アプリでは、クロスサイト文脈でCookieが必要になることがあります。SameSiteを強めるとログインループやセッション切れに見えることがあります。

認証付きCORSでは、SameSite=None; Secure、Credentials、ACAOの明示許可が揃っているかを確認します。Cookie側とCORS側を別々に直すと、片方だけ正常に見えて混乱します。

• IdP戻りとiframe内表示を確認する。
• CredentialsとACAOを同時に見る。
• ログインループの発生条件を記録する。

変更証跡と引き継ぎ

SameSite対応では、Cookie名、値、変更前後の属性、対象フロー、ブラウザ挙動、CSRF対策との関係を残します。認証不具合は再現条件が細かいため、画面遷移単位の証跡が役立ちます。

引き継ぎでは、認証基盤担当、アプリ担当、フロントエンド担当、関連語としてCookie、Set-Cookie、Secure、CORS、CSRFを残すと確認しやすくなります。

• 変更前後のSet-Cookieを保存する。
• SSO戻りと決済戻りを確認する。
• 失敗時のブラウザConsoleを残す。

関連語

同じ主要カテゴリの用語

セキュリティ・認証の学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能