Application Security? But I Have a WAF!

It seems so tempting. Solve your application security problem by throwing an appliance at it. After all, if web applications are the most common form of attack, why not just protect them the same way you protect your network and email servers, and be done with it? Why should you spend time hunting down vulnerabilities in your code and figuring out how to fix them?

The “appliance throwing” approach would be viable if WAFs were perfect, but protecting your app layer with only a WAF leaves a lot of holes. WAFs, at their heart, are black-box protection technologies that rely on inspecting incoming traffic for known attack patterns and that’s often not enough. There are circumstances where WAFs will leave you vulnerable to attack, for instance:

Missed attack due to new patterns

A WAF tries to use known attack patterns to protect an application. It can be tuned via writing rules, but attackers are coming up with new patterns all the time. In fact, creating WAF bypasses is something of a cottage industry for security researchers, to the point that you can download a cheat sheet for conducting SQL injection via WAF bypass from the OWSP project .

Missed attack due to application changes

Based on the results of a penetration test or other evaluation of an application, you can make a WAF very accurate by creating rules that focus on specific input fields and types of vulnerability. However, you have to maintain these rules every time the application is changed. The SANS Institute notes, "During the WAF deployment, everyone involved understands exactly which form fields and inputs are vulnerable and to which attack categories, but over time, this knowledge fades. Many organizations lack the in-house expertise to conduct penetration tests every time they change the web application or WAF configuration (and miss the opportunity to ensure a vulnerability was not introduced).”

Missed attack due to configuration complexity

The same SANS report notes that it’s not uncommon for WAFs to be extended to cover more applications than they can handle or to fail under high load, or to have a high number of false positives. For this reason, some organizations configure their WAFs only to alert in the event of a potential attack, rather than try to block it ― which means that a successful attack will likely be missed in the midst of other alerts from the WAF.

There are definitely still benefits to deploying WAFs, including avoidance of denial of service attacks and―when properly configured―providing some protection against an attack. But at best, they slow an attacker down.

No application security silver bullet

Effective application security requires multiple technologies that protect apps in different ways and in different stages of their lifecycle.

If you’re going to use a WAF, you won’t be protecting your products from attack indefinitely. So use the time a WAF gives you wisely; figure out where the underlying vulnerabilities are in your application and fix them. For instance, consider an automated application security solution that integrates into your SDLC, allowing developers to find and remediate security-related defects early in the development process.

But in the end, perfect prevention is not possible: You should also consider supplementing both your efforts to secure code in the SDLC and your WAF with technology designed to specifically protect applications in production, such as runtime application security protection .

Cyberattackers are increasingly focused on the application layer; it’s critical to understand both how this layer is being exploited, and which solutions protect it most effectively. To find out more, start with tips and advice on application security from someone who’s been there check out 5 Lessons From an Application Security Pro .