Logic flaws and ordinary looking abuse by a signed in user can pass a web application firewall because the request resembles normal traffic.
If the firewall does not decrypt the session, it also cannot read the body, so placement alone does not create full visibility.
How it works
A signed in person who misuses a real feature may look entirely legitimate to a pattern filter.
A workflow that skips a price check is a business rule problem, not a signature the firewall was given.
Secure code and authorization tests have to cover what the firewall cannot judge.
The companion page explains where the firewall sits, which is a different question from these blind spots.
Concrete examples
- A customer changes a price field in a real checkout flow and the request looks well formed.
- An authenticated user exports far more records than the job requires.
- A flaw in a background job never appears in the request the firewall inspected.
Protective measures
- Do not treat the firewall as a substitute for authorization checks in the application.
- Test business rules with abuse cases, not only with well formed happy paths.
- Decrypt at the firewall only when policy and privacy rules allow that visibility.
- Review unusually large exports by signed in users even when the request looks normal.
Related articles
Where does a web application firewall sit? explains where the firewall sits, which is separate from these limits on what it can judge.
What is web application security? covers the application controls that must catch logic the firewall cannot see.
What is SQL injection? describes a data layer flaw that parameterized queries must stop inside the application.