Web application firewalls sit in front of thousands of business-critical applications across the UK. They filter malicious requests, block known attack patterns, and provide a reassuring layer between the internet and your web servers. The problem is that many organisations treat a WAF as a substitute for secure code rather than a complement to it.
A WAF operating in its default configuration blocks basic SQL injection and cross-site scripting attempts. It catches automated scanner traffic and script kiddie attacks. Against a skilled attacker who understands how WAFs work, default rules offer significantly less protection than the marketing material suggests.
How Attackers Bypass WAFs
WAF evasion is a well-documented discipline. Encoding payloads in unusual character sets, fragmenting requests across multiple packets, using HTTP parameter pollution, and exploiting differences between how the WAF and the application parse input all provide bypass routes. A determined attacker with access to a copy of your WAF product can test bypass techniques offline before launching them against your production environment.
Business logic vulnerabilities bypass WAFs entirely because they involve legitimate-looking requests. A WAF cannot determine whether a user is authorised to access a particular record, whether a discount code is being reused fraudulently, or whether an API endpoint exposes more data than intended.
William Fieldhouse, Director of Aardwolf Security Ltd, comments: “We bypass WAFs routinely during testing engagements. The typical approach involves identifying the WAF product, then applying known evasion techniques specific to that vendor. Most WAFs in their default configuration add minutes to an attack timeline rather than preventing the attack altogether. Custom rules and virtual patching improve things significantly, but they require ongoing maintenance that many organisations neglect.”
WAFs as Part of a Strategy
A properly configured WAF has genuine value. Virtual patching buys time when a vulnerability is disclosed before a code fix is ready. Custom rules tuned to your application’s specific attack surface block targeted threats. Logging and alerting provide visibility into attack attempts that inform your defensive strategy.
The danger lies in treating a WAF as a silver bullet. It is a compensating control, not a replacement for secure development and thorough web application penetration testing. Test your applications with the WAF enabled and disabled. Both perspectives matter. The WAF-disabled results show your true exposure, whilst WAF-enabled testing validates whether your rules actually block real attack techniques.
The Right Approach
Fix vulnerabilities in code. Use a WAF for defence in depth. Test regularly to verify that both layers work as expected. Request a penetration test quote that includes WAF bypass testing to understand what a motivated attacker could achieve against your deployed defences.
JSON-based attacks pose particular challenges for WAFs. Applications that accept structured JSON payloads process nested objects, arrays, and encoded values that WAF rules struggle to inspect thoroughly. Attackers embed SQL injection and command injection payloads inside deeply nested JSON structures that the WAF parses differently from the application, creating a blind spot at the exact point where security matters most.
Regularly review and update your WAF rules as your application evolves. A rule set tuned for last year’s version of your application may miss new endpoints, changed parameter names, and additional functionality that the original rules were never designed to protect.
A WAF is a valuable tool in a comprehensive security programme. On its own, it provides comfort without corresponding protection.