@csrf_exemptが招くCSRF攻撃の本当の怖さ AIの提案を信じた結果
公開日：
※当サイトはアフィリエイトプログラムを利用しています。
「動いた！」とAIの提案に従って加えた、たった一行の@csrf_exempt。
その判断が、あなたのアプリをCSRF攻撃に対して無防備な状態にし、何万人もの利用者を危険にさらすことがあります。
本記事では、なぜその一行が致命的なのか、実際の被害例とともに、開発者と利用者の両視点から解説します。
前回の記事「バイブコーディングで作ったアプリは本当に安全？」で指摘したセキュリティリスクの中でも、特に深刻なのがこの@csrf_exempt（イグゼンプト）問題です。
CSRFとは？
CSRF（Cross-Site Request Forgery：クロスサイト・リクエスト・フォージェリ）とは、ウエブアプリケーションの脆弱性を悪用し、ユーザーが意図しない操作を強制的に実行させるサイバー攻撃のこと。
ブラウザは同じドメインへのリクエストに対して、自動的にCookie（ログイン情報）を送信してしまうという特性があり、これを悪用します。
例えば、あなたがログインしているウエブサイトに対して、あなたが意図しないリクエストを送信するように仕向けます。
悪意のあるウエブページにアクセスさせることで、そのページに埋め込まれた不正なリクエストを、ユーザーがログイン中の別のウエブサイトに送信。
CSRFによるサイバー攻撃方法
| 手順 | あなた | 罠サイト | 通販サイト |
|---|---|---|---|
| ① | 通販サイトにログイン （タブ開きっぱなし） |
- | ログイン状態を記憶 |
| ② | SNSで「猫の動画」を クリック |
罠サイトが開く （画面には猫の動画） |
- |
| ③ | 動画を見ている （気づかない） |
裏で自動実行： 「通販サイトで商品を買え！」 という命令を送信 |
命令を受信 |
| ④ | - | - | CSRF対策あり： 「身元証明書がない！拒否！」 @csrf_exempt あり： 「はい、実行します」 |
| ⑤ | 結果： ✅ 安全：何も起きない ❌ 危険：勝手に購入される |
- | - |
普通のサイトの仕組み
☝️あなたがページを開くと、サイトは裏側で「身元証明書（CSRFトークン）」をあなたのブラウザに埋め込む（画面には表示されない）。
☝️何か操作するたびに、その身元証明書を自動的に確認して「このサイトの正規の画面から送られた操作だ」と判断する。
☝️外部から勝手な命令が来ても、「身元証明書がないからダメ！」とはじく。
@csrf_exemptを付けると
🆖この身元証明書チェックが完全にオフになる。
🆖外部（罠サイト）から「この人の投稿ボタンを勝手に押せ」という命令が来ても、「はい、わかりました！」と通してしまい、ブラウザは同じドメインへのリクエストに対して、自動的にCookieを送信してしまう。
ワンタイムパスワードとの違い
CSRFトークンは、二段階認証で使う「ワンタイムパスワード」とは別物です。混同しやすいので、違いを表で確認しましょう。
| CSRFトークン （この記事で説明しているもの） |
ワンタイムパスワード （二段階認証のOTP） |
|
|---|---|---|
| 何を確認するのか | この操作が、正規のサイトの画面から送られたものか | この人が本当に本人かどうか |
| あなたは何をするか | 何もしない（自動的に処理） | 自分で入力する |
| 画面に表示されるか | 表示されない（裏側で勝手に動いている） | 表示される（入力欄がある） |
| いつ使われるか | フォーム送信のたびに毎回 | ログイン時や重要な操作時のみ |
| どのくらい有効か | セッション中ずっと、または数時間 | 30秒～数分で使い捨て |
| 何から守るのか | CSRF攻撃 | 他人によるなりすまし |
利用者が受ける具体的被害
CSRF攻撃の目的は、犯人にとっての金銭的利益や、それにつながるアカウント乗っ取りの可能性が高いため、金融取引や個人情報の変更といった機密性の高い処理を扱うサイトが狙われやすい傾向にあります。
- 狙われやすいサイトの例
- ・ネットバンキング、証券会社
- ・通販サイト、決済サービス
- ・SNS、コミュニティサイト
- ・行政サービス、公共料金の変更サイト
フィッシングサイトではない
ここで出てくる「罠サイト」は、フィッシングサイトとは違います。見た目は普通のブログや動画サイト、SNSの投稿などで、一見すると何の問題もないように見えます。
フィッシングサイトは偽のウエブサイトを作成して、あなたにパスワードを入力させて盗む。
CSRF攻撃の罠サイトは、攻撃者は利用者のログイン情報を直接盗む必要がない。
つまり、あなたが通販サイトAにログインしたまま、全然関係ないブログBを開いただけで、本物の通販サイトAで勝手に買い物されてしまうのがCSRF攻撃です。
フィッシングサイトなら「怪しいサイトには情報を入力しない」という自衛策がありますが、CSRF攻撃はあなたが何も入力していないのに被害に遭います。
しかも、本物のサイトのログには「あなたが正常に操作した」という記録が残るため、「あなたが自分で買ったんじゃないですか？」と疑われることも。
例えばネットバンクにログイン中の利用者が、知らないうちに振込処理を実行させられる、ショッピングサイトでは、勝手に商品を購入させられる被害が実際に発生しているんですね。
ケース1 あなたの身にも起こる悪夢
例えば、あなたが通販サイトにログイン中、たまたまSNSで見つけた「猫の動画」のリンクをクリック。
その裏で、勝手に50万円分の商品が購入され、配送先も犯人の住所に変更されていた・・・気づいたときには手遅れです。
- 悪いのは？
通販サイトの開発者が@csrf_exemptを消し忘れたこと - 罠サイト
犯人が用意したもの（猫の動画） - 被害が起きた理由
通販サイトのセキュリティが無効化されていたから
通販サイトがセキュリティ対策をしていれば、あなたが例え罠サイトを開いても被害は起きません。
ケース2 あなたの身にも起こる冤罪
例えば、あなたがSNSにログインしたまま、友人から送られてきた「面白いブログ」を開いた瞬間、あなたのアカウントで勝手に誹謗中傷の投稿や不正な口座開設の申請が行われていました。
後日、警察から連絡が来て初めて事態に気づきます。
- ・悪いのは？
SNSサイトの開発者が@csrf_exemptを消し忘れたこと - 罠サイト
犯人が用意したもの（友人から送られてきた「面白いブログ」） - 被害が起きた理由
SNSサイトのセキュリティが無効化されていたから
もしSNSサイトがCSRF対策をしていたら、あなたが「面白いブログ」を開いても、外部からの命令は「身元証明書がないからダメ！」とブロックされ、誹謗中傷の投稿も、口座開設の申請も実行されないということ。
「面白いブログ」を送ってきたのはあなたの友人ですが、友人に悪意があったわけではなく、こういったケースが考えられます。
- ☝️友人も知らずに拡散
- 犯人が作った「一見普通のブログ」
- ↓
- SNSで拡散される
- ↓
- 友人が「面白い！」と思ってシェア
- ↓
- あなたが開く
- ↓
- 裏で罠が発動
- ☝️友人のアカウントが乗っ取られている
- 犯人が友人のアカウントを乗っ取る
- ↓
- 友人のアカウントから「面白いブログだよ！」と自動送信
- ↓
- あなたが「友人からのメッセージなので安全」と思って開く
- ↓
- 裏で罠が発動
悪意はなく、罠だと知らずに共有した、または乗っ取られているので、やはりSNSサイトの開発者が@csrf_exempt を消し忘れたことに原因があるのです。
「信頼できる友人からのリンクだから安全」とは限らないのが、CSRF攻撃の怖いところですね。
主な被害パターン
利用者がそのサイトを使っている際、犯人の用意した「罠サイト」をうっかり開いた瞬間、以下のことが勝手に行われます。
アカウントの乗っ取り
登録メールアドレスとパスワードを勝手に変更され、二度とログインできなくなる。
勝手な決済・送金
通販サイトなら商品爆買い、ネットバンキングなら見知らぬ口座への送金。
犯罪の片棒を担がされる
あなたのアカウントで勝手に誹謗中傷を投稿され、不正な口座開設の申請をされ、警察があなたの家にやってくる。
利用者が@csrf_exemptの設定されたサイトにログインすると、そのブラウザは「誰からの命令でも、ログイン中のあなたの権限で実行できるモード」に突入します。
利用者はいつも通りブラウザを使っているだけなのに、裏側で勝手に操作され放題。
まさに、ガードレールのない崖っぷちの道を利用者に歩かせているようなものです。
実際に起きたCSRF攻撃の事件
CSRF攻撃は理論上の話ではなく、実際に国内外で深刻な被害が発生しています。
【日本】2012年 パソコン遠隔操作事件
横浜市のウェブサイトなどに小学校襲撃予告や犯罪予告が書き込まれ、複数の方が逮捕されました。
しかし後に、これらはすべてCSRF攻撃によって無関係な人のパソコンから勝手に書き込まれたものであることが判明し、誤認逮捕という最悪の事態となりました。
（上記の花子さんの例と同じことが、実際に起きたのです）
【海外】2020年 TikTok アカウント乗っ取り
TikTokでCSRF脆弱性が発見され、なんとワンクリックでアカウント乗っ取りが可能な状態でした。
攻撃者は任意のアカウントに新しいパスワードを設定。報告から3週間で修正されています。
【海外】2008年 ING Direct（オランダ銀行）不正送金
オンラインバンキングサイトにCSRF対策が一切なく、ログイン中のユーザーのアカウントから攻撃者が勝手に送金できる状態でした。
SSL認証があっても、CSRF対策がなければ意味がないことを示す事例です。
【海外】2021年 WordPress プラグイン
WordPressのプラグインのCSRF脆弱性により、50,000以上のサイトに悪意のあるコードが注入され、サイト利用者が罠のリンクを開かされる被害が発生しました。
他にも、Netflix（2006年）、YouTube（2008年）、McAfee（2014年）など、大手企業のサービスでもCSRF脆弱性が発見されています。
このような実例があることから、ネットバンキングでの勝手な送金や、通販サイトでの意図しない購入といった被害は、決して理論上の話ではなく、実際に起こり得る脅威なのです。
なぜユーザーには気づけないのか？
ユーザーが画面を見ただけで「このサイト、CSRF対策がオフになってる！」と気づくことは、まず不可能です。
見た目は100%正常
セキュリティチェックをオフにするコードは、サーバーの裏側で動く設定です。画面のデザインが変わったり、警告が出たりすることはありません。
「何も起きない」のが普通
攻撃を受けるまでは、普通にログインして普通に買い物もできます。
しかし裏では「誰でも鍵を開けられる状態」でドアが放置されているようなものと言えば伝わるでしょうか。
被害に遭うのは別のサイトを見た時
罠は、そのサービスの中ではなく、全然関係ない怪しいブログやSNSの短縮URLなどに仕込まれています。
そちらを開いた瞬間に、裏でこっそり操作されるので、異変に気づけません。
利用者は、自分がアクセスしたサイトが「まさかセキュリティをわざとオフにしている」とは思いませんよね。
「ちゃんとしたサイトっぽいから大丈夫だろう」という信頼が、たった一行のコードで裏切られている状態なんです。
開発者が徹底したい安全のためのセルフチェック
ここで疑問なのは「なぜ、この危険なコード@csrf_exemptを使ってしまうのか？」ということではないでしょうか。
決して悪気があるわけではなく、開発中の「動かないストレス」から逃げたい心理が原因であることがほとんどです。
エラーの壁
CSRF対策が有効な状態では、トークンを正しく受け渡す処理を書く必要があります。
これが初心者には少し手間に感じられます。
AIの提案
AIは「目の前のエラーを消すこと」を最優先するため、「じゃあ、この一行を足してチェックを一時的にスキップしましょう」と、安易な解決策を提案してきます。
デプロイの罠
開発中に「動いた！」と喜んで、そのスキップ設定を消し忘れたまま本番サーバーにアップ（デプロイ）してしまうと、世界中にセキュリティホールを公開することになります。
技術の進歩とAI時代の新たなリスク
現代の主要なWebフレームワーク（Django, Ruby on Rails, Laravelなど）は、開発者が何もしなくても最初から安全な「デフォルト・セキュア」の状態で動くように設計されています。
しかし、AIによる「動かないなら無効にしましょう」という提案は、この安全な設計をわざわざ20年前の危険な状態（2008年のING Direct不正送金事件の頃）へと逆戻りさせてしまいます。
AIの登場により、専門教育を受けていない人でもアプリを作れる素晴らしい時代になりました。
しかし、その裏側では「バイブコーディングで作ったアプリは本当に安全？」でも触れたように、基礎知識がないまま「爆弾」を抱えたアプリが公開されるリスクも急増しています。
reddit（レディット）には、こんな投稿もありました。2026年01月末に起きたことです。
「うちの会社のノリで仕事してるプログラマーたちはセキュリティに気を配ってなくて、痛い目にあったんだよね」と。
職場環境の愚痴も含め、外野から見れば興味深い話ですが、当事者にとっては笑えない事態です。
デプロイ前の徹底チェックリスト
「自分は大丈夫」という思い込みを捨て、機械的に以下の６点をチェックしましょう。
これは専門家コミュニティでも推奨されている、身を守るための作法です。
①@csrf_exemptを検索して撲滅する
プロジェクト全体のコードから、csrf_exemptやdisable_csrfといった文字列を検索してください。
# プロジェクト全体で一括検索するコマンド例
grep -r "csrf_exempt" . grep -r "disable_csrf" . ②「オフ」にするのではなく「正しく設定」する
エラーが出るのは、セキュリティが正しく機能している証拠です。
- フロントエンド（画面側）： フォームに
{% csrf_token %}などのタグを入れているか？ - API通信： HTTPヘッダーにトークンを含めているか？
③AIの提案を「翻訳」して理解する
AIが「テストのために無効にしましょう」と言ったら、それは「今だけガードレールを外して崖っぷちを走りましょう」と言っているのだと捉えてください。
開発が終わったら、必ずガードレールを戻さなければなりません。
④「Exempt（免除）」という単語を警戒するexempt（免除）、ignore（無視）、disable（無効）という文字がコードに出てきたら、「今、自分は危険なことをしている」という自覚を持ってください。
⑤「一時的」という言葉を信じない
「とりあえず後で直す」は、ほぼ確実に消し忘れます。
最初から「無効にする方法」ではなく、「正しくトークンを処理してエラーを消す方法」をAIに聞き直しましょう。
⑥環境変数で「本番だけは守る」
どうしてもテストで切りたい場合は、本番環境では絶対に無効化されない条件分岐を徹底します。
if settings.DEBUG: # 開発モード（テスト中）のときだけ無効化 もし放置したまま公開してしまったら？
もし@csrf_exemptを放置したまま公開し、実際にユーザーが被害に遭ってしまった場合、開発者には「技術的なミス」では済まされない重い責任がのしかかります。
以下の3つの側面から、そのリスクを忘れないでください。
1. 法的な責任
「わざとではない」は通用しません。最低限の安全性を確保しなかった「善管注意義務違反」として、損害賠償や慰謝料、最悪の場合は警察の捜査対象になることもあります。
2. 社会的信用の失墜
SNSでの拡散、取引先からの契約解除、Googleによる「危険なサイト」認定など、サービスそのものが死に至ります。
3. キャリアへの打撃
「杜撰な開発者」というレッテルを貼られ、数ヶ月から数年にわたり、事故対応と再発防止策の報告に追われることになります。
最後に、具体的な確認手順をまとめます。目視とツールの両方でガードを固めましょう。
①コードレビュー時の必須項目
目視による最終チェックです。
- □ プロジェクト全体を「csrf_exempt」で検索したか
- □ フォームやAPIヘッダーにトークン処理が含まれているか
- □
disableやignoreという不審な設定がないか
②自動検出ツールの活用
人間のミスを防ぐため、機械にチェックさせましょう。
方法1：GitHubのCodeQLやSemgrepを使う
自動で脆弱性を見つける「AIのようなツール」です。危険なコードを検知すると警告してくれます。
方法2：Gitのpre-commitフック（上級者向け）
保存（コミット）する瞬間に、禁止ワードがないか自動全検索する強力なガードです。
# 実行例：csrf_exemptが残っていたら保存をブロックする
if git grep -n "csrf_exempt"; then echo "ERROR: csrf_exempt found in code!" exit 1 fi ③デプロイ前の最終環境確認
DEBUG = True（開発モード）のまま公開すると、エラー時にソースコードが世界中に丸見えになります。
これは家の中をマジックミラー越しに見せているようなものです。
- ・
DEBUG = False（本番モード）になっているか - ・環境変数に危険な設定（無効化など）が残っていないか
もし、これらの設定に少しでも不安を感じるなら、公開を止め、信頼できるエンジニアにダブルチェックを依頼してください。
アプリユーザーができる自己防衛策
ユーザー側に非がないだけに、防ぎようがないと思われがちですが、被害を最小限にする以下の習慣をつけましょう。
①ログアウトは最大の自己防衛
CSRF攻撃は、あなたがログイン中であるこを悪用します。
銀行、SNS、通販サイトを使い終わったら、ブラウザを閉じるだけでなく、必ず「ログアウト」ボタンを押す習慣をつけましょう。
ログアウトしていれば、犯人が偽の命令を送っても、サイト側が「誰だかわからないので拒否」してくれます。
②「ログインしっぱなしのタブを減らす
ブラウザで何十個もタブを開き、すべてにログインしたままにするのは、攻撃の受付窓口を大量に開いているのと同じです。
使わないサイトはこまめに閉じましょう。
③シークレットモードの活用
重要なサイト（銀行、通販）にアクセスする際は、ブラウザのシークレットモードを使うと、セッションがタブを閉じた瞬間に消えるので安全性が高まります。
セッションとはログインしてからログアウトするまでの「通信のつながり」のこと。
このつながりが残っている間は、パスワードなしで操作ができてしまうため、使い終わったらこの「つながり」を断つ（ログアウトやブラウザを閉じる）ことが重要なのです。
④パスワードマネージャーの使用
パスワードマネージャーは、セッション管理にも役立ちます。
ログイン状態を適切に管理し、不要なセッションを残さない習慣がつきます。
⑤二段階認証の有効化
完全な防御にはなりませんが、被害を限定的にする効果があります。重要なアカウントには必ず設定しましょう。
⑥判断できないサイトには情報を入れない
「このサイト、セキュリティ大丈夫かな？」と少しでも不安に感じたり、自分で安全性が判断できなかったりする場合は、無理に利用しないことが最大の防御です。
いつも書いていますが、あなた自身で判断できないなら利用自体やめましょうね。
それでも、どうしてもサービスを利用する必要があるのなら、以下の点に目を向けてください。
✅運営者情報が明確か
会社名や住所、責任者名が正しく記載されているか？
✅大手サービスのログイン連携があるか
信頼できる大手の認証（GoogleやLINEなど）を使っているか、それとも独自にパスワードを作らせる形式か？
✅怪しい日本語やレイアウト崩れがないか
AIで急造されたサイトや詐欺サイトは、細部の日本語がおかしかったり、ボタンの配置が崩れていたりすることがあります。
動くと安全は別物
@csrf_exemptという一行のコードは、開発者にとっては「エラーを消す便利な魔法」に見えますが、利用者にとっては見えない危険な場所そのものです。
- 開発者の皆さんへ
- ・AIの提案を鵜呑みにせず、「なぜこのエラーが出るのか」を理解する
- ・「動いた」で満足せず、「安全に動いているか」を確認する
- ・デプロイ前の最終チェックリストを必ず実行する
- サービス利用者の皆さんへ
- ・ログアウトの習慣をつける
- ・重要なサイトはシークレットモードで使う
- ・怪しいサイトには重要な情報を登録しない
AIコーディングの時代だからこそ、「動く」と「安全」は別物だという認識を、開発者も利用者も持つ必要があります。