検証した主張
「404は絶対に安全、200は攻撃成功、403は完全に防御できた証拠である。」
発見元は調査の入口であり、判定の根拠には使用していません。404が多いときは何が起きているか
存在しない /admin-test のような架空パスへの404は、一般的な探索かもしれません。ただし、パスが存在しないことと、同じ送信元が別パスで成功していないことは別です。頻度、パスの変化、同時期のアプリログを確認します。
Cloudflareのブロックページが返した状態と、オリジン・Workerが返した状態を混同しないよう、Edge/Originの指標を確認します。
200を「認証成功」と読まない
ログイン画面のHTML、公開APIの応答、空のJSON、アプリ内の失敗メッセージが200で返る実装もあります。HTTP 200だけでデータの漏えいや認証成功を認定できません。
逆に、200が急増した重要APIなら調査対象です。セッション、権限、操作履歴をアプリ側で確認し、必要なら秘密情報の変更やアクセス停止などの対応を判断します。
403と5xxも別の問い
403は拒否応答ですが、どのルール・層が返したかで意味が変わります。5xxはEdge、Worker、オリジンのどこに原因があるかを先に切り分けます。
安全性の結論には、アクセス経路、認証、返却データ、変更結果を揃えた証跡が必要です。
検証条件・対象環境
| 対象プラン | 製品・契約プランで機能と表示範囲が異なる |
|---|---|
| 地域 | 提供地域・利用環境で表示や条件が異なる場合あり |
| 利用面 | Cloudflare Dashboard / Webサイト・API |
| 提供状態 | 2026年9月22日時点の公式公開資料。ダッシュボードの名称・契約条件は変更され得る |
| 実機確認 | Cloudflare公式資料で機能と制限を照合しました。個別のサイト・アカウントで設定変更や攻撃の再現はしていません。 |
| 次回見直し | 2026.10.22 |
よくある質問
200が出たら攻撃は成功ですか？
HTTPステータスはリクエストへの応答分類で、認証や侵害の成否そのものではありません。EdgeとOriginのどちらが返したか、アプリのログを合わせて見ます。
更新履歴
公式資料を確認し、固有の利用情報を含まない一般的な手順・注意点として整理。
実機検証は未実施のため、根拠レベルを公開基準に合わせてAからBに訂正。
情報源
一次情報と発見元を区別し、各ページの公開日と確認日を記録しています。
- HTTP status codes
EdgeとOriginのステータスコード。
公開: 公開日未確認（閲覧日を記録）確認: 2026.09.22 - Security Analytics (new dashboard)
TrafficとEventsの対象・Workersサブリクエストの扱い。
公開: 公開日未確認（閲覧日を記録）確認: 2026.09.22 - Cloudflare 5xx errors
5xxエラーの原因別切り分け。
公開: 公開日未確認（閲覧日を記録）確認: 2026.09.22