A WAF is a filter, and filters see traffic, not intent
A web application firewall sits in front of your application and inspects incoming requests, blocking those that match patterns associated with attacks: the shapes of SQL injection, cross site scripting, path traversal, and known exploit signatures. Used well it is worthwhile. It buys time against opportunistic scanning, dampens the noise, and can virtually patch a known vulnerability while a real fix ships. The danger is not the WAF itself, it is what its presence does to how an organisation reasons about risk.
The failure mode is predictable. A WAF gets deployed, a box gets ticked, and the application behind it stops being treated as something that must defend itself. That is the wrong conclusion, because a WAF sees the traffic, not the meaning. It can recognise a request that looks like an attack. It cannot recognise a perfectly ordinary request that is doing something it should not be allowed to do.
The flaws it is structurally blind to
The most damaging web vulnerabilities we find in practice are not malformed payloads. They are legitimate requests that the application handles incorrectly, and to a WAF they are indistinguishable from normal use.
It is worth being precise about where a WAF genuinely earns its place, because the goal is not to disparage it. Against automated, opportunistic attacks, the constant background scanning that hits every public application, a WAF removes a large volume of noise and blocks the low effort attempts outright. When a vulnerability is disclosed in a framework you use, a WAF rule can virtually patch the specific exploit shape within hours, holding the line while you test and ship the real fix through your normal release process. And its logs are a genuine source of monitoring signal, showing you what is being thrown at your application over time. All of that is real value. The mistake is only ever to read that value as coverage of the flaws it cannot see.
- Broken object level authorization: a logged in user changes an identifier in a request and reads another customer's record. Every part of that request is well formed. The flaw is that your code did not check ownership.
- Broken authentication and session handling: a token that does not expire, a password reset that can be replayed, a privilege that is granted client side. The request is valid; the logic is wrong.
- Business logic abuse: applying a discount twice, ordering a negative quantity, skipping a payment step in a multi stage flow. Nothing here is an attack signature, it is your workflow being used against you.
- Sensitive data exposure through a legitimate endpoint that simply returns more than it should to whoever asks.
Why signatures cannot solve a logic problem
A WAF works by knowing what bad tends to look like. Injection and scripting attacks have recognisable structure, which is why signature and anomaly detection can catch a meaningful share of them. Authorization and business logic flaws have no such structure. Whether a request is legitimate depends entirely on context the WAF does not have: who the user is, what they are allowed to touch, and what state the transaction is in. That context lives inside your application, so the decision has to be made there.
This is also why leaning on a WAF against your own bugs tends to fail quietly. Attackers who find a logic flaw are not sending anything the filter would flag. They are using your application exactly as built, just in an order or with values you did not intend. There is nothing to match, so nothing is blocked.
Treat it as one layer, not the plan
The right mental model is defence in depth, where the WAF is the outer skin and the load bearing security lives in the application. Input is validated and output encoded in the code, so injection and scripting are handled at the source rather than hopefully filtered at the edge. Authorization is checked on every request against the specific object being accessed, not assumed from the fact that someone is logged in. Business rules are enforced server side, where the user cannot reach them.
With those in place, the WAF becomes what it is good at: a layer that raises the cost of automated attacks, buys you a window when a new vulnerability is disclosed, and adds monitoring value. Without them, it is a reassuring banner over an application that still gives away whatever a thoughtful attacker asks for politely.
How to find what the WAF hides
Because a WAF makes an application look safer from the outside, the flaws it cannot see are exactly the ones you have to go looking for deliberately. That means testing authorization the way an attacker would, by logging in as one user and trying to reach another's data, and walking business flows to see what happens when steps are skipped or values are pushed out of range. A scanner running through a WAF will report a clean outside and miss all of it.
This is the work a penetration test and a secure code review are built for: reasoning about what the application is supposed to allow and proving where it allows more. A WAF is a good thing to have. It is a bad thing to trust as your security, and the difference between the two is measured by how much of your defence lives in the code behind it.