>
>
公開日
最終更新日
CSRF（クロスサイトリクエストフォージェリ）は、利用者がログインしているWebサービスに対し、攻撃者が用意したページから意図しないリクエストを送らせる攻撃です。パスワード変更、メールアドレス変更、送金先登録、管理者追加といった状態変更処理が標的になりやすい傾向があります。
CSRF対策では、CookieのSameSite属性だけに依存せず、CSRFトークン、Origin・Referer検証、Fetch Metadata、重要操作時の再認証を組み合わせます。とくにSPAとAPIを分離した構成では、認証Cookieの送信条件、CORS設定、カスタムヘッダーの検証を一体で設計しなければなりません。
本記事は、WebアプリケーションやAPIの設計・実装・運用を担当するエンジニア、情シス担当者、外部ベンダーの診断結果を受け取る立場の担当者を対象にしています。フロントエンドエンジニアからバックエンドエンジニア、インフラ担当者まで、Cookie認証を扱う構成に関わるすべての役割で活用できます。最初にCSRFとは何かを短時間で把握し、その後に自社構成に応じた対策とエラー対応へ進める構成です。
CSRFとは
CSRFとは、認証済みセッションを悪用し、利用者の意図しないリクエストを対象サイトに強制実行させる攻撃です。
本記事のポイント
CSRFは、ブラウザがCookieを自動送信する性質を悪用して状態変更を起こす攻撃です。
XSSはスクリプト実行、CSRFはリクエスト強制が中心であり、対策の目的が異なります。
SameSite=Laxは補助策であり、状態変更をGETで実装した場合や、構成によってはsame-site起点の攻撃を防げない場合があります。
Cookie認証を使うSPAやBFFでは、トークン、オリジン検証、Fetch Metadataを構成に応じて組み合わせます。
一般的なWebサービスは、ログイン後に発行したセッションCookieをブラウザに保存します。ブラウザは対象ドメインへのリクエスト時にCookieを自動で付与するため、サーバーは利用者を再入力なしで識別できます。CSRF攻撃では、この便利な仕組みを利用し、攻撃者が別サイト上のフォームや画像リクエストなどから、被害サイトへ操作リクエストを送信させます。
たとえば、利用者が銀行、ECサイト、SaaSの管理画面にログインしたまま攻撃ページを開いたとします。そのページに埋め込まれた
タグがメールアドレス変更APIへPOSTを送ると、サーバーが送信元の正当性を検証していない場合、利用者本人の操作として処理される可能性があります。攻撃者は通常、レスポンス本文を直接読めませんが、状態変更そのものを成立させられます。
admina.moneyforward.comは、MITREが公開した「2025 CWE Top 25 Most Dangerous Software Weaknesses」においてCSRFに対応するCWE-352が世界第3位にランクインしたと紹介しています。管理画面や決済、権限変更など高い影響度を持つ処理に混入した場合に危険性が高いと評価されています。IPAも「安全なウェブサイトの作り方」ipa.go.jpで、SQLインジェクションやCSRFを含む11種類の脆弱性を取り上げています。
IPAはCSRFに関する届出がWebサイトの届出全体に占める割合を1％未満と案内していますipa.go.jp。ただし、この数値は届出ベースの集計であり、対策不要を意味するものではありません。IPAが2025年第1四半期末時点で公表した集計ipa.go.jpによると、届出受付開始からの累計脆弱性届出数は19,385件で、うちWebサイトに関するものが13,344件（全体の約7割）を占めています。重要な状態変更処理を持つサービスでは、届出件数ではなく攻撃成功時の業務影響で優先順位を決めます。
攻撃が成立する前提条件
CSRFが成立しやすいのは、ブラウザCookieなどで認証済みセッションを維持し、サーバーが「このリクエストは正規画面から送られたか」を検証しない場合です。IPAは、Cookieを使ったセッション管理だけでなく、Basic認証やSSLクライアント認証を利用するサイトもCSRFの影響を受ける可能性があると説明しています。
一方、認証情報をAuthorizationヘッダーで明示的に送るネイティブアプリやサーバー間APIでは、典型的なフォームCSRFの成立条件が異なります。ただし、ブラウザからCookieを伴って呼び出すAPIがあるなら、そのAPIはWeb画面と同じくCSRF対策の対象です。認証方式ではなく、ブラウザが認証情報を自動送信するかどうかで判断します。
CSRF攻撃の仕組みと成立条件
CSRF攻撃は、被害者のブラウザが認証情報を自動送信し、サーバーがリクエストの送信元を十分に確認しないときに成立します。
攻撃の流れは、攻撃者が認証を突破するものではありません。すでに認証済みの利用者のブラウザを経由して、正規サービスに操作させる点が特徴です。攻撃者がパスワードを知らなくても、利用者がログイン状態であれば被害につながる場合があります。
利用者が対象サービスにログインし、セッションCookieを保持します。
攻撃者が、状態変更リクエストを埋め込んだ悪意あるページを作成します。
利用者がそのページを開くか、誘導リンクをクリックします。
ブラウザが対象サービスへリクエストを送り、条件次第でCookieも自動送信します。
サーバー側のトークン検証や送信元検証がなければ、利用者が操作したものとして処理されます。
狙われやすい状態変更処理
CSRF対策の対象は、データを取得する画面ではなく、サーバー上の状態を変える処理です。具体的には、プロフィール変更、メールアドレス変更、パスワード変更、二要素認証の無効化、配送先変更、送金先登録、権限付与、ユーザー削除、外部連携の追加、Webhook設定変更などが該当します。
設計時に特に避けるべきなのは、削除やログアウト、設定変更をGETリクエストで実装することです。GETは情報取得に使うHTTPメソッドであり、状態変更を載せると、リンク、検索エンジンのクロール、ブラウザの先読み、外部サイトからのトップレベル遷移まで意図しない実行経路が増えます。状態変更はPOST、PUT、PATCH、DELETEに限定し、そのうえでCSRF防御を適用します。
ログインCSRFの影響範囲
CSRFは設定変更だけでなく、攻撃者が用意したアカウントへ被害者をログインさせる「ログインCSRF」として現れることもあります。この場合、被害者が攻撃者のアカウントだと気付かずに個人情報や決済情報を入力すると、攻撃者が後から同じアカウントで内容を確認できるおそれがあります。
ログイン処理にもstate値や送信元検証を適用すると、外部サイト起点の認証開始・認証完了を識別しやすくなります。デジタル庁の開発者向けドキュメントでは、stateパラメーターに十分なエントロピーを持つ値を使うよう説明しているとされています（具体的な推奨値はデジタル庁の公式開発者サイトで確認できます）。OAuthやOpenID Connectのコールバック処理では、state値をセッションとひも付け、戻り値と一致しない認証結果を拒否する設計にします。
▲ CSRF攻撃が成立するまでの仕組みと流れ
XSSとの違いと被害範囲
XSSはWebページ内で不正なスクリプトを実行させる攻撃であり、CSRFは利用者の認証状態を利用して操作リクエストを送らせる攻撃です。
両者は併発することがありますが、攻撃者ができること、守るべき境界、優先する対策が異なります。CSRFを「情報を盗めないから軽い問題」と扱うのは危険です。管理者権限の追加や送金先変更など、1回の状態変更が重大な被害へつながる処理があるためです。
比較項目 | CSRF | XSS |
|---|---|---|
主な手口 | 外部ページから認証済みサイトへリクエストを送らせます。 | 脆弱なページにスクリプトを注入し、利用者のブラウザで実行させます。 |
主な直接被害 | 設定変更、購入、送金先登録、権限変更などの不正操作です。 | 画面改ざん、入力内容の取得、利用者操作の監視、不正操作です。 |
レスポンスの読み取り | 通常のクロスサイトフォーム送信では、攻撃者はレスポンス本文を直接読めません。 | 同一オリジンで実行されるXSSでは、ページ上の情報にアクセスできる場合があります。 |
Cookie窃取の条件 | Cookie自動送信を悪用しますが、Cookie値を読む必要はありません。 | CookieがHttpOnlyでない場合、JavaScriptからCookie値を読む危険があります。HttpOnly設定済みでも画面操作や同一オリジンのAPI呼び出しは別途対策が必要です。 |
中心となる防御 | CSRFトークン、Origin・Referer検証、Fetch Metadata、SameSite、再認証です。 | 出力時エスケープ、入力値の適切な処理、CSP、HttpOnlyです。 |
CookieとLocalStorageの設計上の違い
CSRFを避ける目的で、認証トークンをLocalStorageへ保存する設計が選ばれることがあります。ブラウザはLocalStorageの値を自動送信しないため、典型的なCookie型CSRFは起きにくくなります。しかし、LocalStorageはページ上で動くJavaScriptから読めるため、XSSが成立するとアクセストークンを持ち出される可能性があります。
Cookie認証を採用する場合は、HttpOnly、Secure、SameSiteを設定し、状態変更APIにCSRFトークンまたは送信元検証を実装します。LocalStorageに保存する場合は、XSS対策、トークン有効期限、更新トークンの保管場所、漏えい後の失効手順まで含めて設計します。CSRFだけを基準に保存先を決めると、別の攻撃面を広げます。
複合攻撃の見分け方
CSRF単体では通常、攻撃者が被害サイトの応答本文を自由に読めるわけではありません。情報流出、カード情報窃取、DNS改ざん、サーバー侵害といった被害を評価するときは、CSRFによる操作強制と、認可不備、XSS、管理権限の過大付与、入力値検証不備などを分けて確認します。
この切り分けを行うと、診断報告の対応順を誤りにくくなります。たとえば、管理者追加をCSRFで強制できても、新規管理者の作成時に再認証と権限承認が必要なら影響は抑えられます。反対に、設定変更だけで外部連携先を追加できる設計では、CSRF単体でも重大な業務影響が発生します。
▲ CSRFとXSSの攻撃特性と相違点
CSRF対策の選定マトリクス
CSRF対策は単一の機能で完結させず、アプリケーション改修を中心に、ブラウザ制御と診断・運用を重ねる設計が適しています。
まず、状態変更を伴うエンドポイントを一覧化します。そのうえで、Cookie認証の有無、フロントエンドとAPIのドメイン関係、ブラウザ以外のクライアント利用、管理操作の重要度を判定します。WAFは緊急緩和に役立ちますが、サーバー側で正当な操作を区別する仕組みそのものにはなりません。
対策方式 | 主な役割 | 向く条件 | 注意点 |
|---|---|---|---|
CSRFトークン検証 | 画面またはセッションにひも付く推測困難な値を検証します。 | SSR、Cookie認証の管理画面、従来型フォームです。 | キャッシュ、複数タブ、トークン更新時の画面遷移をテストします。 |
SameSite属性 | クロスサイトでCookieを送る条件を制限します。 | すべてのCookie認証アプリケーションです。 | 単独ではGETによる状態変更やsame-site起点の攻撃を防げません。 |
Origin・Referer検証 | 送信元オリジンが許可範囲かをサーバー側で判定します。 | トークン実装が難しい既存システムの補助策です。 | Referer未送信時の扱い、リバースプロキシ配下のヘッダーを設計します。 |
Fetch Metadata検証 | Sec-Fetch-Siteなどからクロスサイト要求を判定します。 | モダンブラウザ向けの追加防御です。 | 非対応ブラウザ、非ブラウザクライアント、same-site攻撃の経路を別途扱います。 |
再認証・取引確認 | 重要操作の直前に本人確認を追加します。 | 送金、認証情報変更、権限変更、退会です。 | CSRFの代替ではなく、攻撃成功時の被害を縮小する対策です。 |
WAF・脆弱性診断 | 既知の不正要求の遮断と実装漏れの検出を補助します。 | 改修前の緊急対応、継続的な監査です。 | 業務仕様を理解したトークン検証の代わりにはなりません。 |
トークン方式の実装要件
CSRFトークンは、攻撃者が推測できず、対象の利用者またはセッションに結び付いた値をサーバー側で照合する方式です。HTMLフォームにhiddenフィールドとして埋め込むSynchronizer Token Pattern、CookieとカスタムヘッダーのトークンをサーバーWで照合するDouble Submit Cookie Patternなどがあります。Double Submit Cookie Patternを採用する場合、Cookie注入攻撃やサブドメイン経由の改ざんを防ぐため、トークンにHMACなどで署名を付けるか、セッションと結合した値にする設計が安全です。署名なしの単純な一致確認では、攻撃者がサブドメインを制御できる環境でトークンを差し替えられる場合があります。
トークンを実装するときは、値の生成、保存、検証、失効の範囲を決めます。ログイン後の全セッションで共通のトークンを使うか、フォーム単位・操作単位で発行するかにより、利便性と防御粒度が変わります。送金先登録やパスワード変更のような高リスク操作では、CSRFトークンに加え、現在のパスワードやワンタイムコードの再入力を求めると、セッションを悪用された場合の影響を抑えられます。
診断と運用の位置付け
脆弱性診断は、CSRF対策が実装されているかを第三者視点で確認する手段です。過去の診断統計では、フレームワークの標準機能が存在しても実装漏れが残るケースが報告されています。自動診断と手動確認を組み合わせることで、こうした漏れを検出しやすくなります。
虎の穴ラボは、XSSやCSRFを含む主要脆弱性の確認を目的に、AI脆弱性診断ツールのAeyeScanを採用したと公表しています。なお、同社の事例では権限周りなど人手が必要な脆弱性もあり、外部診断サービスの完全な代替ではないとも説明されています。自動診断を導入する場合でも、権限変更や決済確定など業務仕様に依存する操作は、テスト用アカウントを使った手動確認を組み合わせます。
構成別のCSRF防御設計
Cookie認証を使う構成では、同一ドメインかクロスドメインかを問わず、状態変更APIごとに送信元とトークンを検証します。
SPAやAPIでは「画面が別ドメインだからCSRF対策は不要」と判断しがちです。しかし、ブラウザが認証Cookieを送る設定であれば、APIのドメインが別でもCSRFの検討対象です。下表では、認証方法と通信経路に応じた基本方針を整理します。
システム構成 | 認証の例 | 優先する防御 | 設計上の確認点 |
|---|---|---|---|
SSRのWebアプリケーション | 同一ドメインのセッションCookie | フレームワークのCSRFトークン、SameSite、Origin・Referer検証 | 全フォームと状態変更URLに保護が適用されているかを確認します。 |
同一ドメインのSPAとAPI | HttpOnly Cookie | カスタムヘッダー付きCSRFトークン、Fetch Metadata、SameSite | 初期HTML、トークン取得API、更新APIのキャッシュ条件を確認します。 |
クロスオリジンのSPAとAPI | SameSite=None; SecureのCookie | CSRFトークン、厳格なCORS許可、Origin検証、Fetch Metadata | 許可Originをワイルドカードにせず、credentials利用時のCORS応答を限定します。 |
BFFを介したSPA | ブラウザとBFF間はCookie、BFFとAPI間はサーバー認証 | BFFでのトークン・送信元検証、SameSite、重要操作の再認証 | BFFが認可判断を代行しすぎず、API側でも権限を検証します。 |
モバイルアプリとブラウザ併用API | モバイルはBearerトークン、ブラウザはCookie | ブラウザ経路だけにCSRF検証を適用し、クライアント種別を安全に区別 | CSRF検証の例外をURL単位で広げず、認証方式単位で設計します。 |
同一ドメインSPAの防御構成
同一ドメインのSPAでは、ログイン後にCSRFトークンを取得し、POST、PUT、PATCH、DELETEなど状態変更を行う通信でX-CSRF-Tokenヘッダーに付与します。サーバーはトークンの一致を確認し、加えてSec-Fetch-Siteがcross-siteである要求を拒否する設計にします。
トークンをJavaScriptから読ませる場合、認証CookieまでJavaScriptで読めるようにしてはいけません。認証CookieはHttpOnlyを維持し、CSRF用CookieまたはHTML内のトークンだけをフロントエンドが取得できるよう分離します。XSSが混入した場合を想定し、CSP、出力時エスケープ、依存ライブラリの更新も並行して実施します。
クロスドメインAPIの防御構成
フロントエンドとAPIでドメインが異なる場合でも、同一サイト（eTLD+1が同一）であればSameSite=Noneが不要な構成もあります。クロスサイトにまたがってCookieを送る構成ではSameSite=NoneとSecureが必要になる場面があります。この設定はクロスサイトCookie送信を許容するため、CSRFトークンと厳格なOrigin検証を省略できません。
CORSは、ブラウザがクロスオリジンのレスポンスをJavaScriptへ公開するかを制御します。一般的なHTMLフォーム送信そのものを止める仕組みではありません。ただし、サーバーがカスタムヘッダーを必須にし、CORSで許可Originを固定し、資格情報付き通信を必要なオリジンだけに許可する構成では、ブラウザのプリフライトも防御の一部になります。Access-Control-Allow-Origin: *とcredentialsの組み合わせは使わず、環境別の許可Originを明示します。
Fetch MetadataとBFFの適用範囲
Fetch Metadataは、ブラウザが付与するSec-Fetch-Site、Sec-Fetch-Mode、Sec-Fetch-Destなどを使い、クロスサイトからの不審な要求を判定する仕組みです。Fetch Metadataをブラウザ向けの追加防御層として活用し、従来のCSRFトークン検証と組み合わせる設計は、モダンブラウザ対応の補助策として機能します。採用するフレームワークのバージョンごとにFetch Metadata対応状況が異なるため、利用するフレームワークの公式リリースノートで対象バージョンと設定条件を確認したうえで、従来のトークン検証との組み合わせを判断します。
ただし、Fetch Metadataは万能ではありません。古いブラウザ、組み込みWebView、サーバー間通信、モバイルアプリではヘッダーが存在しない場合があります。また、悪意あるサブドメインや同一site内のXSSを起点とする攻撃は、cross-site判定だけで防げません。対象リクエストがブラウザからだけ届くなら、ヘッダー不在時はトークン検証へフォールバックします。非ブラウザクライアントも使うなら、クライアント認証方式を分離し、単純なヘッダー例外にしない設計が必要です。
BFFは、ブラウザの認証CookieをBFFまでに閉じ、BFFから内部APIへはサーバー側の認証情報で接続する構成です。認証トークンをブラウザのJavaScriptへ露出させにくい利点があります。しかし、BFFを置くだけでXSS、認可不備、過剰権限が解消されるわけではありません。BFFとAPIの両方で権限検証を行い、画面から渡される操作対象IDを信用しない実装を維持します。
失敗パターンとSameSite属性の注意点
CSRF対策で失敗しやすいのは、SameSite、CORS、HttpOnlyの役割を取り違え、フレームワークの保護を無効化してしまうことです。
Cookie属性は有効な防御層ですが、サーバー側のリクエスト検証を不要にする機能ではありません。実装の簡略化を理由にCSRF保護を外すと、後から画面やAPIが追加された際に、保護漏れを見つけにくくなります。
SameSite=Laxへの過信
SameSite=Laxは、クロスサイトからのCookie送信を一定範囲で制限します。ただし、クロスサイトであってもトップレベルナビゲーションかつ安全なメソッドと見なされるGETでは、Cookieが送られることがあります。したがって、<a href="">削除</a> のようなGETリンクで削除処理を実装していると、Lax設定でもCSRFが成立し得ます。
明示的にSameSite=Laxを設定したCookieと、SameSite属性を付けずにブラウザがLax相当として扱うCookieは区別します。ブラウザ実装の既定値に依存せず、認証Cookieの属性をサーバー設定で明示し、状態変更をGETで行わないことが先決です。SameSite=Strictはより制限が強い一方、外部サイトからの正規遷移や認証連携で利用者がログイン状態を失うことがあるため、業務要件と合わせて検証します。
過去の2分ルールの混同
一部のブラウザには、SameSite未指定CookieをLax相当として扱い始めた過渡期に、作成直後のCookieに対してクロスサイトPOSTを一時的に許容する緩和的な挙動があったとされています。この過渡的な挙動はブラウザ実装・バージョンに依存しており、現在の対策前提として扱うべきではありません。
現在の設計では、2分ルールを利用した攻撃を主な評価軸にせず、Cookie属性の明示、POST等の状態変更へのトークン検証、GETの安全な利用という基本原則で判断します。FAQや設計書にも、過去のブラウザ挙動を現行リスクとして記載しないよう更新します。
CORSとHttpOnlyの役割違い
CORSは主に、別オリジンのJavaScriptがレスポンスを読み取れるかをブラウザが判断する仕組みです。一般的なフォームCSRFは、攻撃者がレスポンスを読めなくても状態変更が成功すれば被害になるため、CORS単独では防げません。
HttpOnlyは、JavaScriptによるCookie値の読み取りを制限する属性です。XSSでセッションCookieを直接持ち出すリスクを抑えますが、ブラウザがCookieを自動送信する挙動は止めません。HttpOnlyを有効にしたうえで、CSRFトークンやOrigin検証を追加します。
保護機能の無効化
Laravelなどで419 Page Expired、Spring系アプリケーションで403 Forbiddenが発生すると、開発環境だけのつもりでCSRFミドルウェアを無効化する失敗があります。無効化設定が本番へ混入すると、全ての状態変更エンドポイントが保護されない状態になり得ます。
エラーが出たときは、保護を外すのではなく、トークンが画面へ出力されているか、SPAがヘッダーへ付与しているか、セッションCookieが送信されているかを順番に調べます。検証の結果、ブラウザ以外のWebhookやサーバー間APIが対象なら、その経路だけを強固な署名検証やクライアント認証へ分離します。
CSRFエラーの原因特定とデバッグ手順
419 Page Expiredや403 Forbiddenは、CSRFトークン、セッション、Cookie属性、送信元判定のどこで不整合が起きたかを順番に確認すると原因を絞り込めます。
エラー画面だけでは、CSRFトークン不足とログインセッション失効を判別できない場合があります。ブラウザの開発者ツールとサーバーログを同じ時刻で照合し、失敗したリクエストのヘッダー、Cookie、レスポンス、サーバー側の拒否理由を確認します。個人情報や認証トークンをチケットへ貼り付けず、必要な値は伏せ字にして扱います。
確認順 | 確認内容 | 確認できた場合の判断 | 確認できない場合の対応 |
|---|---|---|---|
1 | 失敗したURLとHTTPメソッド | POST、PUT、PATCH、DELETEならCSRF検証対象として次へ進みます。 | GETで状態変更しているならAPI設計を修正し、リンク経由の実行を廃止します。 |
2 | セッションCookieの送信 | Cookieが送信されていればトークン・送信元検証を確認します。 | SameSite、Domain、Path、Secure、期限、HTTPS終端を調べます。 |
3 | CSRFトークンの発行と送信 | 値があるならサーバー保存値との一致、エンコード、更新タイミングを確認します。 | HTMLのhiddenフィールド、metaタグ、トークン取得API、Axios等の設定を修正します。 |
4 | Origin、Referer、Sec-Fetch-Site | 許可値と一致すればアプリケーション側の検証処理を確認します。 | 正規オリジンの登録、リバースプロキシ設定、フォールバック方針を見直します。 |
5 | CDN・キャッシュ・複数タブ | 古いHTMLが配信されていればトークン更新・キャッシュ制御を調整します。 | セッションの保存先、ロードバランサーのスティッキー設定、時刻ずれを調べます。 |
419エラーの典型原因
419 Page Expiredは、Laravelでセッション期限切れやCSRFトークン不一致が発生した際に返されることが多い応答ですが、アプリケーションの例外ハンドラー設定によって実際のステータスコードは異なる場合があります。ログイン画面を長時間開いたままにした、別タブでログアウトした、デプロイで暗号鍵やセッションが切り替わった、CDNが古いトークン入りHTMLを返した、といった条件で発生します。
まず失敗時にセッションCookieが送信されているかを確認します。Cookieがあるのに419となる場合は、画面表示時のトークンとサーバーが保持するセッションの対応が切れている可能性があります。トークン取得APIがあるSPAでは、ログイン直後、セッション更新後、419発生時の再取得処理を設けると、利用者に無意味な再操作をさせずに済みます。
403エラーの典型原因
403 Forbiddenは、CSRF検証だけでなく認可、Origin検証、WAF、Fetch Metadataの拒否でも返されます。アプリケーションログに「CSRF token mismatch」「origin rejected」「permission denied」などの理由を残せるなら、障害切り分けの速度が変わります。
クロスオリジンSPAで403が出る場合は、リクエストのOriginとサーバーが許可したOriginが完全一致するかを見ます。開発環境のポート番号、本番のサブドメイン、HTTPとHTTPSの違いも別オリジンです。許可設定が確認できれば対象環境だけに正規Originを追加し、確認できなければワイルドカード許可ではなく、BFF経由または同一オリジン配信へ設計を寄せます。
再発を防ぐテスト項目
修正後は、正規画面からの更新が成功することだけでなく、外部オリジンからのPOST、トークン欠落、トークン改ざん、期限切れトークン、別ユーザーのトークン、Origin不一致、Sec-Fetch-Siteがcross-siteの要求が拒否されることを自動テストに入れます。
株式会社クロス・コミュニケーションは、共有サーバーに脆弱性診断ツール「Vex」を導入し、深夜の自動実行を含めてメンバーが診断できる体制を構築したと公表しています。リリース前の単発診断だけでなく、コード変更後や設定変更後にも再検証できる運用を作ると、CSRF保護の例外設定が増えた際に把握しやすくなります。
▲ CSRFエラー（419 / 403）発生時のデバッグフロー
CSRF攻撃による被害事例
CSRFの直接被害は不正な操作実行ですが、認可不備やXSSなどが重なると、情報流出やサービス設定の乗っ取りへ影響が広がる場合があります。
事例を読む際は、「CSRFだけで何ができたか」と「別の脆弱性や運用不備が加わった結果、何が起きたか」を分けて評価します。この整理をしないと、対策の優先順位が曖昧になり、CSRFトークンだけで防げない問題まで同じ対策に期待してしまいます。
横浜市ホームページのなりすまし書き込み
横浜市ホームページを巡る事件では、CSRF攻撃の手法が用いられ、利用者があたかも書き込みを行ったように偽装される事態が起きたと伝えられています。詳細な原因の確認には横浜市の公式発表資料を参照してください。この事例は、投稿機能のように一見すると金銭被害と距離がある機能でも、利用者の信用や運営組織の信頼を損ねることを示しています。
投稿、問い合わせ、レビュー、社内ワークフローの承認コメントなど、本人性が意味を持つ機能では、状態変更としてCSRF保護を適用します。公開フォームのスパム対策と、ログイン利用者になりすますCSRF対策は別の問題であるため、CAPTCHAだけで済ませない設計にします。
EC-CUBE関連の脆弱性
EC-CUBEと関連プラグインでは、管理画面に関するCSRF脆弱性が報告されてきました。CSRF単体の直接的な影響については、各脆弱性報告（JVNやEC-CUBE公式のセキュリティアドバイザリ）に記載された管理操作の不正実行の範囲で評価します。
一方、IPAは2019年12月に、EC-CUBEを利用するサイトで情報漏えい被害が増加しているとして、利用者へ対策を呼びかけています。CSRFがその流出に直接寄与したかどうかは公式一次資料から明確に裏付けられていないため、断定は避けます。管理画面への不正操作、スクリプト埋め込み、認可不備など複数の弱点が連鎖すると、被害が拡大します。
事例から得る実務上の判断
管理者向け機能は、利用者向け画面よりもCSRF対策の優先度を上げます。理由は、ユーザー削除、権限変更、外部連携、決済設定、テンプレート変更のように、1回のリクエストで影響範囲が広がる処理が集中するためです。
情シス部門では、管理画面の状態変更URLを棚卸しし、CSRFトークンの有無だけでなく、再認証、操作ログ、権限分離、承認フローの有無まで確認します。変更ログを取得できれば、トークン検証の追加後に拒否されたリクエスト数と正規操作への影響を比較できます。ログを取得できない場合は、まず管理操作をテスト環境で洗い出し、重要処理から保護を追加する順序が現実的です。
よくある質問
CSRF対策では、SameSiteの適用範囲、CORSとの関係、419・403エラーへの対応を正しく区別すると、不要な保護無効化を避けられます。
CSRFエラーで最初に確認する項目
Q：419 Page Expiredまたは403 Forbiddenが発生したとき、最初に何を確認しますか？
A：最初に、失敗したリクエストのHTTPメソッド、セッションCookie、CSRFトークンの送信有無を確認します。Cookieとトークンが揃っている場合は、Origin・Referer・Sec-Fetch-Site、CDNキャッシュ、サーバー側の拒否ログへ調査を進めます。
SameSite=Lax設定下の注意点
Q：SameSite=Laxを設定していれば、CSRFトークンは不要ですか？
A：不要にはなりません。トップレベルナビゲーションのGETではCookieが送信される条件があり、状態変更をGETで実装していれば危険です。状態変更を安全なメソッドへ移し、トークンまたはOrigin検証をサーバー側で実施します。
CORSとCSRF対策の関係
Q：CORS設定があれば、CSRF対策は済んでいますか？
A：CORS単独では、一般的なフォーム送信によるCSRFを防げません。ただし、カスタムヘッダーを必須にし、許可Originを固定したCORS設定を組み合わせる場合は、CSRF防御の一層として機能します。
SPAでのフレームワーク保護
Q：SPAで419エラーが出るため、フレームワークのCSRF保護を無効化してもよいですか？
A：無効化しません。トークン取得、ヘッダー付与、セッション更新の実装を見直し、ブラウザ以外の通信だけを別の認証・署名方式へ分離します。保護を全体で外すと、画面経由の状態変更APIまで無防備になります。
まとめ
CSRF対策では、Cookieが自動送信されることを前提に、状態変更処理を守ります。最初の一歩は、削除・権限変更・認証情報変更・決済設定などのURLを洗い出し、GETで状態変更している処理をなくすことです。その後、フレームワークのCSRF保護を有効にし、SameSite属性、Origin検証、Fetch Metadata、重要操作時の再認証を構成に合わせて重ねます。
明日からは、まず管理画面のPOST・PUT・PATCH・DELETEを1本選び、トークン欠落時に419または403で拒否されるかをテストします。拒否されない場合は、保護の実装漏れとして優先的に修正します。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
