Implementing Granular Rate Limiting in Cloudflare for API Protection

Preventing API Abuse with Cloudflare Edge Rate Limiting

The problem is preventing API abuse or service overload without indiscriminately blocking legitimate users behind shared IP addresses. The useful takeaway is that Cloudflare allows granular rate limiting based on request paths, tokens, or specific selectors, not just the originating IP address.

Prerequisites for Configuration

• A domain managed within Cloudflare.
• Access to the Cloudflare dashboard with administrative permissions.
• A clear understanding of the API endpoints requiring protection.

Focused Rate Limiting Procedure

Rate limiting is configured within the Cloudflare Firewall Rules or Rate Limiting dashboard, not via DNS or proxy settings alone.

1. Navigate to the Rate Limiting section in the Cloudflare dashboard.
2. Create a new Rate Limiting Rule.
3. Define the scope using selectors (e.g., (http.request.uri.path eq /api/v1/*) to target a specific path).
4. Set the threshold (e.g., 100 requests) and the time window (e.g., 60 seconds).
5. Select the desired action: block, challenge (JS or CAPTCHA), or managed challenge.

Verification and Testing

To confirm the rule functions as intended, simulate traffic matching the defined selector.

Concrete Example: Path-Specific Throttling

If an API endpoint requires a maximum of 50 requests per minute per token, the rule selector should target the path and the token header (if using token-based limiting): (http.request.uri.path eq /api/protected) and (http.request.headers['X-Api-Token'] exists). The limit should be set to 50 requests over 60 seconds, with the action set to challenge.

Diagnostic Check: Execute a request pattern that exceeds the 50-request limit within the 60-second window. The expected response is an HTTP 429 Too Many Requests, or a Cloudflare challenge page, not a standard API error.

Recovery and Limitations

Limitation: Overly aggressive IP-based limiting will fail for users behind corporate or shared proxies. Always prioritize token or path-based selectors.

Recovery: If legitimate users are blocked, review the rule selector and lower the threshold. Note that if a request is rate-limited, changing the rule action afterward will not immediately revert the block; the state persists until the time-to-live (TTL) of the counter expires.

Practical Check: Verify the rule's effectiveness by checking the metrics within the Cloudflare dashboard for the specific rule, confirming the request count increments toward the threshold without triggering unintended blocks on unrelated traffic.