用語辞典
CSRF（クロスサイトリクエストフォージェリ）とは — ログイン中の利用者に“勝手に操作”させる攻撃
CSRF（クロスサイトリクエストフォージェリ）は、ログイン中の利用者のブラウザを利用して、本人が意図しないリクエスト（送金・設定変更など）を別サイト経由で送らせる攻撃です。仕組みの図解と、本命の防御（CSRFトークン・SameSite Cookie・Origin確認）を、攻撃手順を伏せて防御目線で解説します。
「ログインしたまま“別のサイト”を開いただけで、知らないうちに送金や設定変更が走る」——それがCSRFです。仕組みと確実な防ぎ方を解説します（攻撃手順は載せません）。
なぜ成立するのか（仕組み）
ブラウザは、あるサイトへのリクエストにそのサイトのCookieを自動的に付けます。だから、利用者が銀行サイトにログイン中なら、別の悪意あるページから銀行への操作を送っても、ブラウザは“本人のCookie”を一緒に送ってしまいます。サーバーから見ると、本人の正規操作と区別がつきません。
XSSが「被害者のブラウザでコードを動かす」のに対し、CSRFは「被害者のログイン状態を勝手に使う」攻撃です（→ XSS とは）。
防御
CSRFトークンを必須にする
状態を変える操作（フォーム送信・API）に、推測できない使い捨てトークンを要求。サーバーが発行し、リクエストに含まれないと拒否する。多くのフレームワークが標準提供。
SameSite Cookie を設定する
セッションCookieに SameSite=Lax（または Strict）を付け、別サイト起点のリクエストにCookieを付けさせない。近年の既定はLaxで、これだけでも大きく効く。
状態変更に GET を使わない
閲覧（GET）で副作用を起こさない設計に。変更はPOST/PUT/DELETEにし、トークン検証を通す。
Origin / Referer を確認する
重要操作では、リクエスト元（Origin）が自サイトかをサーバーで確認し、外部起点を弾く。
ITDの視点：ほぼ“解決済み”だが油断は禁物
モダンなフレームワークのCSRFトークン＋ブラウザの SameSite=Lax 既定で、典型的なCSRFは大幅に減りました。とはいえ、独自実装のAPI・古い構成・トークンを省いた管理画面では今も普通に刺さります。「フレームワークに任せきり」でも、状態変更の経路にトークン検証が通っているかを一度自分で確認するのが安全です。
よくある抜け穴
仕組みを知っていても、実装では次の2点で抜けがちです。
- GETに副作用を持たせている：閲覧用のGETで状態が変わる設計だと、画像タグや単なるリンクだけでCSRFが成立しえます。状態変更は必ずPOST/PUT/DELETEにし、トークン検証を通します。
- 一部の経路だけトークン検証を忘れる：後から足したAPIや管理機能で、トークン検証が抜けていることがよくあります。「フレームワークに任せた」で安心せず、状態を変える全経路を一度棚卸ししてください。
次に読む
よくある質問
QCSRFとXSSは何が違う？
XSSは“被害者のブラウザでスクリプトを実行”させる攻撃、CSRFは“被害者のログイン状態を使って意図しないリクエストを送らせる”攻撃です。CSRFはスクリプトを実行できなくても、Cookieが自動送信される性質だけで成立します。
QCSRFの一番の防御は？
状態を変える操作（POST等）にCSRFトークンを必須にすることと、セッションCookieに SameSite（Lax/Strict）を設定することです。多くのフレームワークはトークンを標準提供しています。加えて、状態変更にGETを使わないことも基本です。
QSameSite Cookie だけで十分？
大幅に効きますが万能ではありません。古いブラウザや特定の遷移、サブドメイン構成などで隙が残るため、CSRFトークンと併用する多層防御が安全です。