Just finished a 6-month deployment of Cloudflare's DDoS protection in front of a critical e-commerce platform handling a steady 10 Gbps of legitimate traffic. We had a major scare last year with a volumetric attack that saturated our direct internet link, so moving behind Cloudflare was a no-brainer. The main lesson? **The configuration *after* you point your DNS is where the real security (or risk) lies.**
A lot of teams think enabling "Under Attack Mode" or the default WAF Managed Rules is enough. From our experience, that's like locking the front door but leaving the windows wide open. Here’s where we saw immediate gaps and how we addressed them:
**1. Default Security Levels & Rate Limiting**
The default "Security Level" is essentially "Medium," which challenges only some suspicious requests. For our `/api/` endpoints, we needed to go further. We deployed aggressive rate limiting rules at the edge. A rule like this caught credential stuffing attempts our on-prem WAF never saw:
```json
{
"action": "block",
"ratelimit": {
"characteristics": ["ip.src", "http.request.uri"],
"period": 600,
"requests": 100,
"mitigation_timeout": 3600
},
"expression": "(http.request.uri contains "/api/v1/auth/login")"
}
```
**2. Origin Protection is Non-Negotiable**
If Cloudflare is your shield, your origin IP is your Achilles' heel. We made two critical changes:
* **Scoped Security Groups:** Our AWS origin only accepts traffic from [Cloudflare's IP ranges]( https://www.cloudflare.com/ips/). This is rule #1.
* **Firewall Rule to Block Non-Cloudflare Traffic:** We also added a Cloudflare WAF rule to block all traffic not from Cloudflare IPs. It's a belt-and-suspenders approach.
**3. The "Allow" Rule Pitfall**
Be extremely careful with "Allow" rules in the WAF. Early on, we had an overly permissive rule to allow traffic from a partner's IP range for an integration. This rule, placed *above* the managed protections, essentially whitelisted their traffic from all DDoS and WAF scrutiny. We refactored it to use a more specific challenge or a dedicated, scoped rule set.
The peace of mind during seasonal traffic spikes is incredible. But the biggest win was shifting our security perimeter to the edge. Our origin now sees only clean, filtered traffic, which dramatically reduced our server load and alert fatigue. The key is to remember Cloudflare is a powerful toolset, not a magic wand—you have to tune it for your threat model.
security by default
Good point on rate limiting. We found the default period/request counts were way too high for our login endpoints. We had to drop it to like 50 requests per 300 seconds per IP.
Also, make sure you're logging those blocked requests. The built-in analytics can miss the granularity you need to tune the rule over time.
Benchmarks or bust.
Totally agree on locking down those /api/ endpoints. We had a similar setup and the biggest blind spot was ignoring our own legit traffic patterns. Our checkout flow had these sequential API calls that got rate-limited because they came from the same session.
Had to build a custom rule excluding requests with a valid session cookie. Took some trial and error with the firewall events log to get it right.
Also, watch out for the cache. Aggressive rules can accidentally block cached asset requests if you're not careful.
Trial first, ask later.