CSRFは、ログインしたまま別のサイトを開いただけで、知らないうちに送金や設定変更が実行されてしまう攻撃です。仕組みと確実な防ぎ方を解説します（攻撃手順は載せません）。
なぜ成立するのか（仕組み）
ブラウザは、あるサイトへのリクエストにそのサイトのCookieを自動的に付けます。だから、利用者が銀行サイトにログイン中なら、別の悪意あるページから銀行への操作を送っても、ブラウザは“本人のCookie”を一緒に送ってしまいます。サーバーから見ると、本人の正規操作と区別がつきません。
XSSが「被害者のブラウザでコードを動かす」のに対し、CSRFは「被害者のログイン状態を勝手に使う」攻撃です（→ XSS とは）。
防御
CSRFトークンを必須にする
状態を変える操作（フォーム送信・API）に、推測できない使い捨てトークンを要求。サーバーが発行し、リクエストに含まれないと拒否する。多くのフレームワークが標準提供。
SameSite Cookie を設定する
セッションCookieに SameSite=Lax（または Strict）を付け、別サイト起点のリクエストにCookieを付けさせない。近年の既定はLaxで、これだけでも大きく効く。
状態変更に GET を使わない
閲覧（GET）で副作用を起こさない設計に。変更はPOST/PUT/DELETEにし、トークン検証を通す。
Origin / Referer を確認する
重要操作では、リクエスト元（Origin）が自サイトかをサーバーで確認し、外部起点を弾く。
当サイトの視点：ほぼ“解決済み”だが油断は禁物
モダンなフレームワークのCSRFトークン＋ブラウザの SameSite=Lax 既定で、典型的なCSRFは大幅に減りました。とはいえ、独自実装のAPI・古い構成・トークンを省いた管理画面では今も普通に被害が起きます。「フレームワークに任せきり」でも、状態変更の経路にトークン検証が通っているかを一度自分で確認するのが安全です。
よくある実装の漏れ
仕組みを知っていても、実装では次の2点で抜けがちです。
- GETに副作用を持たせている：閲覧用のGETで状態が変わる設計だと、画像タグや単なるリンクだけでCSRFが成立しえます。状態変更は必ずPOST/PUT/DELETEにし、トークン検証を通します。
- 一部の経路だけトークン検証を忘れる：後から足したAPIや管理機能で、トークン検証が抜けていることがよくあります。「フレームワークに任せた」で安心せず、状態を変える全経路を一度棚卸ししてください。
CSRF・XSS・SSRFの違い
名前の似た3つは、「誰が」「何を使って」リクエストを送るかで区別できます。
| 攻撃 | リクエストを送るのは | 悪用されるもの | 主な防御 |
|---|---|---|---|
| CSRF | 利用者のブラウザ（本人は気づかない） | ブラウザがCookieを自動で付ける性質 | CSRFトークン・SameSite Cookie |
| XSS | 利用者のブラウザで動く攻撃者のスクリプト | ページの出力時のエスケープ漏れ | 出力時のエスケープ・CSP |
| SSRF | あなたのサーバー | URLを受け取って取りに行く機能 | 宛先の許可リスト・内部宛の遮断 |
CSRFとXSSは、どちらも利用者のブラウザを使う攻撃です。ただしXSSがあれば、ページ内のスクリプトがCSRFトークンを読めるため、CSRF対策は回避されます。CSRF対策はXSS対策ができている前提で成り立ちます。
具体例：CSRFで送らされた書き込みが、本人の操作と扱われた
2012年、横浜市のウェブサイトの意見投稿フォームに、小学校への襲撃を予告する書き込みがありました。送信元とされたPCの持ち主が逮捕されましたが、後に誤認逮捕だったことが明らかになりました。警視庁は同年12月、この書き込みには、掲示板に貼られたリンクを開いた利用者のブラウザから投稿を送らせるCSRFの手法が使われたと説明したと報じられています。
この事例から分かることは2つあります。
- CSRFの記録は本人の操作と見分けがつかない：サーバーに残るのは利用者のIPアドレスとCookieです。ログだけでは、本人が送ったのか、送らされたのかを区別できません。
- ログイン不要のフォームも対象になる：この投稿フォームにログインは必要ありませんでした。外から送らせると困る送信（投稿・申し込み・通報など）には、ログインの有無にかかわらずトークンを付けます。
CSRFは今も多く見つかる弱点です。MITREが2025年12月に公表した「CWE Top 25」（危険なソフトウェアの弱点の上位25）では、CSRF（CWE-352）が3位でした。
自分のサイトで確認する方法
セッションCookieの SameSite を明示しているか
ブラウザの開発者ツール（Application → Cookies）かサイト総合セキュリティ診断で、セッションCookieの SameSite 属性を確認する。Chrome と Edge は属性のないCookieを Lax として扱うが、Safari と Firefox は既定ではこの扱いをしていない。ブラウザの既定に頼らず、SameSite=Lax か Strict を自分で付ける。
CSRF対策の除外設定を見直す
フレームワークのCSRF保護を一部の経路で外していないかを確認する（Django の csrf_exempt、Laravel の除外リスト、Rails の skip_forgery_protection など）。Webhookの受け口のように外す理由がある経路は、署名の検証で代わりに守る。
GETで状態が変わる経路がないか
ルーティングの一覧から、GETで削除・更新・ログアウトなどを行う経路を探す。見つかったらPOST等に変え、トークンの検証を通す。
重要な操作に、もう一段の確認を足す
パスワード・メールアドレスの変更、送金、権限の付与では、トークンに加えて現在のパスワードの再入力や多要素認証を求める。CSRFで送らされても、本人の確認で止まる。
出典（一次情報）
- OWASP「Cross-Site Request Forgery Prevention Cheat Sheet」 — cheatsheetseries.owasp.org（トークン、Sec-Fetch-Site、SameSiteの限界、XSSで対策が回避されること、GETで状態を変えないこと）
- MITRE「2025 CWE Top 25 Most Dangerous Software Weaknesses」（2025年12月） — cwe.mitre.org（CWE-352 が3位）
- web.dev「SameSite cookies explained」 — web.dev（属性のないCookieをLaxとして扱うブラウザと、扱わないブラウザ）
- INTERNET Watch「遠隔操作事件『どんな些細なことでも』、CSRFのリンク踏んだ人は情報提供を」（2012年12月14日） — internet.watch.impress.co.jp（横浜市サイトへの書き込みにCSRFが使われたとの説明）
- @IT「『なりすまし』ウイルスとクロスサイトリクエストフォージェリ（CSRF）による誤認逮捕について」（2012年11月） — atmarkit.itmedia.co.jp
- IPA「安全なウェブサイトの作り方」 — ipa.go.jp
次に読む
分類番号
CWE は脆弱性の原因となる弱点の種類を、MITRE ATT&CK は攻撃者の手口を分類した番号体系です。どちらも MITRE が管理し、脆弱性情報や検知ルールの分類に広く使われています。
CWE（弱点の種類）
CWE™: Copyright © 2006–2026, The MITRE Corporation. CWE is a trademark of The MITRE Corporation. The MITRE Corporation hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. Any copy you make for such purposes is authorized on the condition that you reproduce MITRE’s copyright designation and this license in any such copy. CWE Terms of Use
よくある質問
QCSRFとXSSは何が違う？
XSSは“被害者のブラウザでスクリプトを実行”させる攻撃、CSRFは“被害者のログイン状態を使って意図しないリクエストを送らせる”攻撃です。CSRFはスクリプトを実行できなくても、Cookieが自動送信される性質だけで成立します。
QCSRFの一番の防御は？
状態を変える操作（POST等）にCSRFトークンを必須にすることと、セッションCookieに SameSite（Lax/Strict）を設定することです。多くのフレームワークはトークンを標準提供しています。加えて、状態変更にGETを使わないことも基本です。
QSameSite Cookie だけで十分？
大幅に効きますが万能ではありません。古いブラウザや特定の遷移、サブドメイン構成などで隙が残るため、CSRFトークンと併用する多層防御が安全です。
Qログインが要らないフォームでもCSRF対策は必要？
必要な場合があります。問い合わせや投稿のフォームでも、別サイトから利用者のブラウザに送信させれば、送信元はその利用者のIPアドレスとして記録されます。2012年には、横浜市のウェブサイトへの犯行予告の書き込みがCSRFで送らされたもので、送信元とされたPCの持ち主が誤認逮捕されました。外から送らせると困るフォームには、ログインの有無にかかわらずトークンを付けます。
QJSONのAPIやBearerトークンで認証するサービスにもCSRF対策は要る？
認証にCookieを使っているかで決まります。CSRFは、ブラウザがCookieを自動で付けて送る性質を使う攻撃です。AuthorizationヘッダのBearerトークンのように、アプリが自分で付ける認証情報だけを使うAPIは、別サイトからそれを付けさせられないため、CSRFは基本的に成立しません。Cookieで認証するAPIなら、トークンかOriginの確認が必要です。
QSec-Fetch-Site とは？CSRF対策に使える？
ブラウザが付けるリクエストヘッダで、そのリクエストが同じサイトからか（same-origin / same-site）、別サイトからか（cross-site）を示します。OWASPのCSRF対策ガイドは、状態を変えるリクエストで cross-site を拒否する方法を対策の一つに挙げています。古いブラウザは送らないため、Originの確認を併用します。