判断基準

認証 Cookie の SameSite を None にすると、あらゆるクロスサイト文脈で Cookie が自動添付され CSRF の余地が広がる。フロントと API が同一の登録可能ドメイン配下のサブドメイン（例: app.example.com と api.example.com）であれば same-site 扱いになるため、SameSite=Lax でも通常のリクエストで Cookie は送信される。したがってこの構成では None ではなく Lax（必要なら Strict）を既定にする。

None が本当に必要なのは、Cookie を別サイト（別の登録ドメイン）から送る要件があるときだけ。安易に None; Secure にしない。

落とし穴

CORS のプリフライトは「単純リクエスト」には発生しない。application/x-www-form-urlencoded などの単純リクエストはプリフライトされず送信が成立するため、CORS 設定だけでは状態変更の CSRF を防げない。サーバーが Content-Type を見てフォームバインドする実装だと、悪意あるサイトの自動送信フォームから副作用付き POST が通りうる。

対策と検証

• 第一には認証 Cookie を SameSite=Lax/Strict にする。
• クロスサイトの状態変更を許す要件がある場合は CSRF トークン、またはカスタムヘッダ必須化でプリフライトを強制する。
• 検証では、別オリジンの HTML から自動送信フォーム（フォームエンコード）で状態変更 API を叩き、Cookie が送られず操作が失敗することを確認する。