Thoughts on Web Application Firewalls
I recently attended a talk given by an engineer from a top security product company and, while the talk was quite interesting, something that the engineer said has been bugging me a bit. He basically stated that, as a control, deploying a web application firewall was preferable to actually fixing vulnerable code. Web application firewalls (WAFs) are great in that they provide an additional layer of defense at the application layer. By filtering requests sent to applications, they are able to block certain types of malicious traffic such as cross-site scripting and SQL injection. WAFs rarely produce false positives, meaning that they won’t accidently block legitimate traffic. And WAFs can be tuned fairly precisely to particular applications. Additionally, WAFs can filter outbound traffic to act as a sort of data leak prevention solution. But is installing a WAF preferable to writing secure code? Or, put differently, is having a WAF in place reason enough to disregard secure coding standards and remediation processes? I don’t think so. WAFs, like other security controls, are imperfect and can be bypassed. They require tuning to work properly. They fall victim to the same issues that any other software does: poor design and poor implementation. While a WAF may catch the majority of injection attacks, for example, a skilled attacker can usually craft a request that can bypass application filters (particularly in the common situation that the WAF hasn’t been completely tuned for the application, which can be an extremely time-consuming activity). We have seen this occur quite often in our penetration tests; the WAF filters automated SQL injection attempts executed by our tools but fails to block manually crafted injections. I’m not saying that organizations shouldn’t deploy web application firewalls. However, rather than using a WAF in place of good application secure application development and testing practices, they should consider WAFs as an additional layer in their strategy of defense-in-depth and continue to address application security flaws with code changes and security validation testing.
Explore More Blog Posts
You’ve Got (Graph) Mail – Leveraging Microsoft Graph API Change Notifications for Data Exfiltration
Discover how threat actors leverage Microsoft Graph API Change Notifications and Rich Notifications for stealthy post-exploitation data exfiltration of Outlook emails and Teams messages.
Authorization Differential Testing in Salesforce
NetSPI Salesforce expert Aussan explores how holding identity steady across UI API, GraphQL, and custom @AuraEnabled Apex methods reveals hidden authorization gaps.
PHP2Shell Unauthenticated RCE on PHP: CVE-2026-109618 & CVE-2026-109619
The PHP project has disclosed two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, affecting all PHP installations that serve web requests. Both vulnerabilities carry a CVSS 4.0 score of 9.2 (Critical).