Similar in some ways to a network firewall, a web application firewall (WAF) is a device (or in some cases a service), purpose-built to protect web applications. Instead of filtering requests at the network level with rules based on IP addresses and network protocols, WAFs understand http requests and responses at the application layer. WAF rules are crafted to identify anomalous http requests, and take action accordingly.

While very powerful and useful, operating WAF cannot be considered an adequate replacement for routine review of your application source code as part of your application deployment process. A 100% secure web application (if such a thing were to exist) would arguably not require WAF protection. However, even if such a web application did exist today, tomorrow new vulnerabilities would be discovered and require mitigation.

Compliance

From a compliance perspective, security controls, such as PCI-DSS requirement 6.6, call for WAF protection in lieu of code reviews. Many organizations have invested in WAF solutions to check the compliance box addressing these requirements. However, while a WAF may be physically in place monitoring traffic, is it really doing anything meaningful? Due to the complexity of tuning rules and policies to minimize negative impact, I am concerned that many organizations may not have adequate policies enabled to block attacks.

Relying too heavily on a WAF has the very real danger of providing a false sense of application security.

While a WAF can block malicious attacks from reaching your application, the ultimate goal of application security is to correct the application itself so it is no longer susceptible to those attack vectors. Depending on the scope, correcting the vulnerability at the code level can take some time. This is where a WAF can play an important role protecting the application in the interim until the code is fixed and deployed into production.

Real-World Attack Intelligence

Proper placement of a WAF can provide valuable insight into “real world” activity and attack attempts against your application. Monitoring this activity and following up to determine how the application handled (or would have handled, if the WAF had not blocked the traffic) can help uncover weaknesses that have not yet been detected by routine testing.

Event Categorization

Sure, web server logs could also show evidence of this activity, but a WAF does a terrific job of pulling the needle out of the hay stack of raw log events, categorizing them into attack categories, such as SQL injections, command injections, scanning activity, etc.

Feeding these categorized and correlated events into your SIEM or log monitoring tool can easily generate meaningful reports and alerts that can be acted on to enhance your overall security posture.

Shared Threat Intelligence

Another valuable function some WAF vendors provide is dynamic black lists of bad actors who have exhibited malicious behavior on other websites. This threat intelligence can be particularly helpful blocking low-bandwidth distributed denial of service (DDoS) attacks.

Is a WAF the silver bullet to web application security? Not on its own.

My advice is to consider a WAF as one of many tools in your toolbox. When leveraged along with routine code reviews and active event monitoring, it can be very effective. However, if your goal is to stand it up, set it, and forget it, I would caution that you will likely not have favorable results.