Essay · 2 min read
A web application firewall is a speed bump, not a wall
WAFs buy you log lines and minutes. Treating one as your security boundary is how breaches happen.
By Kyeson Blake Utley ·
On almost every web application test I run, there's a moment when the client mentions their web application firewall, usually as a reason a finding "isn't really exploitable." I understand the instinct. A WAF is a product you can point to, with a dashboard full of blocked requests. It feels like a wall.
It isn't. A WAF matches traffic against patterns of known-bad input. An attacker's whole job is to send input that does the same damage without matching those patterns.
Why filters lose
An injection payload can be written in hundreds of equivalent ways: different encodings, comment tricks, case changes, unusual whitespace, or splitting the payload across parameters the application later joins together. The WAF has to recognize every variant. The attacker only needs one it misses.
The firewall also sees requests, not meaning. It can't tell that a perfectly ordinary-looking request changes another customer's order, because broken access control doesn't look malicious on the wire. Some of the most damaging bugs I find are invisible to any filter: insecure direct object references, privilege checks done only in the browser, and business-logic flaws like applying a discount twice.
A WAF's best feature isn't blocking. It's visibility.
What a WAF is good for
None of this means you should switch it off. A WAF is useful for blocking commodity scanners and botnets, slowing down an unsophisticated attacker, giving you virtual patching while a real fix ships, and producing logs that show you someone is probing.
That last point matters most. A WAF's best feature is visibility. If you're reading the alerts, it tells you who is testing your defenses and where.
Fix the application
The real boundary is the code. Parameterized queries end SQL injection regardless of how the payload is encoded. Server-side authorization checks on every object end the "change the ID in the URL" class of bugs. Output encoding in the right context ends most cross-site scripting.
When I write up a finding the WAF happened to block, it still goes in the report as a vulnerability, because one bypass or rule change away, it's live. Budget for the fix, keep the WAF as a seatbelt, and never let it stand in for the brakes.
