I am reaching out to this community after a particularly concerning incident during our quarterly penetration test. Despite having Cloudflare's WAF (Managed Ruleset) deployed in front of our application database, several classic SQL injection payloads were not blocked and successfully reached our backend. This has triggered a major data quality and integrity alert within our analytics team, as the test targeted a user-facing form whose data feeds directly into our core fact tables.
Our setup is as follows: We proxy our application through Cloudflare (DNS orange-clouded), with the WAF operating in its default **Security Level: High** and **Managed Ruleset: OWASP Core Ruleset** enabled. The penetration test team employed standard union-based and error-based SQLi techniques. For example, a payload such as:
```sql
' UNION SELECT null,username,password FROM users--
```
Was passed through a `?search=` parameter in a GET request. Our application logs confirmed the request was not blocked by Cloudflare and was processed by our backend (which, thankfully, uses parameterized queries, so no harm was done). However, the very fact that the attempt reached our database layer is a significant failure of the first defensive layer.
I have conducted a preliminary analysis of the WAF analytics events in the dashboard for the time period, and the block rate is curiously low. I need to diagnose the gap. My immediate hypotheses are:
* **Rule Sensitivity:** The default OWASP ruleset sensitivity might be too low for our compliance requirements, or certain rule IDs might be disabled.
* **Request Body Inspection:** Perhaps the WAF is not configured to inspect POST body contents with the appropriate content-type, though some tests were GET requests.
* **Exclusion or Bypass:** There may be an unintentional WAF bypass due to a misconfigured **IP Access Rule** or a **Page Rule** that disables security for a path pattern.
* **Managed Ruleset Override:** A potential conflict where a more specific, lower-priority rule is overriding the core SQLi block rules.
I am seeking a systematic, data-driven approach to troubleshoot this. Specifically:
1. What is the most effective method to audit the full list of **active WAF rules** and their actions (block, challenge, log) for a given zone? The UI seems to only show a subset.
2. Are there specific **OWASP rule IDs** (e.g., 942100-series) that we should explicitly set to "Block" that might be in "Log" or "Score-Based" mode by default?
3. What is the recommended workflow to replay a captured malicious payload (from our logs) against the current WAF configuration to verify its behavior, ideally using the Cloudflare API?
4. How do you structure your logging (whether to Cloudflare's own analytics, SIEM, or a data warehouse) to create a monitor for "WAF Events Allowed" that can trigger alerts in our data quality pipeline?
My next step is to export the last 72 hours of WAF events via the GraphQL API and load them into our Looker instance to correlate blocked vs. allowed events with the penetration test timestamps, but I suspect the configuration itself is the root cause. Any detailed guidance or shared SQL queries for analyzing Cloudflare WAF logs would be immensely valuable.
- dan
Garbage in, garbage out.