I've been conducting performance benchmarks for a web analytics dashboard that sits behind Cloudflare WAF. During load testing, I discovered a critical issue: my custom WAF rule designed to block aggressive, malformed query string scans is being completely ignored due to rule ordering.
The setup is a standard managed ruleset (Cloudflare Managed) with a single custom rule appended. The custom rule uses a `block` action with a regex pattern to catch suspicious URI patterns. However, during testing with simulated attack patterns, the requests are being evaluated—and passed—by the managed ruleset before my custom rule ever fires.
Here is the simplified rule configuration:
```json
{
"description": "Block excessive query parameter scans",
"expression": "(http.request.uri.query contains "../") or (http.request.uri.query matches "\/.*[\x00-\x08\x0e-\x1f\x7f]")",
"action": "block"
}
```
My understanding of the execution order was:
1. Custom rules (evaluated in order listed)
2. Managed rulesets (evaluated in their configured order)
But the observed behavior suggests the opposite, or perhaps a more complex interaction. The managed ruleset (with sensitivity set to `medium`) is processing the request and assigning a `skip` action for these particular probes, which then seems to short-circuit evaluation of my subsequent custom rule.
Has anyone else run into this while tuning WAF performance? Specifically:
* Is there a documented, definitive hierarchy of evaluation between managed rules and custom rules?
* If a managed rule decides to `skip`, does that skip all further WAF evaluation for that request?
* What's the recommended pattern for inserting a high-priority, early blocking rule without disabling managed rules entirely?
Your understanding of the order is incorrect. Managed rulesets are evaluated first by default, then custom rules. That's why your rule is never reached.
You need to change the execution order in the WAF configuration. Go to the managed ruleset and set its "Action order" to "Last" or use a custom order, placing it after your custom rules. Otherwise, a managed rule with a score-based action like 'challenge' or 'log' will let the request pass through before your block rule triggers.
—AF
That's a valid workaround, but it's trading one problem for another. If you move the managed ruleset to execute last, you're potentially allowing malicious traffic through your custom rules before Cloudflare's threat intelligence even gets a chance to evaluate it. The core issue is that the rule engine stops processing on the first definitive action like `block` or `challenge` from a *higher-priority* phase.
The real fix is often to adjust the custom rule's sensitivity or logic so it triggers *before* a managed rule would issue a `score-based` action that lets the request pass. Sometimes, you need to use a `log` action on the custom rule first to verify it's even matching the traffic you expect.
SQL is not dead.