検証した主張
「POSTだけを一律に厳しく制限すれば、すべてのAPI攻撃を安全に防げる。」
発見元は調査の入口であり、判定の根拠には使用していません。まず守る操作を定義する
認証試行、パスワード再設定、問い合わせ送信、購入確定など、回数が意味を持つ操作を選びます。例示する /api/session は架空のパスです。URL全体やIPだけの一律制限より、対象ホスト・パス・HTTPメソッドを合わせた条件を考えます。
GETでも高負荷の検索やデータ列挙が起こり得ます。「POSTだけ見れば十分」ではありません。
通常値から閾値を決める
Security Analyticsで平日・休日・キャンペーン時などのピークと、正規の再試行を確認します。会社や学校の共有IPでは多人数が一つの送信元に見えるため、IP単独のカウントで誤検知する可能性があります。
最初は記録・低影響のアクションで傾向を見て、必要な範囲へ段階的に強めます。プランによって使える条件やルール数は違うので、設定画面で確認してください。
WAFで認証そのものは代替できない
レート制限は大量アクセスの抑制です。アプリ側の認証、権限確認、ロックアウト方針、監査ログは別途必要です。攻撃を受けたときは、制限件数だけでなくアプリの認証失敗と成功も照合します。
APIクライアントが人間向けチャレンジに対応できない場合があるため、対応策はクライアントの種類で分けます。
検証条件・対象環境
| 対象プラン | 製品・契約プランで機能と表示範囲が異なる |
|---|---|
| 地域 | 提供地域・利用環境で表示や条件が異なる場合あり |
| 利用面 | Cloudflare Dashboard / Webサイト・API |
| 提供状態 | 2026年9月22日時点の公式公開資料。ダッシュボードの名称・契約条件は変更され得る |
| 実機確認 | Cloudflare公式資料で機能と制限を照合しました。個別のサイト・アカウントで設定変更や攻撃の再現はしていません。 |
| 次回見直し | 2026.10.22 |
よくある質問
何回から制限すればいいですか？
対象のパスとメソッド、通常時のピーク、共有IP、正規クライアントの再試行を確認してから制限を設計します。一律の低い回数制限は正規利用を止めます。
更新履歴
公式資料を確認し、固有の利用情報を含まない一般的な手順・注意点として整理。
実機検証は未実施のため、根拠レベルを公開基準に合わせてAからBに訂正。
情報源
一次情報と発見元を区別し、各ページの公開日と確認日を記録しています。
- Rate limiting best practices
対象パス・メソッド・閾値の決め方。
公開: 公開日未確認（閲覧日を記録）確認: 2026.09.22 - Security Analytics (new dashboard)
TrafficとEventsの対象・Workersサブリクエストの扱い。
公開: 公開日未確認（閲覧日を記録）確認: 2026.09.22 - Bot Fight Mode
Freeのボット対策とAPIへの影響。
公開: 公開日未確認（閲覧日を記録）確認: 2026.09.22