>
>
最終更新日
CSRF（クロスサイトリクエストフォージェリ）とは、ログイン状態を悪用して意図しない不正リクエストを強制送信させるサイバー攻撃です。本記事では、CSRF対策の基本的な仕組みから「SameSite=Lax」の誤解、XSSとの違い、EC-CUBEなどの被害事例、2026年最新の「Fetch Metadata」やBFF（Backend For Frontend）を用いたモダンWebでの強固な防衛策まで、開発者や情シス担当者に向けてわかりやすく解説します。
本記事のポイント
① CSRFはCookie自動送信を悪用し「状態の書き換え」を強制するXSSとは別物の攻撃である
② SameSite=Laxだけでは不十分な理由（過去の2分ルール・GETメソッドの罠・3大誤解）
③ CORS・HttpOnlyはCSRF対策にならない—よくある3大誤解を解説
④ モダンWeb（SPA／BFF／Fetch Metadata）での2026年最新の多層防衛策
CSRFとは
CSRF（クロスサイトリクエストフォージェリ）は、ログイン状態を悪用して意図しない不正リクエストを強制送信させる攻撃です。
多くのWebアプリケーションは、ブラウザが特定ドメイン宛てのリクエストを送信する際、対応するセッションCookieを自動的に添付する仕様（自動送信仕様）を利用してユーザー認証を維持しています。これは1990年代のWeb黎明期における利便性を考慮して設計された挙動ですが、悪意ある第三者が構築した罠サイトを経由することで、この仕組みが悪用されてしまいます。なお、現在はGoogle ChromeをはじめとするモダンブラウザでCookieの「SameSite=Lax」がデフォルトに設定されていますが、後述するようにそれだけでは不十分なケースが存在します。
「CSRFは過去の脆弱性である」という認識は、セキュリティ現場では明確な誤りです。米MITREが発表した「2025 CWE Top 25 Most Dangerous Software Weaknesses（最も危険なソフトウェア脆弱性トップ25）」において、CSRF（CWE-352）は世界第3位にランクインしました。日本国内の脆弱性データベース「JVN iPedia」の累計登録件数は27万件超にのぼりますが、その中でもCSRFは件数としては少数ながら、長年にわたって息が長く報告され続けている実態があり、現在でも警戒すべき3大脆弱性の1つとして位置づけられています。
▲ ユーザーのログイン状態を悪用して意図しない処理を強制実行させるCSRFの仕組み
CSRF攻撃とXSS攻撃との違い
XSSが攻撃者のスクリプトをブラウザ上で実行させ情報を盗むのに対し、CSRFはログイン状態を悪用してデータの書き換えのみを強制します。
どちらもWebアプリケーションの脆弱性を突く代表的な攻撃手法ですが、その影響範囲やアプローチには決定的な違いがあります。CSRFは、攻撃対象のリクエストを「送信させる（Write）」だけであり、サーバー側からの返却値（レスポンス）を攻撃者が「読み取る（Read）」ことはできません。そのため、情報の漏洩ではなく設定の書き換えが直接的な被害となります。一方、XSSは任意のスクリプトを実行できるため、情報の窃取から画面改ざんまで幅広い被害を及ぼします。
比較項目 | CSRF（クロスサイトリクエストフォージェリ） | XSS（クロスサイトスクリプティング） |
|---|---|---|
主な攻撃目的 | 不正決済、アカウント設定変更、強制退会などの「状態の書き換え」 | セッションIDの盗み出し、画面改ざん、マルウェアの感染 |
情報の窃取（Read） | 不可能（攻撃者がレスポンスを読み取ることはできない） | 可能（任意のJavaScriptを実行しCookieなどを窃取できる） |
代表的な防衛策 | ワンタイムトークンの検証、SameSite属性、Fetch Metadata、カスタムヘッダー | サニタイズ（エスケープ処理）、CSP（Content Security Policy）の設定 |
JWTをLocalStorageに保存する際のトレードオフ
CSRFを恐れるあまり、セッション管理にCookieを使用せず、JWT（JSON Web Token）などのトークンを「LocalStorage」に保存する設計を採用するケースがあります。しかし、LocalStorageに保存されたデータはJavaScriptから容易にアクセス可能です。万が一、アプリケーションに1箇所でもXSS脆弱性が混入した場合、LocalStorage内の認証トークンは即座にすべて窃取されてしまいます。実務においては、Cookieに「HttpOnly」「Secure」属性を付与した上で、堅牢なCSRF対策を実装する多層防御がベストプラクティスとされています。
▲ 攻撃目的や情報の読み取り（Read）可否におけるCSRFとXSSの決定的な違い
CSRF攻撃による具体的な被害事例
CSRF攻撃の被害は情報の流出ではなく、意図しない設定変更やトランザクションの不正実行として現れます。
具体的な実被害および公表された事例として、以下のケースが代表的です。
「EC-CUBE」および関連プラグインの脆弱性：国内シェア最大級のEC構築OSである「EC-CUBE 2系」の管理画面（JVN#75444925）やサードパーティ製メルマガ管理プラグイン（CVE-2022-21179）などで、相次いでCSRF脆弱性が報告されました。JVN#75444925のCSRFによる直接的な影響は「意図しない管理ユーザーの削除」、CVE-2022-21179ではメールテンプレートの削除等に留まります。なお、同時期のEC-CUBEでは認可制御の不備やXSS等の別脆弱性も報告されており、これらが組み合わさることでフォームジャッキング（クレジットカード情報の窃取コードの埋め込み）といった深刻な2次被害につながるリスクが指摘されています。
「ASUS製無線LANルータ」のDNS改ざん：ASUS製の複数の無線LANルータにおいて、Web管理画面のCSRF脆弱性が公表されました。管理者がログイン状態で悪意あるサイトを閲覧すると、ルータのDNSサーバー設定が勝手に書き換えられ、ルータに接続する全ユーザーが偽のフィッシングサイトへ誘導されるというインフラ乗っ取り型のリスクが発生しました。
オープンソースチャット（Mattermost・Rocket.Chat）：CSPT（クライアントサイド・パストラバーサル）というSPA特有の脆弱性と組み合わせることで、従来のCSRF保護を迂回してAPI（POST/DELETE等）を強制実行させられる「CSPT2CSRF」脆弱性が検知され、セキュリティ研究者から警鐘が鳴らされました。
2025〜2026年の最先端セキュリティ脅威：AIチャットボットへの不正プロンプト送信
生成AIの普及に伴い、社内に組み込まれた「AIチャットボット」や「生成AIプロンプト送信フォーム」がCSRFの新たな標的となっています。攻撃者の罠サイトを経由し、ログイン中のユーザーのブラウザから、AIチャットに対して「不正なシステムプロンプト」や「機密データの外部送信」を強制実行させられます。さらに、管理者画面のAIボットから内部システムに対してOSコマンドを実行させる「CSRF ＋ OSコマンドインジェクション」の複合攻撃によって、サーバー自体が乗っ取られるリスクも指摘されています。
開発者が陥りがちなCSRF対策の誤解と失敗パターン
主要なセキュリティ機能の役割を誤解したまま実装を進めると、深刻なCSRF脆弱性を放置することになります。
主要ブラウザにおけるCookieの「SameSite=Lax」属性のデフォルト化に伴い、「もうCSRF対策は不要である」と誤認する開発者が増えていますが、以下の2つの大きな仕様上の隙（バグ）が存在します。
誤解の隙①：過去の「2分ルール（Lax+POST 例外仕様）」と現在の注意点
Google ChromeをはじめとするChromium系ブラウザには、Chrome 80で「SameSite=Lax」がデフォルト化された際の過渡期に、「Lax-by-default-2-minute-mitigation（Laxデフォルトにおける2分間の緩和措置）」と呼ばれる例外仕様が存在していました。Cookieが作成・更新されてから最初の120秒間は、クロスサイトからのPOSTリクエストでも例外的にCookieが送信される仕様でしたが、この緩和措置はその後のアップデートですでに廃止・無効化されています。ただし、この経緯はブラウザのデフォルト挙動に頼るリスクを示す好例であり、現在も必ずサーバー側で明示的に Set-Cookie: ...; SameSite=Lax（または Strict）を明記することが重要です。
誤解の隙②：GETメソッドの罠（LaxはGETを防げない）
SameSite=Laxは、クロスサイトからの「POST」リクエストによるCookie送信は遮断しますが、「GET」リクエスト（通常のリンククリックや画面遷移など）では通常通りセッションCookieが送信されます。開発者が「ログアウト処理」や「設定変更・削除処理」を、実装の簡便さからGETメソッド（例: `/logout` や `/delete?id=12`）で実装しているケースが後を絶ちません。この場合、攻撃者が用意した タグをユーザーがクリックしただけで処理が勝手に実行され、CSRFが完全に成立してしまいます。
エンジニアが実務で混同しやすい『3大誤解』
誤解①：「CORS（Cross-Origin Resource Sharing）を設定しているから大丈夫」
CORSは他サイトが「レスポンスを読めるか」を制御する仕組みです。リクエスト自体はサーバーに届いてデータベースが更新されてしまうため、CSRFの防止には一切機能しません。誤解②：「CookieにHttpOnly属性を設定しているから安心」
HttpOnlyはJavaScriptからの読み取りを制限するXSS対策です。リクエスト時のCookieの自動送信挙動を止めることはできないため、CSRF対策にはなりません。誤解③：「エラーが出るからフレームワークのCSRFプロテクションをオフ（Disable）にする」
SPAや非同期API連携の初期開発時に419や403エラーが多発した際、一時的なエラー回避目的で安易にプロテクションを無効化する重大な実装ミスが多発しています。これはセキュリティの盾を自ら捨てる極めて危険な行為です。
▲ Cookieの「SameSite=Lax」依存における、CSRF防御の「穴」を発見するセキュリティ判定フロー
モダンWeb（SPA・API構成）でのCSRF対策
SPAとAPIが分離したモダンなアーキテクチャでは、Cookie制御と非同期通信の特性に合わせた多層防御が必要となります。
React, Vue, Next.jsなどのフロントエンド（SPA）とバックエンドAPIが分離した構成では、セッション管理にCookieを使う限り、CSRF対策は必須です。2026年現在、以下の最新防衛策を組み合わせた設計が強く推奨されています。
1. カスタムHTTPヘッダーの検証（X-CSRF-Token等）
JavaScriptでの非同期通信時に、独自のリクエストヘッダー（例：X-CSRF-Token）を付与して通信します。ブラウザの仕様上、異なるドメインをまたぐ（クロスサイト）通信でカスタムヘッダーを勝手に付与することは（プリフライトリクエストによる制限のため）不可能であるため、サーバー側でこのヘッダーの存在を検証するだけでCSRF攻撃をブロックできます。
2. BFF（Backend For Frontend）パターンの採用
フロントエンドと本番APIの間に中継用のWebサーバー（BFF）を挟むアーキテクチャです。ブラウザ・BFF間は「HttpOnly + Secure + SameSite=Strict」を付与したCookieで強固に認証し、BFFから先の本番APIへはBFF内部でアクセストークンを付与してリクエストします。認証情報がブラウザ側に露出しないため、XSS・CSRF双方に極めて高い防御力を持ちます。
3. Fetch Metadata（Sec-Fetch-Siteヘッダーなど）の検証
多層防御の「ファーストライン（第一関門）」として、2025〜2026年のモダンWeb開発で急速に普及しているのがFetch Metadataです。ブラウザが自動付与する、JavaScriptで偽装不可能なセキュリティヘッダー（Forbidden Header）を検証します。
モダンWebフレームワークの代表格である「Ruby on Rails」でも、Rails 8.2において、従来のCSRFトークン検証から、ブラウザが自動送信する「Sec-Fetch-Siteヘッダー」を利用したモダンな防御（Fetch Metadata）へ主要な対策を移行する方針が示されています。これにより、従来の複雑な「CSRFトークン」を発行・管理・検証するオーバーヘッドがなくなり、キャッシュされたHTMLページでも動作しやすくなるため、開発コストの削減に直結します。
よくある質問
Q：CORSとCSRF対策はどのように異なりますか？
A：CORSは異なるドメイン間でのデータの「読み取り」を制限するポリシー制御です。一方、CSRF対策はサーバー上のデータを「書き換える（状態変更する）」リクエストの不正実行を阻止する役割を持ち、目的が全く異なります。
Q：SameSite=Laxがあれば、アプリ側のCSRF対策は一切不要ですか？
A：いいえ、必要です。データの書き換え（退会、設定変更など）をGETメソッドで処理している設計上の欠陥があったり、Chromiumの「120秒（2分）のPOST例外ルール」を突かれたり、同一サイトのサブドメインに存在するXSSを足がかりにされたりすると、SameSite=Laxをすり抜けてCSRFが実行されます。
Q：LaravelやDjangoなどのフレームワークが持つCSRF保護を有効にしたまま、SPA構成で開発するにはどうすればよいですか？
A：多くのフレームワークは、JavaScriptから読み取り可能な「CSRFトークン用Cookie（例：XSRF-TOKENなど）」を発行し、フロントエンド側がそのトークンをリクエストヘッダーに付与して送信する仕組みをサポートしています。フレームワークのCSRF保護を無効化せず、この仕組みを正しく実装することが重要です。さらにFetch Metadataによる検証を多層防御として組み合わせると、より強固な構成になります。
まとめ
Webアプリケーション開発において、セキュリティをブラウザ側の仕様（SameSite=Laxなど）だけに丸投げするのは極めて危険です。サーバー側でのCSRFトークン検証の徹底、あるいは2026年現在のWeb標準となりつつある「Fetch Metadata（Sec-Fetch-Site）」の導入による多層防御を構築しよう。まず自社の重要処理でGETメソッドが使われていないか、フレームワークの保護が無効化されていないかをコードレビューで確認するところから始めてほしい。
今日からできるアクションチェックリスト
✅ 重要処理（退会・設定変更・削除等）にGETメソッドが使われていないか確認した
✅ フレームワークのCSRFプロテクションが有効になっているか確認した
✅ Set-CookieにSameSite属性を明示的に付与しているか確認した
✅ Fetch Metadata（Sec-Fetch-Site）の導入可否を検討した
✅ BFFパターンやカスタムヘッダー検証の適用を検討した
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
