I’ve been conducting a long-term evaluation of Cloudflare’s WAF for a client with a complex, legacy-heavy application stack. A persistent and critical metric for any WAF efficacy assessment, particularly when justifying its TCO against an on-premise or alternative cloud solution, is the rate of false positives. These incidents directly impact operational overhead, developer productivity, and can even affect revenue if customer-facing functions are blocked.
While Cloudflare provides excellent real-time logging and analytics, I found the native dashboards insufficient for tracking the *trend* of false positives over extended periods. I needed to correlate spikes with deployment cycles, WAF rule package updates, and specific managed rule states (modes). To that end, I built a simple, external dashboard using a time-series database (InfluxDB) and Grafana. The goal was to move from anecdotal complaints to data-driven conversations with both the security team and Cloudflare support.
The workflow is straightforward:
* A scheduled script polls the Cloudflare Logpush API (specifically using the `http_requests` dataset with WAF-related fields).
* It filters for requests where `FirewallMatchesAction` is `'block'` or `'challenge'`, but where the request ultimately resulted in a `OriginResponseStatus` in the 2xx range (indicating the request, though flagged, was ultimately served by the origin, suggesting a false positive).
* These events are enriched with metadata (WAF rule ID, managed ruleset name, customer zone) and written to InfluxDB.
* Grafana visualizes this data with a focus on trends.
Key panels on the dashboard include:
* **False Positive Rate Over Time:** A line chart showing daily counts, normalized against total request volume where possible.
* **Top Offending Managed Rules:** A breakdown of which Cloudflare managed ruleset (e.g., OWASP, Cloudflare Managed) is responsible for the most false blocks.
* **Rule ID Drill-down:** A table listing specific Rule IDs that trigger most frequently, which is indispensable for creating precise exceptions.
* **Correlation with Change Events:** Manual annotations on the timeline for code deployments or WAF package updates.
The immediate value has been substantial. For instance, we identified that a specific OWASP rule related to SQL injection was consistently blocking a particular legacy API endpoint pattern after every other weekly release. This wasn't obvious from Cloudflare's Analytics UI alone because the absolute numbers were low, but the trend was clear and repetitive. This evidence allowed us to:
1. Justify a temporary rule disablement to the security team with precise impact data.
2. Work with developers to refactor the endpoint, with a clear timeline.
3. Re-enable the rule and confirm the false positives ceased.
This approach turns a reactive, support-ticket-driven process into a proactive governance activity. I'm interested if others in the community track similar metrics, and what methodologies or tooling you employ. Specifically, how do you balance the need for granular historical data with the cost implications of storing and querying extensive log data from Cloudflare? Are there particular WAF features (like the new Sensitivity Scores) you've found useful in automating parts of this analysis?
—LJ
—LJ