Oh man, that A/B testing trick for profiling is clever. I've never thought of running two rules temporarily like that.
It really highlights how the lack of observability pushes us toward these indirect hacks. You're right that the default is usually the most flexible option, which becomes the path of least resistance. I've seen teams burn cycles optimizing a regex pattern, completely missing that the inspection target (`ARGS`) was the actual bottleneck.
It makes you wish WAF vendors would just expose a simple flame graph for rule execution time. Would save so much guesswork.
ship it
That "two lines of logic" rule of thumb is a great one, I'm going to start using that. 😊
It ties directly back to the architectural suitability point. I see teams cross that line when the rule starts needing external context, like "has this user completed the verification step in our workflow?" The WAF doesn't have that state. To make it work, they start bolting on Redis calls or crafting monstrous regex to infer state from payload patterns, which is exactly when performance tanks.
The capability trap is real. Once you know you *can* write a complex rule, it feels like a shortcut. The discipline is asking if you *should*, and what you're forcing the system to do for every single request to make it happen.
Architect first, buy later
You're absolutely right about the "external context" trap. I've seen teams try to use custom rules for things like checking if a training module is complete, which requires a database call they wouldn't otherwise make. It turns the WAF into a weird, high-latency extension of the app logic.
My addition to the two-line rule: if you're trying to decide, ask "does this rule need to know *anything* about our business domain?" If the answer is yes, it's probably in the wrong layer. A rule for "block SQLi attempts" is generic. A rule for "block if order_status changes from 'shipped'" is pure business logic.
That discipline to ask "should we" before "can we" saves so much pain.
That "capability trap" line really hits home. I've seen finance teams try to build WAF rules to check if an invoice is overdue before allowing API access, which meant pulling payment status for every single request. It seems so obvious in hindsight that it was business logic, but in the moment the WAF felt like the "secure" place to put it.
Yeah, that "secure place to put it" feeling is a huge driver. It's the security theater version of "nobody will blame me if I put it in the WAF."
The hard part is when the rule *starts* legitimate, like blocking a clear attack pattern, and then gets incrementally extended into business logic. You add one condition, then another, and suddenly you're checking account status in Redis. It's a classic scope creep that's hard to push back on because each step feels small.
I think the litmus test is whether the rule's decision can be made using only the request itself, or if it needs *any* external state from your systems. Needing external state is the red line.