Most guides assume you're protecting a website. API-only setups are different. You can't rely on Cloudflare's default rulesets.
Key issues I've seen:
* Misconfigured rules blocking legitimate API traffic because the threat score is based on web behavior patterns.
* Noisy logging from bots that don't matter to your API, drowning out real attack signals.
* False sense of security because the WAF is active but not tuned for your actual endpoints.
To start correctly:
1. Create a subdomain (api.yourdomain.com) and proxy it through Cloudflare.
2. Immediately set the Security Level to "Essentially Off" for that subdomain. The default "Medium" will block API clients.
3. Build your own rules. Start with these two in the WAF:
* A rule to block requests NOT to your known API paths (e.g., `(not starts_with $request_uri "/v1/")`).
* A rule to challenge/block on high threat scores, but only after you've observed baseline traffic for a week.
What metrics are you actually tracking to validate it's working? API response times? 4xx error rates from legitimate clients? Don't just look at blocked requests.
If it's not a retention curve, I don't care.
Yeah, that "Essentially Off" tip for the security level is critical. I burned a morning debugging that when our mobile app started throwing errors for no reason after we flipped the proxy on. 😅
Your point about validating with metrics beyond blocked requests is spot on. For our API, tracking 4xx error rates from known client IDs was the real signal. It showed us a rule was too strict on payload size before it caused a support ticket.
What did you end up using for your high threat score threshold after that baseline week? We settled on >20, but it felt arbitrary.
Great point about tuning the threat score after a baseline. We set ours to >25 based on the 95th percentile from a clean week. But the real trick is to scope that rule to only your API endpoints from the start, otherwise you'll still get noise.
I'd add a third starter rule: block all requests missing your required API headers (like `X-API-Key` or `Authorization`). It cuts down on so much script kiddie traffic immediately. Use the "and" condition with your threat score rule later.
For metrics, watch your origin's 5xx error rates and latency. If the WAF is working, those should drop or stay flat even as attacks increase. Blocked requests tell you nothing about what got through.
Setting the security level to "Essentially Off" is the first thing anyone should do, good call. That default medium setting is a great way to get paged at 2am by your automated client jobs.
On your starter rules, I'd skip that path block unless your API gateway at the origin is a total mess. It's more maintenance, and a misconfigured load balancer path rewrite can make it useless or overly restrictive. Better to use the threat score rule from day one, but scope it to your known user-agent strings for legit API clients first. You'll see real attacks quickly that way.
For metrics, blocked requests are vanity, origin CPU is sanity. If your WAF is working, your origin's compute cost should drop even if traffic volume stays the same.
Every cloud has a dark cost.
Great starter list. That second point about false confidence is huge - we had a rule set to "Managed Challenge" on threat score, thinking it was safe. Turns out our automated clients can't handle a challenge page, so they'd just retry and push our error budgets. Switched it to block for anything over the threshold after seeing that.
For metrics, we found tracking "Requests with Threat Score > 10" as a separate graph was more useful than total blocked. It shows the noise floor of what the WAF is even looking at. If that line spikes, you know to check new rules or bot traffic, even if blocks stay low.