Web Application Firewalls & API Security: Why WAFs Always Fall Short

In the modern digital landscape, APIs serve as the cornerstone of web applications and data exchange, connecting services and data stores at a level of complexity that grows year by year. As APIs enable more innovation and development, securing these systems has become more crucial than ever. While Web Application Firewalls, or WAFs, are often touted as a go-to solution for web app security, they frequently fall short – and in many cases, offer little more than an artificial sense of protection that is not backed by actual protection.

But why isn’t a WAF good enough? Where do they fall short, and what is the better alternative? Let’s dive a bit deeper.

Unique API Security Challenges

APIs, or Application Programming Interfaces, form the backbone of the modern internet. Whether an API is serving up-to-date weather information, updating flyers as to the status of their airline service, or even serving this very article in a usable format for your specific device, these systems are vital to the ongoing experience of users across the globe.

As powerful as they are, APIs can also be extremely vulnerable. The entire purpose of an API is to expose itself to external users or systems in a way that can serve information in a variety of potential use cases. This paradigm is a disaster scenario for the security minded, as serving this data securely with proper safeguards and tracking becomes exponentially harder with more access permutations.

Beyond just the data availability, there is also a larger logical issue at hand. Yes, APIs are gateways to data, but they also expose functions and the business logic they underpin. Accordingly, API security is as much about securing data as it is securing the underlying business logic and functional design.

What is a WAF?

With this in mind, let’s look at what a WAF actually is. WAFs, or Web Application Firewalls, are defensive systems that guard a web service by monitoring, filtering, and blocking traffic based on a set of rules. When HTTP traffic attempts to connect to a service, a WAF can use a variety of systems to inspect this traffic and determine whether it is exploiting a variety of known vulnerabilities, or matches any number of other potentially malicious criteria, such as coming from a blocked geography or from known bad actors. When this traffic is marked as malicious, it can be filtered, blocked, and even rerouted, thereby protecting the systems underneath.

WAFs have some advertised benefits that have made their adoption commonplace. They provide a basic layer of defense against very common application vulnerabilities, and it is this basic layer of defense that is often considered as “checking the box,” providing a minimal amount of protection. WAFs also typically provide active patching, with new updates to the signature database and new detection systems seeing rapid deployment. WAFs can also be relatively user friendly, offering novice users a “turnkey” solution that is often positioned as “good enough.”

WAF Drawbacks

The problem is that WAFs are not good enough, and more often than not, organizations who depend on them benefit from little more than a false sense of security.

Signature Based Detection

WAFs offer a very basic level of defense, and in this sense, they do what they’re designed to do. Unfortunately, as with any firewall, WAFs are highly dependent on signature-based detection. Signature-based systems utilize a database of known attacks registered as “signatures.” Each of these signatures is a specific pattern or sequence of patterns that forms part of a malware codebase, behavior, or vector, and once detected, signals a high likelihood that the traffic in question is illegitimate.

This dependence on signature based detection means that any attack that has not been seen before can bypass all but the most well-implemented and highly-secured WAF systems. Zero day attacks, novel combinations of attack vectors, or even false negatives achieved by hiding within trusted systems can make WAFs trivial to circumvent. WAFs also miss the point when it comes to API abuse – most breaches of APIs occur through authorization and authentication abuse and excessive data exposure, not through traffic abuse. In this case, using a WAF to solve an API security problem is like using a bandaid to secure your front door.

This signature-based methodology also does nothing to protect against logical attacks and business logic exploits. Because signatures are designed around commonly seen attacks, specific attacks that abuse the underlying logic – such as attacks to buy up stock of a hot item for resale or an attack meant to escalate costs by repeatedly calling a specific service that is resource heavy – will not be part of any signature database due to their specific and custom nature. 

Complexity of Configuration

Much of this could, in theory, be mitigated, but this process requires ever-growing complexity in the configuration of the WAF. All of this adds up to a system that does little more than protect against some very basic attacks while giving a sense to developers of complete security, creating an environment where harm is not just likely - it’s almost guaranteed.

This configuration and complexity also brings with it consistently increasing resource consumption. To make a WAF really effective for an API, you have to throw a ton of resources at it to enable a variety of heuristics detection, signature updating, tracking and mitigation, etc. As these systems grow in complexity, their resource demands grow in equal measure, resulting in a highly expensive – and potentially ineffective – end security posture.

This long-term management of WAF rules on an ongoing basis can be difficult for an organization. In a survey by the Ponemon Institute of 595 IT professionals, this cost was staggering:

Security is the primary reason to invest in a WAF. Organizations are spending an average of $419,100 on WAF products and/or services and an additional average of $200,500 for staff to manage WAF-related security issues. Organizations typically have 2.5 full-time employees to manage the WAF. On average, the staff spends 45 hours per week responding to alerts and 16 hours per week [...] creating and/or updating rulesets.

In this same survey, a more critical issue was discovered – WAFs often don’t even do what they’re designed to do. While 66% of surveyed respondents considered WAFs to be an important tool for their security posture, 43% noted that the WAF is only used to generate alerts, and not to block any sort of attack. And fair enough, as 86% experienced application-layer attacks in the last 12 months which bypassed WAF protection entirely.

There’s also the reality that APIs are largely secured through effective authentication and authorization systems. API attacks are more often than not logical attacks, ones that manipulate authentication and authorization systems to attack underlying data and logic. This authentication and authorization paradigm is difficult to manage through a WAF, as controlled access is the name of the game for either system and any additional layer confuses rather than improves outcomes.

The Wrong Fit

It should also be mentioned that WAFs are not really meant for APIs as a single solution. WAFs handle traffic – that’s what they were designed to do, and that’s what they’re best at. While APIs communicate through traffic, this does not mean that WAFs are a strong security option through some sort of transitive property – APIs might handle traffic, and WAFs might secure traffic, but that does not mean that WAFs secure APIs effectively. 

A lack of API-specific rule sets and signatures make most WAFs ineffective at detecting all but the most obvious threats, and those threats can largely be mitigated through some basic port filtering, rate limiting, and monitoring. The inability to effectively inspect and validate API payloads makes this even worse, as even a system with good API-specific signatures would likely be ineffective. WAFs focus on the HTTP layer, but the content and the structure of the API request and the response it generates often happens fully abstracted into separate layers in the stack. In essence, WAFs are to APIs what cameras are to truck inspections – on the surface potentially useful, but in practicality supremely limited.

The reality is that many attacks on APIs are not principally traffic-based – API-specific threats, including broken object-level authorization, over-exposure of business logic, etc., can not be effectively mitigated by WAFs, or at the very least, are not managed more effectively by other solutions that do not add complexity to the security posture.

Examples of WAF Failures

None of this is purely theoretical – there have been many instances where WAFs have been abused, misused, and even entirely bypassed.

Some of these attacks are frighteningly trivial. In 2022, security researcher Manash demonstrated that it was possible to bypass Amazon WAF – by all measures a pretty well-implemented and secure WAF system – through some clever use of code. While the WAF did what it was supposed to do during Manash’s initial attacks, filtering a wide range of strings, Manash discovered that using multi-line comment syntax could bypass the ruleset entirely, allowing Manash to trigger an internal alert:

Then I remembered that I can use the multi-line comment syntax in Javascript in between the payload to fool the WAF which usually runs based on a set of rules and regular expressions. The final payload is ';window/*aabb*/['al'%2b'ert'](document./*aabb*/location);//. I split the “alert” string into two parts of “al” and “ert” and then added them. The plus symbol needs to be URL encoded; otherwise it would be interpreted as the space symbol.

A similar type of issue with WAFs can be found in the AWS WAF 8 KB limit. In essence, AWS WAF only inspects the first 8 KB of the web request body, and when a request exceeds this base size, the entire request is forwarded internally to be handled by a web server. This means that any attack of sufficient complexity that is larger than 8 KB can simply bypass the AWS WAF into an internal EC2 instance. While this issue can – in theory – be fixed by simply blocking all traffic with a body larger than 8 KB, this can result in actual functionality being blocked, especially when dealing with rich media or complex multi-step requests.

This issue was expounded upon by Osama Elnaggar on his security blog in a piece titled "AWS WAF’s Dangerous Defaults,” where he states:

Before writing this blog post, I reached out to the AWS Security team to discuss this issue. Unfortunately, their response was disappointing to say the least. They mentioned that this is a known and documented limitation and that it was up to the customer to add this rule. 

Due to how WAFs are often talked about – a simple "set and forget" way to add a secure layer! – the default instance of the WAF is very likely to exist in the wild, with this exact problem active in production and able to be used by any malicious actor.

Another good example of a WAF security failure is the 2019 Capital One Data Breach. In this instance, the WAF that was used by Capital One allowed a user to enumerate and read files that were stored in cloud buckets. 

The specific way this occurred has been challenged by the WAF provider, Modsecurity, but the commonly accepted theory is that the WAF was tricked into relaying requests it would otherwise not relay, either through a malicious abuse of a misconfiguration or through the deployment of a Server-Side Request Forgery attack. Either way, the WAF was a key weakness here.

Using a legacy security solution to protect modern, complex application architectures just doesn’t make sense. WAFs rely on technology from the past to combat threats that are not relevant threats to modern APIs. Perhaps WAFs can still be effective against certain threats but they can't spot modern API attacks. Positioning WAFs as an API security solution is ineffective.

API Security Solutions

WAFs have their place, but they are not appropriate for most API systems as a core security solution. While implementing a WAF is a good first step for most security postures, much more needs to be done. In order to have a fully secure API instance, a dedicated API solution must be deployed that is full-featured and designed for the modern API. These systems can’t just filter traffic – they must provide application layer visibility, provide real-time monitoring and inspection, and more than anything else, do this with simplicity and efficacy.

FireTail is a complete solution for true end-to-end API security, boasting a variety of features that can deliver better security, efficiency, and functionality. FireTail offers:

• API Alerting & Monitoring: Stay Ahead of Threats - FireTail's API Alerting & Monitoring allows you to set specific conditions, metrics, and thresholds to detect and respond to API security events swiftly. Stay in control of your API ecosystem and receive alerts precisely how and when you prefer.
• API Security Posture Management: Gain Full Visibility and Strengthen Security - FireTail's API Security Posture Management offers comprehensive visibility and assessment of your API security in one centralized dashboard. Accelerate the maturity of your API security program and confidently address potential vulnerabilities.
• API Audit Trail: Comprehensive Logging for Enhanced Security Insights - FireTail's API Audit Trail feature has a centralized and comprehensive logging system, so you can create a single, cloud-based API audit trail. Gain insight into API events, detect breaches, and strengthen your incident response capabilities.
• API Inventory - FireTail's API Inventory feature empowers you with comprehensive visibility into your API landscape. Discover, track, and manage your APIs with ease, ensuring a solid foundation for robust security and efficient governance.
• Seamless API Visibility with FireTail's Agentless Integration - FireTail's Agentless Integration offers a seamless approach to your API endpoints. With our innovative solutions, you can discover and log API activity behind AWS's native API gateway, ensuring comprehensive monitoring without the need for additional agents.

By offering a true end-to-end solution that brings together context and control, you can secure your systems and improve your user experience. Click here to learn more!