CSRF（クロスサイトリクエストフォージェリ）とは
CSRFとは、あるWebサービスにログインしたままの利用者に、別の悪意あるページを開かせることで、本人が意図していない操作（送金、設定変更、投稿など）をそのサービスに対して実行させる攻撃のことです。
言い換えると「本人の手を借りて、本人になりすます」攻撃です。正式名称は Cross-Site Request Forgery で、直訳すると「サイトをまたいだリクエストの偽造」です。「シーサーフ」と読まれることもあります。
仕組みとポイント
CSRFが成立するのは、ブラウザが「ログイン状態を示すCookie」を、どのページから送られたリクエストにも自動で付けてしまう性質があるためです。
- 利用者が正規のサービスにログインする（ブラウザにログイン情報のCookieが保存される）
- ログインしたまま、攻撃者が用意したページを開く（メールのリンク、掲示板の書き込みなど）
- そのページに仕込まれたフォームや画像の読み込みが、正規のサービスにリクエストを送る
- ブラウザが自動でCookieを付けるため、サービス側は本人の操作だと判断して処理してしまう
XSSとの違い
名前が似ているXSSとよく混同されますが、狙いと仕組みが異なります。
| 観点 | CSRF | XSS |
|---|---|---|
| 攻撃の舞台 | 攻撃者が用意した別のサイト | 狙われたサイト自身 |
| 実行されるもの | 正規サービスへの「操作のリクエスト」 | 悪意のあるスクリプト |
| 主な被害 | 意図しない送金・設定変更・投稿 | 情報の盗み取り、なりすまし、画面の改ざん |
| 基本の対策 | リクエストの正当性の確認 | 表示時のエスケープ |
なお、XSSの脆弱性があると、CSRF対策をすり抜けられる場合があります。両方の対策が必要です。
実務での使い方・具体例
開発での主な対策
- CSRFトークン：フォームを表示するたびに推測できない値を発行し、送信時にその値が正しいかを確認します。攻撃者のページからはこの値を知りえないため、偽のリクエストを見分けられます。多くのフレームワークが標準機能として備えています。
- Cookieの SameSite 属性：別サイトからのリクエストにCookieを付けないようにする設定です。被害を大きく減らせますが、これだけに頼らず他の対策と組み合わせます。
- 重要な操作の再確認：送金、メールアドレスやパスワードの変更、退会などは、パスワードの再入力や確認画面を挟みます。
- 状態を変える操作にGETを使わない：URLを開いただけでデータが変わる作りは、CSRFの被害を受けやすくなります。
架空の例：管理画面の設定変更
ある会員制サービス（架空）の管理画面で、URLにアクセスするだけで会員の権限を変更できる機能がありました。CSRF対策が入っていなかったため、管理者がログインしたまま外部のページを開くと、そのページから権限変更のリクエストが送られる危険がありました。脆弱性診断での指摘を受け、状態を変える操作をすべてフォーム送信に変え、フレームワークのCSRFトークン機能を有効にしました。あわせて、権限変更の操作を監査ログに記録するようにしています。
対策が特に必要な機能
- お金や契約に関わる操作（購入、送金、プラン変更）
- アカウント情報の変更（メールアドレス、パスワード、連絡先）
- 権限やユーザーの追加・削除
- 公開範囲を変える操作（投稿、共有設定）
発注側としては、これらの機能について「どのような対策を入れているか」を開発会社に確認し、公開前の脆弱性診断で実際に防げているかを検証してもらうのが確実です。
外部サービスとの連携部分の扱い
決済サービスや外部システムからの通知を受け取る入口では、利用者のブラウザを経由しないため、通常のCSRFトークンの仕組みが使えないことがあります。その場合は、送信元が正規のサービスであることを署名などで確認する別の方法を用意します。対策を外した入口がどこにあり、代わりにどう守っているかを一覧にしておくと、後からの点検がしやすくなります。
よくある誤解と注意点
- ログインしていれば安全、ではない：ログイン中であることこそが、CSRFの前提条件です。
- APIなら関係ない、とは限らない：Cookieでログイン状態を管理するAPIは、CSRFの対象になりえます。認証方式に応じた対策を確認しましょう。
- フレームワークの機能を無効にしない：外部連携の都合でCSRFチェックを外す場合は、その経路に別の確認方法を用意します。
- 社内システムも対象：社内向けの管理画面でも、担当者が外部のページを開けば攻撃は成立します。
関連用語
- XSS（クロスサイトスクリプティング）：CSRFと並ぶ代表的なWebアプリの脆弱性
- JWT（JSON Web Token）：認証情報の受け渡し方式の一つ。保存方法によってCSRFへの考え方が変わる
- 監査ログ：重要操作の記録。不正な操作の発見に役立つ
- フレームワーク：CSRFトークン機能を標準で備えることが多い開発の土台
- OAuth：外部連携の認可の仕組み。実装時にCSRF対策が必要になる場面がある
Otsumuに相談できること
CSRFは、フレームワークの標準機能を正しく使えば多くを防げる一方、外部連携や古い管理画面などで対策が外れていることがあります。Otsumuでは、重要な操作を洗い出したうえで、認証方式に合った対策を組み込んだ開発を行っています。詳しくはシステム開発や管理画面開発のページをご覧ください。
診断結果への対応方針に迷ったら、30分の無料相談でお聞かせください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01