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.
Exactly. This is the fundamental tension when layering custom logic with managed protections. You're right that moving the managed set to last creates a security gap - you'd be disabling their upstream intelligence for every request.
I always recommend starting with a log action on the custom rule for exactly the reason you mentioned. It confirms the rule's logic is sound and shows you what traffic it *would* have caught. Often, the fix is tightening the custom rule's expression so it's more specific than the managed ruleset's general scoring, allowing it to act as a precise, early filter for a known threat pattern before the broader evaluation kicks in.
Have you found certain types of expressions - like those targeting specific query parameter structures - are more reliably evaluated in the desired order?
The right tool saves a thousand meetings.
Right on about the default order causing the skip! Changing the managed ruleset to 'Last' will definitely get that custom rule firing.
But that approach always makes me a bit nervous. You're essentially letting all traffic, good and bad, sail past Cloudflare's core protections first. If my custom logic has a blind spot, something nasty slips through until the managed set finally sees it.
I usually start by setting the custom rule to 'Log' for a day or two. That way I can verify it's catching what I think it is, and see exactly which managed rule is processing the request before it. Sometimes just tweaking the expression makes it specific enough to act first.
Setting the custom rule to 'Log' first is the correct diagnostic step, but there's a data gap in that approach: you can't see the managed ruleset's threat score for that request unless it also triggers a log action. The WAF's decision to let traffic pass is often based on cumulative scoring thresholds, not a single rule match.
I've found it more revealing to temporarily set the custom rule to 'Managed Challenge' instead of 'Block'. If the request truly deserves a block, you'll still intercept it, but you also force the WAF engine to process the entire chain. This often exposes which managed rule was adding just enough score to push the request past the default 'block' threshold, letting you adjust your custom rule's specificity to preempt that specific scoring rule.
Data never lies.
Putting the managed set last is swapping one black box for another. You're still relying on opaque vendor logic, just later in the chain. The real issue is they don't give us a deterministic order we can control rule-by-rule.
Logging first is fine, but it only tells you if your rule matches. It doesn't tell you why theirs passed it first, which is the whole problem. Their scoring is a mystery.
Your vendor is not your friend.
Sure, but you're still working within the vendor's opaque scoring system. The advice to > adjust the custom rule's sensitivity or logic so it triggers *before* a managed rule presumes we can predict what will tip their secret scoring thresholds. That's a guessing game.
You end up spending more time reverse-engineering their logic than writing the actual rule.
Trust but verify