「自社サイトのお問い合わせフォームや会員ページは安全だろうか」
「セキュリティ用語で聞く『CSRF』って、XSSと何が違うの?」
Webサイトで会員登録やログイン機能を備えたり、オンラインで各種申請を受け付けたりする企業が増える一方、ユーザーの「なりすまし」を狙ったサイバー攻撃のリスクも高まっています。
その代表的な攻撃手法であり、担当者が知っておくべき脆弱性が「クロスサイトリクエストフォージェリ(CSRF)」です。
CSRFは、ユーザー本人が気づかないうちに、ブラウザを通じて勝手にWebサイトへ「操作のリクエスト(要求)」を送らせる攻撃です。
本記事では、企業担当者様向けに、CSRFのリスクや被害事例、XSSとの違い、そして「自社サイトを守るために明日から何をすべきか」をわかりやすく解説します。
1. 3分でわかる「クロスサイトリクエストフォージェリ(CSRF)」とは?
CSRFを一言でいうと?
CSRF(Cross-Site Request Forgery)とは、攻撃者が用意した罠(悪意のあるサイトやメールのリンク)をユーザーに踏ませることで、「ログイン中のWebサイトで、ユーザー自身の権限を使って勝手に意図しない操作(注文、変更、投稿など)を実行させる攻撃」です。
「フォージェリ(Forgery)」には「偽造」という意味があり、ユーザーの代わりに偽のリクエスト(操作指示)をWebサイトへ送信させることからこの名前がついています。
「なりすまし」で勝手に操作されてしまう恐怖
たとえば、あなたが普段使っているECサイトや社内システムにログインしたまま、別の怪しいWebサイトを開いてしまったとします。
そのサイトに仕組まれた罠によって、バックグラウンドでECサイトへ「パスワード変更」や「高額商品の購入」という指示が勝手に送られてしまう——これがCSRFの典型的な怖さです。
Webサーバー側からは「正当にログインしている本人からの正しい操作」に見えてしまうため、攻撃を防ぎにくく、被害に遭ったユーザーも「自分が操作した」ことに気づきにくいのが特徴です。
とは?企業担当者が知っておくべきリスクと対策-320x180.png)
2. CSRFでよくある「XSSとの違い」とは?
セキュリティ対策で必ずセットで出てくる「XSS(クロスサイトスクリプティング)」と「CSRF(クロスサイトリクエストフォージェリ)」。
混同されがちですが、企業担当者としては以下の違いを押さえておけば十分です。
| 項目 | XSS(クロスサイトスクリプティング) | CSRF(クロスサイトリクエストフォージェリ) |
| 攻撃の狙い | 悪意のあるプログラム(JavaScript)を実行させる | 本人になりすまして「操作の指示」を送らせる |
| 主な被害 | 画面の偽装、個人情報の盗聴、Cookieの強奪 | パスワード変更、勝手な退会、不正な購入や書き込み |
| たとえ | サイト内に「毒(悪質なプログラム)」を仕込む | ユーザーに「勝手な契約書にハンコを押させる」 |
どちらも自社サイトの利用者や顧客に直接被害を及ぼす点では共通していますが、CSRFは特に「状態が変わる操作(登録・変更・削除・購入)」を行うページで発生します。
3. もし自社サイトにCSRFの脆弱性があったら?被害事例
もし自社が運営するWebサイト(会員ページや問い合わせシステムなど)にCSRFの穴があると、以下のような重大な被害が発生する可能性があります。
- ログインパスワードやメールアドレスの強制変更:ユーザーの知らないうちにアカウント情報が書き換えられ、アカウントを乗っ取られます。
- 不正な商品の購入や課金:ログイン状態を利用して、勝手に高額な注文や決済処理を行われてしまいます。
- 掲示板やSNSへの不正投稿・掲示:ユーザーの名義を使って、犯罪予告や誹謗中傷などの書き込みを勝手に投稿させられます(過去には警察が出動する事件に発展した例もあります)。
- 退会手続きの強行:ユーザーのデータを勝手に削除・退会させられてしまいます。
結果として、自社サイトは「勝手に不正操作をされてしまう危険なサイト」として評価が失墜し、顧客対応や返金対応、信頼回復に向けた多大なコストが発生してしまいます。

4. 企業担当者が明日から実施・確認すべき5つのポイント
プログラミングコードを書かない情シス・総務の担当者様でも、自社サイトをCSRFから守るためにできる「実務的なアクション」が5つあります。
1.1. 制作会社・ベンダーに「CSRF対策」を確認する:外部との連携。
Webサイトの制作やシステム開発を外注している場合、「フォームやログイン後の変更画面でCSRF対策(ワンタイムトークンの検証など)は実装されていますか?」と開発担当者に確認しましょう。
2.2. CMS(WordPress等)やプラグインを最新に保つ:基本のキ。
自社サイトでWordPressなどを使っている場合、本体や問い合わせフォーム系プラグインの更新を定期的に行いましょう。
古いプラグインの不備からCSRFの穴が見つかるケースは非常に多いです。
3.3. パスワード再入力・二要素認証(MFA)を挟む:重要処理のガード。
パスワード変更やメールアドレス変更、決済などの重要な処理を行う画面では、処理直前に「現在のパスワードの再入力」や「ワンタイムコードの入力」を必須とする仕組みを導入します。
はなぜ必要?社員に面倒くさがられないための説明のコツ-160x90.png)
4.4. 定期的な「Web脆弱性診断」を実施する:プロの診断。
年に1回やサイトのリニューアル時などに、プロのセキュリティ業者による脆弱性診断を受け、自社サイトにCSRFなどの抜け穴が残っていないかチェックしてもらいましょう。
5.5. サイト管理者の「セッション管理」を徹底する:運用ルール。
自社サイトの管理画面を操作した後は、必ず「ログアウト」する習慣を社内に徹底します。
ログインしたまま別のWebサイトをブラウジングするリスクを減らすことができます。
5. WAFでCSRFは防げる?
よくある質問として「WAF(Web Application Firewall)を導入していればCSRFも防げますか?」という声があります。
結論から言うと、「WAFだけではCSRFを完全に防ぐことはできません」。
WAFは通信の中に含まれる悪意あるコード(XSSやSQLインジェクションなど)を検知するのが得意ですが、CSRFのリクエスト自体は「見た目が普通の正当なアクセス(ただのフォーム送信)」に見えるため、WAFをすり抜けてしまうことがあります。
そのため、CSRF対策は「Webアプリケーション側での正しいプログラム実装(トークン検証など)」が根本対策となります。WAFはあくまで総合的なセキュリティを高める「多層防御の1層」として捉えておきましょう。

6. 担当者によくある質問(FAQ)
Q1. 常時HTTPS(SSL化)していればCSRFは防げますか?
A1. 防げません。
HTTPS(鍵マーク)は「通信の盗聴や改ざんを防ぐ」ための暗号化技術です。
暗号化された安全な通信経路の中で「なりすましリクエスト」が送られてしまうため、CSRFを防ぐ効果はありません。システム側での対策が必要です。
Q2. 制作会社に「CSRF対策はできていますか?」と聞いて、どう返ってくれば安心ですか?
A2. 「CSRFトークン(ワンタイムトークン)による検証を行っています」「重要処理時にパスワード再入力を求めています」という回答があれば安心です。
「WAFを入れているので大丈夫です」「通信を暗号化(SSL化)しているので問題ありません」といった回答の場合は、対策の認識がズレている可能性があるため注意が必要です。
まとめ:自社ユーザーの「信頼」と「アカウント」を守るために
クロスサイトリクエストフォージェリ(CSRF)は、自社サービスを利用するお客様が「知らぬ間に加害者・被害者に仕立て上げられてしまう」という、企業にとってブランドイメージに関わる重大なリスクです。
- ユーザーが罠リンクを踏むことで、自社サイト上で「勝手な注文や設定変更」を実行させられてしまう。
- パスワード変更、個人情報の書き換え、不正投稿などの被害が発生する。
- 「制作会社への対策確認(トークン検証など)」「CMS・プラグインの最新化」「重要な処理での再認証」を確実に進めることが防御の要。
まずは自社サイトでお問い合わせフォームや会員ページを管理している担当部署・制作会社へ「うちのサイトのCSRF対策はどうなっていますか?」と確認を取ることから始めてみましょう。
情報セキュリティ研修をご検討中の方へ
当サイトでは、企業・自治体向けに以下のサービスをご提供しています。
- 研修動画パッケージ(買い切り型)
- 講師派遣による対面・オンライン研修
- 社内啓発に活用できる無料「情報セキュリティ10箇条」ポスター
動画研修には、スライド一式・理解度確認テスト・研修実施報告書テンプレート・社内掲示用ポスターも付属しており、研修担当者の負担軽減にも役立ちます。
料金やカリキュラムの詳細は、[情報セキュリティ研修サービス一覧] をご覧ください。
とは?企業担当者が知っておくべきリスクと対策.png)
