【要約】CSRFの仕組みを丁寧に解説 — なぜCookieだけでは「本人からのリクエスト」と言えないのか [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
Web開発者が、Cookieによる認証のみに依存した設計を行うことで、意図しないリクエストを許してしまう問題がある。攻撃者はユーザーのセッション情報を盗むことなく、ブラウザの挙動を利用して正規のリクエストを偽装できる。
- ・ブラウザがドメインごとにCookieを自動付与する仕様。
- ・攻撃者が用意した悪意あるサイトから、正規サイトへリクエストを強制送信できる点。
- ・サーバー側が「Cookieの有無」のみでリクエストの正当性を判断してしまう設計ミス。
// Approach
開発者は、リクエストの正当性を検証するために、トークン発行とCookie属性制御の二つの手法を採用する。
- ・CSRFトークン方式: サーバーが発行したランダムな値をフォームに埋め込み、リクエスト時に検証する。
- ・SameSite属性の活用: Cookie発行時に属性を指定し、クロスサイトでの送信を制限する。
- ・多層防御の推奨: SameSite属性による基礎防御に加え、重要な操作にはトークン検証を併用する。
// Result
適切な対策を講じることで、攻撃者がユーザーの意図しない操作を実行することを防げる。
- ・CSRFトークンにより、同一オリジンポリシーに基づいた厳格な検証が可能になる。
- ・SameSite属性（Strict/Lax）により、ブラウザレベルでの広範な防御が実現する。
- ・SameSite=Laxの緩和措置（発行後2分間の挙動）を考慮した、より堅牢な設計が可能となる。
Senior Engineer Insight
> フレームワークの標準機能に依存しすぎる設計は危険である。特にAPIとフロントエンドを分離する構成では、CSRF保護が自動適用されないケースが多い。SameSite=Laxのデフォルト化により防御ラインは上がったが、ブラウザの緩和措置（Lax + POST）による隙は存在する。重要なトランザクションを扱うエンドポイントでは、トークン検証による多層防御を設計原則として組み込むべきだ。