I would never call a WAF a security vulnerability by itself. That is, unless there is a known issue with your specific implementation. There are three primary issues with using a WAF en lieu of finding/fixing vulnerabilities:

1. The WAF, by definition is unaware of the context (with regard to the backend application) of a request. Because of this it can only block certain types of attacks (typically injection style attacks). Even then, clever attackers can often evade the protection through various reformating/reencoding techniques that bypass the rules in the WAF. A WAF is never going to be able to detect and stop logic-level vulnerabilities, or at least not without very careful, custom tuning.

2. Even if a WAF is 100% effective at blocking the attacks against your application, it still is acting as a wall between the attacker and your vulnerable application. This means that if the attacker can get passed the wall, the WAF will no longer protect you. Common scenarios where this could occur include:

• The attacker lands a phishing foothold and can tunnel to the app from a "trusted" internal corporate IP address.

• A poorly configured WAF may be circumvented by directly accessing the IP of the webserver or load balancer behind the WAF.

• A server-side forgery attack might allow the malicious request to appear to originate from the same subnet or server as the vulnerable code, thus bypassing the WAF.

3. It is difficult for a WAF to always stich requests together and view them the same way the application does. This is due to the fact that each webserver, loadbalancer, proxy, etc. may chop up and interpret the request slightly differently. This means that new bypasses are always being discovered from transport-encoding, TLS parsing, cache-poisoning, and other attack methods.

The bottom line is that a WAF should always be viewed as a defense-in-depth technique or a quick mitigation while more thorough fixes are implemented. It is always an imperfect solution, unlike patching known vulnerabilities in the underlying software.

I would never call a WAF a security vulnerability by itself. That is, unless there is a known issue with your specific implementation. There are three primary issues with using a WAF en lieu of finding/fixing vulnerabilities:

1. The WAF, by definition, is unaware of the context (with regard to the backend application) of a request. Because of this it can only block certain types of attacks (typically injection style attacks). Even then, clever attackers can often evade the protection through various reformating/reencoding techniques that bypass the rules in the WAF. A WAF is never going to be able to detect and stop logic-level vulnerabilities, or at least not without very careful, custom tuning.

2. Even if a WAF was 100% effective at blocking the attacks against your application, it still is acting only as a wall between the attacker and your vulnerable application. This means that if the attacker can get past the wall, the WAF will no longer protect you. Common scenarios where this could occur include:

   • The attacker lands a phishing foothold and can tunnel to the app from a "trusted" internal corporate IP address.

   • A poorly configured WAF may be circumvented by directly accessing the IP of the webserver or load balancer behind the WAF.

   • A server-side forgery attack might allow the malicious request to appear to originate from the same subnet or server as the vulnerable code, thus bypassing the WAF.

3. It is difficult for a WAF to always stitch requests together and view them the same way the application does. This is due to the fact that each webserver, loadbalancer, proxy, etc. may chop up and interpret the request slightly differently. This means that new bypasses are always being discovered from transport-encoding, TLS parsing, cache-poisoning, and other attack methods.

The bottom line is that a WAF should always be viewed as a defense-in-depth technique or a quick mitigation while more thorough fixes are implemented. It is always an imperfect solution, unlike patching known vulnerabilities in the underlying software.