レート制限のベストプラクティス

以降の節では、よくある用途向けの典型的なレート制限設定を説明します。例のルールを組み合わせて、自分の状況に合わせて調整できます。

レート制限の主な用途は次のとおりです。

• リソースへの 粒度の高いアクセス制御を適用する。User-Agent、IP アドレス、リファラー、ホスト、国、地域などの条件に基づくアクセス制御を含みます。
• クレデンシャルスタッフィングから保護する。アカウント乗っ取り攻撃にも対応します。
• 個々のクライアントが行う 操作回数を制限する。ボットによるスクレイピング、機密データへのアクセス、新規アカウントの一括作成、e コマースプラットフォームでのプログラムによる購入の防止を含みます。
• REST API を保護する。リソース枯渇（標的型 DDoS 攻撃）と、一般的なリソースの不正利用を防ぎます。
• GraphQL API を保護する。サーバー過負荷を防ぎ、操作回数を制限します。

よくある用途は、個々の User-Agent が行うリクエストのレートを制限することです。次の例のルールは、モバイルアプリが 10 分間に最大 100 リクエストまで行えるようにします。デスクトップブラウザ向けのレートを制限するルールを、別に作ることもできます。

訪問者が Managed Challenge に成功すると、Cloudflare は検証済みとして識別するための cf_clearance Cookie を発行します。ただし、悪意のある行為者は、追加の Challenge を回避するために、有効な cf_clearance 値を複数のリクエストや端末で再利用または共有しようとすることがあります。

このレート制限ルールは、定義した期間内に同じ cf_clearance 値で行えるリクエスト数を制限し、こうした不正利用を緩和します。正規の人間ユーザーには影響しません。1 つの cf_clearance 値を使う自動リクエストやリプレイは、しきい値を超えるとブロックされます。

リソースへのアクセスを制御する別の用途は、レート制限ルールから IP アドレスまたは自律システム番号（ASN）を除外または含めることです。

次の例のルールは、同じ IP アドレスから /status への GET リクエストを 1 分間に最大 10 件まで許可します。ただし、訪問者の IP アドレスが partner_ips IP リスト に含まれていない場合に限ります。

アプリケーションによっては、ほかのソース起点のリクエストを受けます（たとえば、第三者ページへリンクする広告）。割り当てを管理する、または間接的な DDoS 攻撃を避けるために、個々のリファラーページが生成するリクエスト数を制限したい場合があります。

この例のルールには Advanced Rate Limiting が必要です。

SaaS アプリケーションや Cloudflare SSL for SaaS をお使いのお客様は、同じゾーンの下に数千のホストがあることがあり、ホストごとに個別ルールを作るのは現実的ではありません。これを避けるには、ホストをカウント特性として使うレート制限ルールを作成します。

次の例のルールは、ホストごとに /login エンドポイントへのリクエストレートを追跡します。

この例のルールには Advanced Rate Limiting が必要です。

レート制限の典型的な用途は、ログインエンドポイントを クレデンシャルスタッフィング ↗ などの攻撃から保護することです。次の例は、リクエストが多すぎるクライアントを管理するために、罰則を段階的に強める 3 つのレート制限ルールです。

ルール #1

ルール #2

ルール #3

これらの例のルールには Business プラン以上が必要です。

ルール #1 は 1 分間に最大 4 リクエストまで許可し、それを超えると Managed Challenge を出します。この設定では、正規のお客様がパスワードを思い出すための数回の試行を許可します。自動アクターが複数回リクエストすると、そのクライアントは未解決の Managed Challenge でブロックされやすくなります。一方、ルール #1 のレート制限に達した人間が Challenge を受けて通過した場合、ルール #2 が次の保護層になります。以降 10 分間で最大 10 リクエストまで許可します。この 2 つ目のしきい値を超えるクライアントには、最も厳しいルール #3 が適用され、1 日間ブロックします。

これらの 3 つのルールは、ルール式（緩和式とも呼びます）とは別のカウント式を持ちます。別のカウント式を設定すると、一致条件はアクションが発動するときにだけ使われます。カウント式には HTTP レスポンスステータスコードと HTTP レスポンスヘッダーに基づく条件を含められるため、レート制限をバックエンドのロジックと統合できます。

レートの計算に使うリクエストと、実際にアクションを適用するリクエストを分けるために、カウント式とルール / 緩和式の 2 つの式を持つこともできます。

1. レートの計算に使うリクエスト。
2. 実際にアクションを適用するリクエスト。

たとえば、ルール #3 は、401 または 403 の HTTP ステータスコードを返した /login への POST リクエストでレートを計算します。ただし、レート制限を超えると、Cloudflare は同じ IP が生成する example.com ホストへのすべてのリクエストをブロックします。カウント式の詳細は、リクエストレートの計算 を参照してください。

ワンタイムパスワード（OTP）と検証エンドポイント（/api/otp/validate や /account/verify など）は、ブルートフォース攻撃の標的になりやすいです。攻撃者は、有効な OTP を推測するために、異なるコードで大量のリクエストを送ります。これらのエンドポイントは特に機微です。

これらのエンドポイントにレート制限を設定するときは、次の指針に従います。

• 正確な URI パスに一致させる: ルール式は、攻撃トラフィックを受けるパスと一致する必要があります。ルールを作成する前に、分析でパスを確認します。/validate/otp を対象にするルールは、/api/otp/validate へのリクエストに一致しません。
• レスポンスベースのカウントを使う: 有効なコードを送る正規ユーザーをレート制限しないよう、エラーレスポンス（401 や 403 など）を返すリクエストだけをカウントします。
• 地理的制限の範囲を適切にする: 国で制限する場合、分析で観測したすべての発生国からの攻撃トラフィックを対象にしているか確認します。1 か国だけに限定しないでください。

次の例のルールは、失敗した試行だけをカウントして、OTP 検証エンドポイントを保護します。

上記の例のルールには Business プラン以上が必要です。

OTP エンドポイントが有効・無効のどちらのコードでも 200 を返す（結果はレスポンス本文にある）場合は、代わりにリクエストベースのカウントと、より低いしきい値を使います。

レート制限を使って、クライアントが行う操作回数を制限できます。この保護を提供する正確なルールは、アプリケーションによって異なります。次の例は、クエリ文字列パラメーターまたは JSON 本文を使う コンテンツスクレイピング ↗ を対象にします。

この例では、クライアントは、異なるクエリ文字列パラメーターを使って、EC サイトで操作（価格照会やカゴ追加など）を行います。たとえば、クライアントが送る典型的なリクエストは次のようになります。

GET https://store.com/merchant?action=lookup_price&product_id=215
Cookie: session_id=12345

セキュリティチームは、Cloudflare Bot Management をすり抜けたボットが店舗のカタログ全体をスクレイピングするのを防ぐために、クライアントが価格照会できる回数に上限を設けたい場合があります。

ルール #1

ルール #2

これらの 2 つのレート制限ルールは、選択した操作（この例では価格照会）を行うリクエストに一致し、カウント特性として IP を使います。前述の /login の例 と同様に、2 つのルールは、執拗だが正規の訪問者による誤検知を減らすのに役立ちます。

クエリ文字列パラメーター経由で特定の product_id の照会を制限するには、そのクエリパラメーターをカウント特性として追加します。レートはクライアントに関係なく、すべてのリクエストに基づいて計算されます。次の例のルールは、各 product_id の照会回数を 10 秒間に 50 リクエストまでに制限します。

この例のルールには Advanced Rate Limiting が必要です。

予約や予約申込を扱うアプリケーションを保護する場合も、同じパターンのレート制限ルールに従えます。

操作とそのパラメーターを、JSON 形式のリクエスト本文で扱うアプリケーションを考えます。たとえば、lookup_price 操作は次のようになります。

POST https://api.store.com/merchant
Cookie: session_id=12345

Body:
{
  "action": "lookup_price",
  "product_id": 215
}

このシナリオでは、個々のセッションからの操作回数を制限するルールを書けます。

この例のルールには Advanced Rate Limiting とペイロード検査が必要です。

リクエスト元のクライアントに関係なく、各 product_id の照会回数を制限するには、次のようなルールをデプロイできます。

この例のルールには Advanced Rate Limiting とペイロード検査が必要です。

ボットからのトラフィックを識別する一般的な方法は、オリジンサーバーから大量の 403 または 404 レスポンスステータスコードを引き起こすリクエストをレート制限することです。これは通常、スクレイピングアプリケーションによる自動活動を示します。

この状況では、次のようなルールを設定できます。

この例のルールには Business プラン以上が必要です。

自動化された送信元が行う操作のレートを制御するには、レート制限ルールを Bot Management とあわせて検討します。Bot Management では、一致条件の一部として ボットスコア を使い、自動または自動の可能性が高いトラフィックにだけルールを適用できます。たとえば、自動の可能性が高いトラフィックには最大スコア（しきい値）30、自動トラフィックには 10 を使えます。

アプリケーションが Cookie でセッションを追跡する場合、その Cookie でレート制限のコンテキストを設定できます（つまり、カウント特性として使います）。レート制限の特性を Cookie にすると、ルールは異なる IP アドレスからのリクエストでも、同じセッションに属するものをまとめます。分散攻撃を行うボットネットワークを扱うときに、よくあるシナリオです。

ルール #1

ルール #2

これらの例のルールには Advanced Rate Limiting と Bot Management が必要です。

アプリケーションがセッション Cookie を使わない場合は、JA3 フィンガープリント で個々のクライアントを識別できます。JA3 フィンガープリントは、Bot Management をお使いのお客様が利用できる一意の識別子で、Cloudflare が同じクライアントからのリクエストを識別できます。自動かどうかに関係なく、すべてのクライアントにフィンガープリントがあります。

この例のルールには Advanced Rate Limiting と Bot Management が必要です。

API は、計算や応答にコストがかかるため、アプリケーションのバックエンドに大きな負荷をかけられます。これらのリクエストは、データ処理や大きなデータ検索など複雑な操作を必要とすることがあり、悪用されると最終的にオリジンサーバーを停止させることがあります。

Advanced Rate Limiting は、DDoS 攻撃、マスアサインメント、データ持ち出しなど、多くの種類のボリューム攻撃を緩和できます。

よくある懸念は、POST 操作の制限です。認証済みトラフィックでは、API Discovery でエンドポイントあたりの適切なリクエストレートを特定し、次のようなレート制限ルールを作成できます。

この例のルールには Advanced Rate Limiting が必要です。API Discovery には追加ライセンスが必要です。

カウント特性は、任意のヘッダー、キー、トークン、Cookie、クエリパラメーター、または JSON 本文フィールドにできます。一部の API は、JSON 本文にセッション ID またはユーザー ID を含むためです。追加情報は次の節を参照してください。

• 一意の識別子が URI パスにある場合は、リソースを保護する を参照してください。
• 一意の識別子が JSON 本文にある場合は、コンテンツスクレイピングを防ぐ（本文） を参照してください。

GET リクエストも、アプリケーションに過剰な負荷をかけたり、帯域幅などのコストの高いリソースに影響したりします。たとえば、多数のファイル（画像など）を保存するアプリケーションで、クライアントが固有の URL にアクセスしてファイルをダウンロードする場合を考えます。

GET https://api.store.com/files/<FILE_ID>
Header: x-api-key=9375

不正利用を避けるためにダウンロード回数を制限したい一方で、データ量を考えるとファイルごとに個別ルールを書きたくないでしょう。この場合、次のようなルールを書けます。

この例のルールには Advanced Rate Limiting が必要です。

このルールは、https://api.store.com/files/* 配下の各ファイルについて、10 分間に 10 ダウンロードまでの制限を定義します。ルール特性として Path を使うことで、<FILE_ID> が異なる新しいファイルがアップロードされるたびに新しいルールを書かずに済みます。このルールでは、送信元 IP やセッション識別子に関係なく、すべてのリクエストでレートを計算します。

Path と x-api-key ヘッダー（キーやトークンがない場合は IP）を組み合わせて、x-api-key で識別する特定のクライアントが、特定のファイルをダウンロードできる最大回数を設定することもできます。

この例のルールには Advanced Rate Limiting が必要です。

GraphQL API のサーバー過負荷を防ぐ方法は、RESTful API の過負荷を防ぐ方法と異なることがあります。GraphQL 上のアプリケーションがもたらす最大の課題の 1 つは、単一のパスがサーバーへのすべてのクエリを扱い、リクエストは通常 POST 操作であることです。このため、HTTP メソッドと URI パスに基づいて、API の用途ごとに異なるレート制限を付けにくくなります。

ただし、RESTful API のようにメソッドとパスを使う代わりに、リクエストの目的は通常本文に埋め込まれます。本文には、クライアントが取得またはミューテーションしたいデータ（サーバー側のデータ変更を指す GraphQL の用語 ↗）と、操作に必要な追加データがあります。

サーバー過負荷を防ぐには、次のアプローチを検討します。

1. 特定のユーザーが、同じ GraphQL 操作名を呼べる回数を制限する。
2. 特定のユーザーが要求できるクエリ複雑度の合計を制限する。
3. 個々のリクエストのクエリ複雑度を制限する。

次の例は、映画のレビューを受け付けるアプリケーションに基づきます。GraphQL リクエストは次のようになります。

POST https://moviereviews.example.com/graphql
Cookie: session_id=12345

Body:
{
  "data": {
    "createReview": {
      "stars": 5,
      "commentary": "This is a great movie!"
    }
  }
}

操作のレートを制限するには、次のルールを使えます。

この例のルールには Advanced Rate Limiting とペイロード検査が必要です。

GraphQL リクエストの処理に必要な複雑度は、大きく異なることがあります。API は単一のエンドポイントを使うため、各リクエストの複雑度を、処理する前に把握しにくいです。

リソース枯渇からオリジンサーバーを保護するには、リクエスト数を制限するのではなく、一定期間に特定のクライアントを扱うために必要な複雑度の量を制限する必要があります。Cloudflare Rate Limiting では、時間経過で複雑度を追跡 し、複雑度の予算または上限に達したあとのリクエストをブロックするルールを作成できます。

この種類のレート制限では、サーバーが処理した各リクエストに、そのリクエストの複雑度に応じたスコアを付ける必要があります。加えて、サーバーはこのスコアを HTTP ヘッダーとしてレスポンスに追加する必要があります。その後、レート制限の仕組みがこの情報を使い、そのクライアントの予算を更新します。

たとえば、次のルールは、1 時間あたりの複雑度予算の合計を 1,000 と定義します。

この例のルールには Advanced Rate Limiting とペイロード検査が必要です。

オリジンサーバーがリクエストを処理すると、処理に要した作業量を表す値（例: 100）を持つ score HTTP ヘッダーをレスポンスに追加します。次の 1 時間、同じクライアントは追加予算 900 までリクエストを行えます。この予算を超えると、タイムアウトが切れるまで以降のリクエストはブロックされます。

API Shield のお客様は、GraphQL malicious query protection を使って GraphQL API を保護できます。GraphQL malicious query protection は、オリジンを過負荷にしてサービス拒否を起こしうるクエリを、GraphQL トラフィックからスキャンします。受信 GraphQL クエリのクエリ深度とサイズを制限するルールを作り、疑わしいほど大きい、または複雑なクエリをブロックできます。

GraphQL malicious query protection の詳細は、API Shield のドキュメント ↗ を参照してください。