API が本番でトラフィックを受け取り始めたら、最初に保護するエンドポイント、適用する制限、正規クライアントをブロックせずに不正利用を監視する方法を決める必要があります。このガイドでは、そのプロセスを 5 段階で進めます。エンドポイントの棚卸し、暗号化接続の強制、想定どおりのトラフィックパターンへの制限、自動不正利用のブロック、結果の監視です。
中核のワークフローでは、Cloudflare Application Security(Web Application Firewall、WAF とも呼ばれます)の機能、SSL/TLS 設定、ボット検出 を使います。いずれも Free、Pro、Business プランで利用できます。Enterprise 向けの補足では、スキーマ検証、JSON Web Token(JWT)検証、シーケンス分析が必要なチーム向けに API Shield の機能を取り上げます。
セキュリティルールを設定する前に、API エンドポイントの一覧を作ります。一覧が揃っていないと、適切なパスに保護を当てられず、未知のエンドポイントがトラフィックを受け始めたときにも気づけません。
-
アプリケーションのルーティング設定を確認し、各エンドポイントを HTTP メソッドと想定パラメーターとともに一覧化します。
-
各エンドポイントをアクセスレベル(公開、認証済み、内部)で分類します。ファイルアップロードを受け付ける、決済を処理する、機密データを返すエンドポイントを優先します。
アクセスレベル 説明 エンドポイントの例 Public 認証不要 /api/status、/api/productsAuthenticated トークンまたはセッションが必要 /api/account、/api/ordersInternal 公開アクセスすべきでない /api/admin、/api/debug -
後のセクションでルール式を書くときの参照用に、一覧をスプレッドシートまたは OpenAPI スキーマファイルに記録します。すでに OpenAPI 仕様がある場合は、API Shield のスキーマ検証(下記の Enterprise 向け補足)にそのまま使えます。
API リクエストには、暗号化されていない接続で攻撃者に傍受されうる認証情報、トークン、レスポンスデータが含まれます。サーバーが HTTP を受け付けると、一部の API クライアントは静かに HTTP へダウングレードし、機密データを平文で送ります。エッジで HTTPS を強制すると、これを防げます。
暗号化モードを Full (Strict) にすると、訪問者と Cloudflare の間、および Cloudflare とオリジンサーバーの間のトラフィックが暗号化されます。このモードでは、オリジンに有効な証明書が必要です。
-
Cloudflare ダッシュボードで、SSL/TLS の Overview ページを開きます。
Overview を開く ↗ -
SSL/TLS encryption で Full (Strict) を選択します。
暗号化モードとその要件の詳細は SSL/TLS 暗号化モード を参照してください。
Always Use HTTPS は、アプリケーション内のすべてのサブドメインとホストについて、HTTP リクエストを HTTPS へリダイレクトします。クライアントが誤って暗号化されていない接続で API リクエストを送るのを防ぎます。
-
Cloudflare ダッシュボードで、SSL/TLS の Overview ページを開きます。
Overview を開く ↗ -
SSL/TLS 暗号化モード が Off になっていないことを確認します。暗号化がオフのときは、Always Use HTTPS オプションは表示されません。
-
Edge Certificates ページを開きます。
Edge Certificates を開く ↗ -
Always Use HTTPS をオンにします。
API は認証情報やトークンなど機密情報を運ぶことがあるため、その前提で適切な最小 TLS バージョンを選びます。
TLS 1.0 と 1.1 には既知の脆弱性があります。最小を TLS 1.2 にすると、古いプロトコルを使うクライアントからの接続を拒否します。
-
Cloudflare ダッシュボードで Edge Certificates ページを開きます。
Edge Certificates を開く ↗ -
Minimum TLS Version で TLS 1.2 を選択します。
詳細は Minimum TLS Version を参照してください。
Automatic HTTPS Rewrites は、HTML レスポンス内の HTTP リンクを HTTPS に書き換えます。JSON やその他の非 HTML コンテンツを返す API エンドポイントでは、この書き換えは不要です。API クライアントが書き換え後の URL をたどると、想定外の動作になることがあります。ドメインが API トラフィックだけを扱う場合は、この設定をオフにします。
-
Cloudflare ダッシュボードで Edge Certificates ページを開きます。
Edge Certificates を開く ↗ -
Automatic HTTPS Rewrites をオフにします。
正規の API クライアントは、予測可能なリクエストパターンを送ります。特定の HTTP メソッド、Content-Type: application/json などの想定ヘッダー、文書化されたパスへのリクエストです。Application Security の カスタムルール で、これらのパターンから外れたトラフィックをブロックできます。レート制限ルール は、クライアントあたりのリクエスト量に上限を設け、不正利用を防ぎます。
API クライアントは通常 Content-Type ヘッダーを付け、Authorization ヘッダーやカスタム API キーヘッダーを付けることもあります。これらのヘッダーがない API パスへのリクエストは、想定クライアントからのものではありません。
次のカスタムセキュリティルールは、Content-Type ヘッダーがない /api/ パスへのリクエストをブロックします。パスとヘッダーの条件は、自分の API に合わせて調整してください。
-
Cloudflare ダッシュボードで Security > Security rules を開きます。
Security rules を開く ↗ -
Create rule > Custom rules を選択します。
-
ルール名を定義します。例:
Block API requests missing Content-Type。 -
式エディターに次を入力します。
(starts_with(http.request.uri.path, "/api/") and not len(http.request.headers["content-type"][0]) > 0) -
Choose action で Block を選択します。
-
Deploy を選択します。
/api/users エンドポイントが GET と POST だけを受け付ける場合は、そのパス上のほかの HTTP メソッドをすべてブロックします。これにより、対応していないエンドポイントに対する PUT、DELETE、PATCH での探査を防げます。
-
Cloudflare ダッシュボードで Security > Security rules を開きます。
Security rules を開く ↗ -
Create rule > Custom rules を選択します。
-
ルール名を定義します。例:
Block unexpected methods on /api/users。 -
式エディターに次を入力します。
(http.request.uri.path eq "/api/users" and http.request.method ne "GET" and http.request.method ne "POST")パスと許可するメソッドは、エンドポイントに合わせて調整します。
-
Choose action で Block を選択します。
-
Deploy を選択します。
メソッドが制限されている各エンドポイントで、このパターンを繰り返します。許可メソッドが同じなら、or 演算子 で複数パスを 1 つのルールにまとめられます。
API エンドポイントは、ブラウザー描画なしで機械速度で呼べるため、Web ページより狙った不正利用を受けやすいです。レート制限は、1 クライアントが時間枠内に送れるリクエスト数に上限を設けます。
認証済みエンドポイントと未認証エンドポイントで、別々のレート制限ルールを作成します。未認証エンドポイント(ログイン、登録、パスワードリセット)は、クレデンシャルスタッフィング とブルートフォース攻撃の主な標的になるため、より厳しい上限が必要です。
次の例は、/api/auth/login へのリクエストを IP アドレスあたり 1 分に 10 件に制限します。パス、リクエストしきい値、期間はエンドポイントに合わせて調整してください。
-
Cloudflare ダッシュボードで Security rules ページを開きます。
Security rules を開く ↗ -
Create rule > Rate limiting rules を選択します。
-
わかりやすい名前を入力します。例:
Rate limit login endpoint。 -
Field ドロップダウンで URI Path を選びます。Operator を equals、Value を
/api/auth/loginにします。 -
With the same characteristics で IP を追加します。
-
When rate exceeds で Requests を
10、Period を 1 minute にします。 -
Then take action で Block を選択します。
-
Duration(緩和タイムアウト)を 1 minute にします。
-
Deploy を選択します。
レート制限のパラメーターとカウント特性の詳細は レート制限パラメーター を参照してください。
カウント特性に API キーを使う API 向けの例は レート制限ルールの例 を参照してください。
ボットはブラウザーのオーバーヘッドなしに、機械速度で API エンドポイントを呼び出します。API に対する一般的な自動攻撃には、認証エンドポイントへのクレデンシャルスタッフィング、一覧エンドポイント経由のデータスクレイピング、カートやチェックアウトエンドポイント経由の在庫操作があります。
Bot Fight Mode は、既知のボットパターンに一致するリクエストに Challenge を出します。ドメイン全体に適用され、すべてのプランで追加料金なしで利用できます。
-
Cloudflare ダッシュボードで Security Settings ページを開きます。
Settings を開く ↗ -
Bot traffic で絞り込みます。
-
Bot fight mode を開きます。
-
Bot fight mode をオンにします。
Bot Fight Mode は、監視ツール、CI/CD パイプライン、パートナー連携など、API への正規の自動トラフィックを妨げることがあります。正規のボットクライアントがある場合は、Bot Fight Mode をオンにする前に例外ルールを作成してください(次のセクションを参照)。
Bot Fight Mode の動作と制限の詳細は Bot Fight Mode を参照してください。
API が既知の自動クライアント(監視サービス、パートナー API、CI/CD システム)からトラフィックを受け取る場合は、Skip アクションのカスタムセキュリティルール を作成し、ボット保護から除外します。例外ルールは、次のセクションで Super Bot Fight Mode をオンにする前に作成します。
-
Cloudflare ダッシュボードで Security > Security rules を開きます。
Security rules を開く ↗ -
Create rule > Custom rules を選択します。
-
ルール名を定義します。例:
Skip bot protections for monitoring service。 -
既知のボットトラフィックに一致する式を組み立てます。たとえば、既知の User-Agent を持つ特定 IP 範囲からのリクエストを保護対象外にする場合:
(ip.src in {203.0.113.0/24} and http.user_agent contains "MonitoringBot")IP 範囲と User-Agent は、正規のボットクライアントに合う値に置き換えます。
-
Choose action で Skip を選び、All Super Bot Fight Mode rules を選択します。
-
Deploy を選択します。
Super Bot Fight Mode は、ドメイン全体に適用できる細かい制御を提供し、ボット種別ごとに異なるアクションを設定できます。
Super Bot Fight Mode を設定する手順は次のとおりです。
-
Cloudflare ダッシュボードで Security Settings ページを開きます。
Settings を開く ↗ -
Bot traffic で絞り込みます。
-
Super Bot Fight Mode を開きます。
-
Super Bot Fight Mode をオンにします。
-
各種類のトラフィックへの応答方法を、対応する編集アイコンを選んで設定します。
- 検証済みボットの詳細は、Verified Bots を参照してください。
- 対応ファイルタイプの詳細は、静的リソース保護 を参照してください。
- 不可視のコード注入の詳細は、JavaScript detections を参照してください。
- WordPress 最適化の詳細は、Super Bot Fight Mode for WordPress を参照してください。
Super Bot Fight Mode では、ボット種別ごとに異なるアクションを設定できます。
- 検証済みボットのブロックまたは許可
- Definitely automated traffic(ボットスコア が 1)に別アクション(許可、ブロック、Challenge)を設定
- Business プラン以上: Likely automated traffic(ボットスコア 2–29)に別アクションを設定
Super Bot Fight Mode はドメイン全体に適用され、パス単位のルールには対応していません。API パスごとに異なるボットしきい値を適用するには、Bot Management サブスクリプション(Enterprise)が必要です。
Application Security の 漏洩した認証情報の検出 は、受信リクエスト内のユーザー名とパスワードの組み合わせが、既知のデータ侵害に含まれていないかを確認します。この検出を使い、認証エンドポイントで侵害済み認証情報を含むリクエストをレート制限または Challenge します。
次のレート制限ルールは、以前漏洩したユーザー名とパスワードの組み合わせを含むリクエストを、IP あたり 1 分に 5 件に制限します。
| 設定 | 値 |
|---|---|
| Expression | cf.waf.credential_check.username_and_password_leaked |
| Counting characteristics | IP |
| Requests per period | 5 requests / 1 minute |
| Action | Block |
アカウント乗っ取り(ATO)検出 ID を含む完全な式は 緩和ルールの例 を参照してください。
セキュリティルールをデプロイしたあと、結果を確認して誤検知を特定し、しきい値を調整します。誤検知(正規クライアントがブロックされる)と見逃し(不正利用が通る)の両方に、調整が必要です。
Security Events は、ルールが一致したすべてのリクエストを、実行したアクションとトリガーしたルールとともに表示します。API パスのプレフィックスで絞り込み、Cloudflare が何をなぜブロックしているかを確認します。
-
Cloudflare ダッシュボードで Analytics ページを開きます。
Analytics を開く ↗ -
Events タブを選択します。
-
URI Path が
/api/で始まるフィルターを追加します。 -
イベントを確認します。ブロックされている正規クライアント(誤検知)を探します。誤検知のよくある兆候は次のとおりです。
- 既知のパートナー IP アドレスからのリクエスト
- 有効な API キーまたは認可ヘッダー付きのリクエスト
- 既知の User-Agent 文字列を持つ監視サービスからのリクエスト
誤検知を見つけた場合は、影響を受けたトラフィックを除外するようにカスタムルールを更新します。前のセクションの 例外ルールの手順 を参照してください。
レート制限のしきい値が厳しすぎると、正規クライアントがブロックされます。緩すぎると不正利用が通ります。Security Events でレート制限イベントを確認し、バランスを取ります。
-
Cloudflare ダッシュボードで Analytics ページを開きます。
Analytics を開く ↗ -
Events タブを選択します。
-
Action が Block、Service が Rate limiting になるよう絞り込みます。
-
ブロックされたリクエストが正規クライアントからか、不正利用のトラフィックかを確認します。
-
正規クライアントがレート制限されている場合は、該当するレート制限ルールを編集し、リクエストしきい値を上げるか、対象ルールの期間を広げます。
-
不正利用のトラフィックが通っている場合は、ルールのしきい値を下げるか、期間を狭めます。
Cloudflare Notifications は、セキュリティイベント量がしきい値を超えたときに通知し、攻撃の可能性やルールの設定ミスを知らせられます。
-
Cloudflare ダッシュボードで Notifications ページを開きます。
Notifications を開く ↗ -
Add を選択します。
-
WAF で絞り込み、Security Events Alert を選択します。
-
通知の名前と配信方法(メール、webhook、または PagerDuty)を定義します。
-
次に、通知を受け取るドメインを設定します。対象アクション(例: Block または Skip)でイベントを絞り込むこともできます。
-
Create を選択します。
利用できる通知タイプの一覧は 利用可能な通知 を参照してください。
Application Security
- カスタムルール — リクエスト属性に基づくルールを作成し、対象トラフィックに対して特定のセキュリティ機能をブロック、Challenge、またはスキップします
- レート制限ルール — クライアントあたりのリクエスト率しきい値を定義し、適用アクションを選びます
- レート制限のベストプラクティス — クレデンシャルスタッフィング、API 保護、GraphQL 向けの一般的なレート制限パターン
- レート制限ルールの例 — ログインページ、API キー、複雑度ベース制限向けの式付きルール例
- セキュリティ機能の相互運用 — カスタムルール、レート制限ルール、Super Bot Fight Mode、マネージドルールの相互作用
- 漏洩した認証情報の検出 — 既知のデータ侵害に含まれる認証情報を持つリクエストを検出します
- Security Events — 一致したリクエストとルールアクションを確認します
Bots
- Bot Fight Mode — 既知のボットパターンに一致するリクエストへの自動 Challenge(Free プラン)
- Super Bot Fight Mode — 検証済みボットの許可リストを含む細かいボット制御(Pro、Business、Enterprise)
- Bot Management — ボットスコア、検出 ID、カスタムルールテンプレート(Enterprise)
- Bot Management の変数 — ボット検出向けにルール式で使えるフィールド(Enterprise)
SSL/TLS
- SSL/TLS を始める — エッジ証明書、暗号化モード、HTTPS の強制
- Always Use HTTPS — すべての HTTP リクエストを HTTPS へリダイレクトします
- Minimum TLS Version — 古い TLS プロトコルの接続を拒否します
API Shield(Enterprise)
- API Shield の概要 — API セキュリティ向けの検出、スキーマ検証、JWT 検証、シーケンス分析
- API Shield を始める — セッション識別子からスキーマ検証までのオンボーディングフロー
- API Discovery — トラフィック分析からのエンドポイント自動検出
- スキーマ検証 — 受信リクエストを OpenAPI スキーマと照合します
- JWT 検証 — エッジで JSON Web Token を検証します
- Sequence Analytics — API リクエストシーケンスを追跡・分析します
- Volumetric Abuse Detection — セッション単位・エンドポイント単位の適応型レート制限
- Authentication Posture — API の認証設定ミスを特定し、その存在を通知します
- BOLA 脆弱性検出 — Broken Object Level Authorization(BOLA)攻撃のリスクがあるエンドポイントを検出します
- Vulnerability Scanner — 一般的な脆弱性について API エンドポイントをテストします