Using Cloudflare Rate Limiting to Protect an API Endpoint from Abuse

The problem: sudden traffic spikes hitting your origin

When a public API endpoint is exposed, a burst of requests—whether from a misbehaving client, a retry storm, or a simple scrape—can quickly overwhelm your origin servers, increasing latency and cost. Because the traffic reaches your infrastructure before you can act, you end up paying for bandwidth and compute that may be wasted.

Thesis: enforce limits at the Cloudflare edge so abusive traffic is stopped before it reaches your origin

Cloudflare Rate Limiting evaluates each request as it arrives at the network edge. By defining a request threshold per IP (or other scope) and choosing an action such as Block or Challenge, you drop or challenge unwanted traffic early, saving origin resources and providing immediate feedback to clients via the cf-rate-limit header.

How Rate Limiting works at the edge

• Requests first pass through Cloudflare’s global network.
• If a matching Rate Limiting rule exists, Cloudflare increments a counter for the defined scope (e.g., IP address + URL pattern).
• When the counter exceeds the threshold within the time window, the specified action is applied.
• Cached responses still count toward the limit unless you enable the “Skip caching” option, which can affect cost calculations.
• On action, Cloudflare adds the header cf-rate-limit: remaining=X; reset=Y so clients can adapt.
• All rule hits are visible in the Security → Rate Limiting analytics dashboard.

Worked example: protecting a test API path

Suppose you have an API at https://example.com/api/users and you want to allow no more than 10 requests per minute per IP, challenging excess traffic with a JavaScript challenge.

1. Create the rule via the Cloudflare dashboard

1. Log in to the Cloudflare dashboard with an account that has Zone → Rate Limiting: Edit permission.
2. Navigate to Security → Rate Limiting and click Create a Rate Limiting rule.
3. Set the following fields:
   • If incoming request matches: http.host equals example.com AND uri path starts with /api/users
   • Threshold: 10 requests
   • Time window: 60 seconds
   • Action: Challenge (JavaScript)
   • Scope: IP address (default)
4. Save and deploy.

2. Verify the rule with curl

Run the following commands from a terminal where you have network access to the host. No special privileges are needed beyond normal user access.

# Replace with your actual domain
DOMAIN=example.com
PATH=/api/users
URL="https://${DOMAIN}${PATH}"

# Send 12 rapid requests; expect the first 10 to succeed (2xx) and the next 2 to be challenged (403 or 429)
for i in {1..12}; do
  echo "Request $i:"
  curl -i -s "$URL" | head -n 1
  # Show the rate‑limit header if present
  curl -s -D - "$URL" -o /dev/null | grep -i cf-rate-limit
  echo "---"
done

Check the output:

• The first 10 lines should show HTTP/2 200 (or another success code).
• Lines 11‑12 should show HTTP/2 403 (or 429) with a body indicating a JavaScript challenge.
• The cf-rate-limit header will display decreasing remaining values and a reset timestamp.

3. Confirm via analytics

In the dashboard, go to Security → Rate Limiting, find the rule you just created, and verify that the “Hit count” matches the number of requests you sent (12 in the example). This confirms the rule is evaluating traffic as expected.

Trade‑off and limitation

Rate Limiting counts requests after Cloudflare caching. If your endpoint serves heavily cached static assets, each cached hit still increments the counter, which may lead to prematurely triggering limits on legitimate traffic. To avoid this, you can enable the Skip caching option on the rule, but that forces those requests to go to the origin, increasing cost. A practical approach is to start with a higher threshold (e.g., 100 requests/minute) for cached paths, monitor the analytics for a few days, then tighten the limit once you understand normal burst patterns.

Actionable closing

Implementing an edge‑based rate limit is a low‑effort way to shield your origin from abusive traffic while giving clients clear feedback. Start by defining a narrow scope (single API path or IP range), choose a modest action like Challenge, and validate with a quick curl test. Use the analytics dashboard to confirm hit counts, then adjust thresholds based on observed traffic patterns. Remember to weigh the caching interaction: if your traffic is mostly cached, consider skipping caching or raising the limit to avoid false positives.