Web Application Firewalls Are Not a Substitute for Testing

Web application firewalls have a place in any serious security stack. They block common attacks at scale, absorb opportunistic scanning, and provide useful telemetry about what attackers are trying. They do not replace application security testing, despite occasional sales pitches that suggest otherwise. Treating a WAF as the primary line of defence creates a false sense of security that breaks down the first time a serious attacker takes interest.

What WAFs Actually Do

A web application firewall inspects HTTP traffic against rules that match known attack patterns. Cross-site scripting, SQL injection, common scanner signatures, and various known vulnerability patterns all get filtered effectively. The WAF reduces the noise reaching the application and stops the bulk of automated attacks before they have a chance to succeed. For an application running on the open internet, that filtering is genuinely valuable.

Where WAFs Struggle

WAFs operate at the HTTP layer. They see requests and responses but understand neither the application’s intended logic nor the data it processes. Business logic flaws, broken authorisation, race conditions, chained exploits, and many authentication issues sit beyond what any signature-based system can catch. A WAF will happily forward a request that exploits insecure direct object reference, because nothing about the request looks malicious in isolation. web application penetration testing probes exactly these gaps.

Bypass Techniques Are Mature

Attackers spend significant energy developing WAF bypass techniques. Encoding tricks, parameter pollution, HTTP request smuggling, and protocol-level manipulations all defeat various WAF rules with depressing regularity. The arms race continues, with vendors updating signatures and attackers finding new bypasses. Each round narrows the gap, but the assumption that the WAF catches everything is wrong on the day the WAF was first deployed and gets more wrong over time.

Expert Commentary

Name: William Fieldhouse

Title: Director of Aardwolf Security Ltd

Comments: I have walked clients through demonstrations where a vulnerability blocked by their WAF was reachable through a slightly modified request that the same WAF allowed through. The application beneath was just as vulnerable as before. The WAF had created an illusion of protection that disappeared the moment a tester actually probed it.

Tuning Versus Default Rules

WAFs ship with default rule sets that aim to balance protection against false positives. The defaults catch a lot, but they let plenty through, including application-specific issues that a WAF cannot understand without context. Tuning rules to the specific application improves detection significantly, but most organisations leave the defaults running because tuning takes effort and risks blocking legitimate traffic. The result is a WAF doing roughly half of what it could be doing.

WAFs and Testing Together

The right approach treats WAFs as a layer in defence in depth rather than a substitute for testing. The application itself should be secure even if the WAF is bypassed entirely. Testing should occur with the WAF in audit mode rather than blocking, so that real vulnerabilities get reported rather than being filtered by the WAF rule. The WAF’s job is to slow down opportunistic attacks. The application’s job is to be safe even against a determined attacker who finds a bypass.

Practical Recommendations

Run WAFs on internet-facing applications, but tune them for your specific application and review the rules quarterly. Test the underlying application as if no WAF existed, since serious attackers will find their way around it eventually. Pair both with a process that ingests WAF telemetry into your detection pipeline, since the patterns of blocked attacks reveal interesting information about your threat environment. Request a penetration test quote that explicitly covers the application behind the WAF rather than testing the WAF itself.