After twelve months of operating Cloudflare's WAF and DDoS mitigation stack for a portfolio of approximately 35 customer-facing applications, I feel compelled to share a detailed, operational review. Our team sits squarely in the mid-market segment: we have dedicated platform engineers, but we are not a hyperscale operation. Our primary drivers were consolidating point solutions, improving security posture, and gaining predictability in our edge spend. This analysis is grounded in logs, billing data, and incident retrospectives.
**The Core Configuration & Philosophy**
We adopted a "defense-in-depth" approach using Cloudflare as our unified edge. The core setup for each application zone typically involves:
* **Managed Rulesets:** Deploying OWASP Core, Cloudflare Managed, and specific CMS (WordPress, Drupal) rulesets in a *blocking* mode after an initial learning period.
* **Custom Rules:** Heavily leveraging custom firewall rules for logic that cannot be expressed via WAF. This includes geo-blocking, rate limiting specific API endpoints, and blocking anomalous user-agent patterns.
* **Rate Limiting:** Configured on a per-API-key-path basis, which proved more effective than broad-brush application-level limits.
* **Transform Rules:** Used extensively to sanitize headers (strip `X-Forwarded-For`), set security headers, and normalize paths before they hit the WAF engine.
A representative custom rule for API protection might look like this:
```
(http.request.uri.path matches "^/api/v1/transactions" and not http.request.headers["x-api-key"] in {"${valid_key_1}" "${valid_key_2}"})
```
This structure gives immense granularity but demands careful management.
**What Worked Exceptionally Well**
* **DDoS Mitigation (L3/4):** Truly set-and-forget. We weathered several volumetric attacks that never registered on our origin servers. The value of the unmetered mitigation cannot be overstated for cost predictability.
* **Performance & Caching:** The integration of WAF with Argo Smart Routing and Tiered Cache significantly improved global response times for dynamic content, a benefit we hadn't fully anticipated.
* **Logpush & Analytics:** The ability to push firewall events and WAF logs directly to our SIEM (Splunk) was transformative for correlation and forensics. The `Action`, `RuleId`, and `Sample` fields in the logs are precise.
* **Custom Rules Engine:** The flexibility is unparalleled. Creating rules to block traffic from specific ASNs or data centers that were sources of persistent bad traffic was straightforward and immediately effective.
**Operational Friction Points**
* **WAF False Positives:** The managed rulesets, particularly OWASP, required significant tuning. We had to disable rules like `932100` (SQL Injection Detection) broadly due to false positives with legitimate encoded payloads in our search APIs. This necessitates a continuous review process.
* **Configuration Drift:** Managing distinct WAF configurations across 35 zones led to drift. We mitigated this by adopting Terraform for all WAF and firewall rule management, which I highly recommend. The Cloudflare Terraform provider is robust, though state management for hundreds of rules requires discipline.
* **Cost Surprises:** While DDoS is unmetered, advanced features come at a cost. Extensive use of Transform Rules, advanced rate limiting, and the volume of Logpush data can inflate the bill. Our monthly spend increased by ~22% over the base Pro plan once all features were enabled.
* **Learning Curve for Custom Rules:** The CF-WAF language is powerful but has nuances. Distinguishing between fields like `cf.threat_score` and `ip.reputation` and understanding when they are populated requires deep diving into documentation.
**Recommendations for Mid-Market Teams**
1. **Instrument First, Then Block:** Run in *Challenge* or *Log* mode for at least two full business cycles before moving to *Block*. Analyze logs to build your custom rule allow-list.
2. **Infrastructure as Code is Non-Negotiable:** Manually clicking in the dashboard is unsustainable. Terraform provides audit trails, versioning, and environment promotion (dev -> staging -> prod).
3. **Centralize Logging:** Do not rely solely on the Cloudflare Analytics dashboard. Export logs to your own system. The raw data reveals patterns the UI summaries obscure.
4. **Calculate the Total Cost of Ownership:** Factor in the engineering time for tuning and the cost of add-on features. The base subscription is often just the starting point.
In conclusion, the platform delivered on its core promises of DDoS protection and a unified edge. However, realizing its full value required a substantial investment in operational maturity—primarily in automation, logging, and continuous tuning. For teams willing to make that investment, it consolidates capabilities effectively. For those seeking a purely managed "fire-and-forget" WAF, the operational overhead may be higher than expected.
CPU cycles matter
That initial learning period before you flip managed rulesets to blocking is such a critical detail everyone glosses over. We almost got burned hard by a false positive on a payment callback path from a major partner, because their internal middleware uses some janky, non-standard JSON serialization that the OWASP rules flagged as SQLi. Had to build a custom rule with a bypass just for that one partner's IP range.
Your point about custom firewall rules handling logic the WAF can't express is dead on. We've ended up using them as a kind of coarse-grained, pre-WAF traffic filter to cut down on the noise. Stuff like knocking down entire ASNs known for pure junk traffic before it even hits a managed ruleset. It saves on... whatever Cloudflare's internal compute unit is that they bill for.
Have you run into any issues with the order of evaluation between your custom rules and the managed rulesets? We had a scenario where a rate limit rule was firing *after* a WAF block, which made our logging a mess until we figured out the precedence.
APIs are not magic.