【IPA・総務省データ】CSRFとは｜仕組みと対策、WAF導入企業は2025年で19.5%

CSRFは、XSSなどと並んでよく名前が挙がるWeb攻撃です。ただ、仕組みの説明は意外と難しいですよね。

• XSSとの違いをうまく説明できない
• 自社にCSRF対策があるか分からない
• CSRFの被害統計が見つからない

結論から言うと、CSRFはログイン中の利用者に、意図しない操作をさせる攻撃です。対策の中心は、トークン検証とSameSite属性です。

なお、公的統計にCSRF単独の件数は無く、数字だけでリスクの大小は判断できません。この記事では、仕組み、統計での扱い、対策を解説します。

この記事のポイント

• CSRFは正規のログイン状態を悪用し、偽のリクエストを送らせる攻撃
• ウェブサイトの脆弱性全般の届出（累計）の種類別割合は、XSSが56%、SQLインジェクションが11%などで、CSRFは個別に示されていない（2026年第2四半期末時点）（出典: IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期］」レポート（PDF））
• 脆弱性の悪用全般は2026年版10大脅威（組織）で4位（出典: IPA「情報セキュリティ10大脅威 2026」組織編 解説書）。WAF導入企業は2025年で19.5%（常用雇用者100人以上のインターネット利用企業、複数回答）（出典: 総務省「令和7年通信利用動向調査の結果（概要）別紙2」）

CSRFはログイン中の利用者に、本人が意図しない操作をWebサイト上で実行させる攻撃

CSRFは「Cross-Site Request Forgery（クロスサイトリクエストフォージェリ）」の略称です。ログイン中の利用者に、本人が意図しない操作を実行させる攻撃を指します。Webアプリケーションの脆弱性を突く攻撃の一つです。

SQLインジェクションやXSSと同じく、Webサイトを狙う代表的な攻撃として知られています。ここでは、仕組み、攻撃の流れ、XSSとの違いの順に見ていきます。

CSRFはブラウザが自動で送るCookieを悪用し、正規のログイン状態のまま偽のリクエストを通す

CSRFの根本にあるのは、サーバーが「本人の操作」と「罠ページから送られたリクエスト」を見分けられないという問題です。

多くのWebサイトは、ログイン後の状態をCookieで保っています。ブラウザは、そのサイトへのリクエストにCookieを自動で付けて送ります。このとき、リクエストが別のサイトから送られた場合でも、Cookieが付くことがあります。

たとえば、利用者がネットバンキングにログインしたまま、別の罠ページを開いたとします。罠ページが送金のリクエストを送ると、ブラウザはログイン中のCookieを付けて送信します。サーバーから見ると、正規の利用者からの正しいリクエストに見えます。

攻撃者は、処理の結果を直接受け取ることはできません。それでも、送金や設定変更といった処理そのものは実行されてしまいます。CSRFは、利用者のログイン状態を借りて、処理だけを通す攻撃だと理解しておきましょう。

攻撃は利用者がログインしたまま罠ページを開くことで始まり、送金や設定変更が気付かないうちに実行される

CSRFの攻撃は、利用者が標的サイトにログインしたまま、罠ページを開くことで成立します。流れは次の4段階です。

1. 利用者が、標的となるWebサイトにログインしている
2. 攻撃者が、メールやSNSの投稿で利用者を罠ページへ誘導する
3. 罠ページが、標的サイトへのリクエストを自動で送る
4. 標的サイトが、そのリクエストを利用者本人の操作として処理する

利用者の画面上では、罠ページを開いただけに見えます。そのため、被害に気付くのが遅れがちです。

狙われやすいのは、データの状態を変える操作です。送金、パスワードやメールアドレスの変更、掲示板への書き込み、管理画面での設定変更などが当てはまります。ログイン後に「何かを変更できる画面」があるサイトは、どれも対象になり得ると考えてください。

CSRFとXSSはどちらも利用者のブラウザを悪用するが、CSRFはスクリプトを実行させずにリクエストだけを偽造する

CSRFとXSSの違いは、攻撃者が利用者のブラウザに何をさせるかにあります。SQLインジェクションも含めて、3つの攻撃を表で比べてみましょう。

項目	CSRF	XSS	SQLインジェクション
攻撃者が悪用するもの	利用者のログイン状態（Cookie）	Webページへの入力値の表示処理	データベースへの命令の組み立て処理
攻撃が実行される場所	標的サイトのサーバー（利用者の権限で処理）	利用者のブラウザ（標的サイト上で動く）	標的サイトのデータベース
主な被害	送金や設定変更など、意図しない操作	Cookieの盗み取り、偽画面の表示	情報の盗み取り、データの改ざん
対策の中心	トークン検証、SameSite属性	出力時の無害化（エスケープ）	プレースホルダの利用

CSRFとXSSは名前が似ているため、混同されやすい攻撃です。クロスサイトスクリプティング（XSS）は、罠のスクリプトを標的サイト上で動かす攻撃です。これに対しCSRFは、スクリプトを動かさず、利用者の権限で正規のリクエストを送らせます。

ただし、両者は無関係ではありません。サイトにXSSの脆弱性があると、CSRF対策が破られる場合があります。CSRF対策は、XSS対策とセットで考えることが大切です。

CSRFはIPAの脆弱性届出統計で個別に集計されておらず、単独の件数は公表されていない

IPAとJPCERT/CCは、ウェブサイトとソフトウェア製品の脆弱性関連情報の届出を受け付けています。届出の件数は、四半期ごとに集計・公表されています。ウェブサイト区分の届出は、2026年第2四半期末時点で累計13,599件です。

ただし、この件数は発見者が任意で届け出た脆弱性の数です。実際に起きた被害をすべて数えた調査ではない点に注意してください。

IPAが種類別割合を示す7区分にCSRFは含まれず、XSS（累計56%）やSQLインジェクション（同11%）のような単独の割合は無い

IPAの届出統計では、ウェブサイトの脆弱性の種類別の割合を7つの区分で示しています。CSRFはこの7区分に含まれていません。

IPAは同じレポートの付表で、CSRFを「クロスサイト・リクエスト・フォージェリ」としてウェブサイトの脆弱性の種類の一つに定義していますが、種類別の集計では個別に表示していません。そのため、公表資料からCSRF単独の値は取り出せません。

2026年第2四半期末時点の累計シェアは、XSSが56%、SQLインジェクションが11%です。2つを合わせると約3分の2になります。いずれも届出制度の開始以降の累計の値です。

IPAのレポートでは、ウェブサイトの脆弱性の種類を次の区分で示しています。

• クロスサイト・スクリプティング
• SQLインジェクション
• DNS情報の設定不備
• ファイルの誤った公開
• ディレクトリ・トラバーサル
• HTTPSの不適切な利用
• その他

この区分構成から読み取れるのは、XSSやSQLインジェクションと比べて、CSRFは統計上の扱いが異なるという点です。CSRFが個別に集計されていないため、公的統計からは「CSRFはXSSより少ない」とも「軽視してよい」とも言えません。

XSSの56%は届出制度の開始以降の累計で、2026年4〜6月の届出に限るとXSSは65件中8件にとどまる

「XSSが過半数を占めるなら、CSRFは少ないはず」と考えたくなるかもしれません。しかし、累計シェアは過去の届出の構成を強く反映した値なので、そのようには読めません。

XSSの累計シェアは、2025年第4四半期末時点で57%、2026年第2四半期末時点で56%でした。ほとんど変わっていません。

この背景には、母数の大きさがあります。累計の届出は2025年第4四半期末で13,467件、2026年第2四半期末で13,599件です。

一方、2026年4〜6月の1四半期に限ると、ウェブサイト区分の届出65件のうち、XSSは8件でした。割合にすると1割強です。XSSはこの四半期でも最も多い種類でしたが、累計の56%とは大きく離れています。

この比較から読み取れるのは、累計シェアは過去の届出構成を映した値だという点です。現在の脆弱性の構成や、CSRFの多い少ないを示す数字ではありません。

出典: IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期（4月〜6月）］」／IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2025年第4四半期（10月〜12月）］」／IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期］」レポート（PDF）／IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2025年第4四半期］」レポート（PDF）

ウェブサイトの脆弱性全般の届出は2年で約65%減った一方、脆弱性の悪用は2026年版10大脅威（組織）で4位に入っている

同じIPAが公表している2つの指標は、逆の方向を示しています。ウェブサイトの脆弱性全般の届出は減っていますが、脆弱性の悪用は組織にとっての脅威として上位に挙げられています。

この章では、2つの数値の中身と、そこからCSRFについて言えることを整理します。

ウェブサイトの脆弱性全般の届出件数は、2023年の505件から2025年の178件へ減少している

IPAに届け出られたウェブサイトの脆弱性は、2023年の505件から2025年の178件へ、約65%減りました。年ごとの件数は次のとおりです。

年	ウェブサイト区分の脆弱性関連情報の届出件数（全種類の合計）
2023年	505件
2024年	336件
2025年	178件

表の出典: IPA「ソフトウェア等の脆弱性関連情報に関する届出状況」2023年第4四半期／2024年第4四半期／2025年第4四半期のデータをもとに作成

この減少から読み取れるのは、件数が減ってもサイトが安全になったとは言えない点です。届出は発見者による任意の届け出なので、届け出る人が減れば件数も減ります。

種類別の内訳は、IPAのレポートで過去2年分の四半期ごとの件数がグラフで示されていますが、CSRFは個別に表示されていません。そのため、CSRFも同じように減っているかどうかは分かりません。

IPAは「システムの脆弱性を悪用した攻撃」を2026年版10大脅威（組織）の4位に挙げ、選出は6年連続となった

IPAの「情報セキュリティ10大脅威 2026」の組織編では、「システムの脆弱性を悪用した攻撃」が4位に入っています。この脅威の選出は6年連続です。

IPAの解説書は、OSやネットワーク機器、CMS（プラグインを含む）などの製品で見つかった脆弱性が、対策前に悪用されるケースを中心に説明しています。CSRFという言葉は出てきません。

CMSのプラグインなどの製品でCSRFの脆弱性が公表される例はあり、2026年第2四半期のIPAのレポートにも、WordPress用プラグインのCSRFの脆弱性がJVNの公表例として載っています。こうした脆弱性の悪用はこの脅威に関係しますが、自社で開発したWebアプリのCSRFまで含めた評価かどうかは、解説書からは読み取れません。

ただし、10大脅威は選考会による定性的な評価です。件数を集計した結果ではありません。

この順位から分かるのは、脆弱性の悪用全般が組織の重要な脅威とされていることまでです。XSS、SQLインジェクション、CSRFのそれぞれが順位にどの程度影響しているかは分かりません。4位という順位を、CSRFの順位として引用しないよう注意してください。

届出の減少と脅威順位のずれは測る対象の違いによるもので、CSRFの脅威が小さいことを示す根拠にはならない

2つの統計から読み取れるのは、CSRFが統計に現れないのは集計区分の作り方によるもので、脅威が小さい証拠ではないという点です。

届出は「発見者が届け出た脆弱性の数」を、10大脅威は「社会的な影響の評価」を示しています。2025年の届出178件と2026年版の4位は、比べられる数字ではありません。

さらに、届出統計ではCSRF単独の件数や割合が公表されておらず、10大脅威でもCSRFは個別の脅威として挙げられていません。

一方で、フレームワークがトークンを標準で備えるようになり、主要ブラウザの一部がSameSite属性の既定値をLaxにしました。その結果、脆弱なサイトが実際に減った可能性もありますが、裏づける公的データはありません。

出典: IPA「ソフトウェア等の脆弱性関連情報に関する届出状況」2023年第4四半期／2024年第4四半期／2025年第4四半期／IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期］」レポート（PDF）／IPA「情報セキュリティ10大脅威 2026」組織編 解説書

CSRF対策の中心は、Webアプリ側でのトークン検証とCookieのSameSite属性の設定

CSRFでは、正規の利用者のブラウザから、正しい形式のリクエストが届きます。そのため対策の基本は、そのリクエストが本人の意図した操作かどうかを、アプリケーション側で確かめることです。

この章では、実装の手順ではなく、対策の考え方を説明します。開発会社に「何を確認すればよいか」が分かることを目指します。

トークン方式と再認証で、利用者が正規の画面から本人の意思で操作したことを確かめる

CSRF対策の基本は、リクエストが正規の画面から送られたことを確かめる仕組みを入れることです。代表的なのがトークン方式です。

トークン方式では、サーバーが第三者に推測できない値を作り、正規の画面に埋め込みます。リクエストが届いたら、その値が含まれているかを照合します。罠ページはこの値を知らないため、偽のリクエストを見分けられます。

IPAは、処理を実行するページをPOSTメソッドで受け付け、この値をフォームの隠しパラメータに入れる方法を示しています。GETで送ると、値が外部サイトに漏れるおそれがあるためです。

もう一つの方法が、重要な操作の前に本人の意思を確かめるやり方です。送金やパスワード変更の前にパスワードを再入力してもらう方法や、確認画面を挟む方法があります。罠ページは、利用者のパスワードを入力できません。

トークン方式は多くの画面に広く使い、再認証は特に重要な操作に使うのが一般的です。2つを組み合わせて、本人が自分の意思で操作したことを確かめると覚えておきましょう。

CookieにSameSite属性を設定すると、他のサイトから送られるリクエストにログイン情報が付かなくなる

SameSite属性は、他のサイトから送られるリクエストにCookieを付けるかどうかを決める設定です。CSRFはCookieが自動で送られることを悪用するため、この設定が対策になります。値ごとの違いを表にまとめました。

値	他サイトからのリクエストでCookieを送るか	利便性への影響	CSRFへの効果
Strict	送らない	外部サイトのリンクから来たときもログインし直しになる場合がある	高い
Lax	ページ移動のためのリンクなど、一部の場合だけ送る	影響は小さい	状態を変える操作の多くを防げる（状態を変える処理をGETで受け付けている場合は防げない）
None	送る	影響なし	効果なし

主要ブラウザの一部は、SameSite属性を指定していないCookieをLaxとして扱います。ただし、挙動はブラウザの種類やサイトの設定によって変わります。また、SameSite属性は「同じサイト」かどうかで判断するため、同じドメインの別のサブドメインから送られるリクエストには効きません。

そのため、SameSite属性だけに頼らず、トークン方式と組み合わせるのが基本です。

送信元をRefererヘッダーで確かめる方法もあり、IPAはこれを根本的解決の一つに挙げています。ただし、Refererを送らない設定の利用者がサイトを使えなくなる場合があるなどの注意点も示しています。

WAFを導入している企業は2025年で19.5%にとどまり、WAFはCSRF対策の補助的な役割にとどまる

総務省の通信利用動向調査では、WAF（Webアプリケーションファイアウォール）の導入状況を調べています。導入企業の割合は、2024年が17.4%、2025年が19.5%でした。対象は常用雇用者100人以上のインターネット利用企業で、複数回答の設問です。

図の出典: 総務省「令和7年通信利用動向調査の結果（概要）別紙2」／総務省「令和7年通信利用動向調査報告書（企業編）」調査の概要のデータをもとに作成

比較できるのは2時点だけなので、増加傾向とまでは言えません。

ここからは技術的な一般論としての見解です。CSRFの偽造リクエストは、正規のセッションから正しい形式で届きます。

そのため、通信の中身から攻撃のパターンを探すWAFでは見分けにくいと考えられます。CSRF対策の機能を持つWAF製品もあるため、無関係とまでは言えません。

また、トークンやSameSite属性の実施率を調べた公的調査は確認できません。WAF導入率の上昇を、CSRF対策が進んだ証拠として扱うことはできません。

情シスは開発会社への発注時と脆弱性診断の際に、CSRF対策が実装されているかを確かめる

CSRF対策が入っているかどうかは、自社のシステムごとに確かめるしかありません。前の節で見たとおり、対策の実施状況は公的統計では分かりません。WAFを導入しているかどうかでも判断できません。

開発会社への発注時や、公開前の脆弱性診断の際に、次の点を確認してみてください。

• 送金や設定変更など、状態を変える画面でトークンを検証しているか
• ログイン状態を保つCookieに、SameSite属性を設定しているか
• パスワード変更などの重要な操作で、再認証を求めているか
• 重要な操作が行われたときに、登録済みのメールアドレスへ通知しているか（IPAが保険的対策として挙げる方法）
• 脆弱性診断の対象に、XSS対策とあわせてCSRF対策を含めているか
• 利用者に「ログインしたまま不審なリンクを開かない」よう周知しているか

これらは、開発者でなくても質問できる内容です。発注時の要件と診断の範囲にCSRF対策を含めておくことで、対策の抜けを防ぎやすくなります。

出典: 総務省「令和7年通信利用動向調査の結果（概要）別紙2」／総務省「令和7年通信利用動向調査報告書（企業編）」調査の概要／IPA「安全なウェブサイトの作り方 1.6 CSRF（クロスサイト・リクエスト・フォージェリ）」

まとめ：CSRFは統計に表れにくいからこそ、トークンとSameSite属性で自社の対策を確かめる

CSRFは、ログイン中の利用者の権限を借りて、意図しない操作を実行させる攻撃です。XSSと違い、スクリプトを動かさずにリクエストだけを偽造します。

公的統計にCSRF単独の値はありません。XSSの累計シェア56%（2026年第2四半期末時点）と2025年の届出178件は、脆弱性全般の値です。2026年版10大脅威の4位も、脆弱性の悪用全般の評価です。

統計に出ないことは、脅威が小さい根拠になりません。自社のシステムで対策を確かめましょう。

出典: IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期（4月〜6月）］」／IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2025年第4四半期（10月〜12月）］」／IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期］」レポート（PDF）／IPA「情報セキュリティ10大脅威 2026」組織編 解説書／総務省「令和7年通信利用動向調査の結果（概要）別紙2」／総務省「令和7年通信利用動向調査報告書（企業編）」調査の概要

Webアプリのセキュリティの基礎を学ぶなら「情シスカレッジ」

CSRFのように統計に表れにくい脅威は、担当者が仕組みを理解しているかどうかで対策の質が変わります。とはいえ、新任やひとり情シスの方ほど、まとまった学習の時間は取りにくいですよね。

「情シスカレッジ」は、新人・ひとり情シスのためのマイクロラーニングLMSです。数分の動画と小テストで、業務の合間に少しずつ学べます。

導入は5名から可能で、請求書払いにも対応しています。初期設定はおよそ10分で完了します。

情シスカレッジの詳細を見る

※出典

• IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2023年第4四半期（10月〜12月）］」
• IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2024年第4四半期（10月〜12月）］」
• IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2025年第4四半期（10月〜12月）］」
• IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期（4月〜6月）］」
• IPA「情報セキュリティ10大脅威 2026」組織編 解説書
• IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2026年第2四半期］」レポート（PDF）
• IPA「ソフトウェア等の脆弱性関連情報に関する届出状況［2025年第4四半期］」レポート（PDF）
• IPA「安全なウェブサイトの作り方 1.6 CSRF（クロスサイト・リクエスト・フォージェリ）」
• 総務省「令和7年通信利用動向調査の結果（概要）別紙2」
• 総務省「令和7年通信利用動向調査報告書（企業編）」調査の概要