Help, I'm Being Attacked: Why WAFs & Gateways Won't Stop the Next API Attack

When we speak with organizations starting their API security journey, we often hear a “I have a WAF, why do I need dedicated API security?” or “I have an API Gateway, why do I need dedicated API security?”, and these solutions can offer a lot, particularly for organizations that do not have the budget for a dedicated solution. Usually already installed and available from other projects. However these do not offer a comprehensive API security solution, it is important to understand the limitations of these tools and where they introduce gaps into your security. These tools can be a useful first step for teams struggling to manage API security, however as teams become more mature the difficulties begin, particularly for APIs.

The Seduction of Simplicity

It's tempting to rely on WAFs and API gateways for security, given their user-friendly interfaces and the promise of a quick fix. It’s worth remembering that these tools are incredibly useful for their intended purposes and worth investigating if they are already available. In fact many WAFs and API Gateways interface with API security solutions and can offer the benefits of both.

WAFs are primarily designed to filter incoming traffic, scanning for known malicious patterns before they reach your server. They can then do some blocking based on this, disallowing traffic that looks malicious, and blocking the IP address that sent this traffic. However, it’s important to remember that these are Web Application Firewalls, they are designed for web applications with a traditional user interface and input, rather than APIs. When these are retrofitted for APIs often they focus on attacks that are less common in APIs but have clear signatures like cross-site-scripting, although APIs are used in more complex attacks APIs do not render Javascript and storing an XSS payload is not typically considered insecure.

Similarly, API gateways act as intermediaries that govern API traffic, offering a degree of security management. These provide a single workspace to help manage APIs, developers can easily publish, manage, and view the traffic on APIs, see API documentation, and see security controls. The security tools of API gateways are limited to check boxes for authentication, and allows developers to easily turn on authentication for an endpoint. Again, the visibility is very limited and if an API is not already in the API management console it cannot be seen by the API Gateway, this is okay for new API projects, but legacy APIs may still be publicly available without your knowledge.

These solutions provide only a superficial layer of security. They are simply not designed to be full API security solutions, the essence of API vulnerabilities lies not just in malicious inputs but in how they are managed but within broader application contexts. Understanding what an API does, how it works, what other APIs it interfaces with as well as the wider business contexts are just not something WAFs and gateways are inherently designed to detect.

Understanding Tools and Their Limits

Security is a giant chess game, full of trade-offs. WAFs focus on input control but struggle with subtle attacks that mirror legitimate traffic. They excel in blocking identifiable malicious inputs like SQL injections but falter when faced with complex attack vectors, such as those devoid of distinguishable patterns. API gateways, though excellent for governance, provide a nominal check against unauthorized access but fall short when more intricate authorization issues arise.

Malicious actors often exploit business logic vulnerabilities or abuse API functionality, activities that these tools are under equipped to tackle.

‍

1. API attacks don't generally involve straightforward offensive maneuvers. Instead, they often exploit complex permission hierarchies and target sensitive business flows. The challenge lies in conditional access rights—something beyond the scope of most WAFs and gateways. Meaning these have limited coverage when it comes to some of the API specific vulnerabilities from the OWASP API top 10.

2. Many API attacks are not conducted on well known, well documented APIs, instead threat actors will hunt down rogue APIs. These shadow APIs might be a remnant of a project that was abandoned or never fully launched, a piece of software that’s no longer in use, or a developer creating an endpoint that ultimately is never used. WAFs and Gateways are typically only helpful when you know what APIs are out there and you are sure.

3. Limited data and exploration options, in the AI age data has never been more valuable, and teams that are looking to explore an attack in a SOC retrospective or actively threat hunt the lack of explorable data in these solutions can be a major disadvantage. While API Gateways do offer some data, this is primarily for traffic management and API usage, not security events. For WAFs why they may offer information on blocked requests they do not typically

4. APIs are never alone,  and with complex systems with many APIs interacting with one another, managing third-party risk or just understanding the root cause of an issue can be challenging. WAFs are designed for the edge, and don’t typically offer visibility into east-west traffic, while API Gateways usually consider each API to be independent and public. It can be difficult to truly understand third-party risk, particularly for compliance.

The intricacy involved in API security also hinges on unrestricted resource consumption and managing hidden vulnerabilities introduced when APIs interact unpredictably with one another.

‍

The Easy Route?

Many organizations embrace WAFs and API gateways because they come pre-integrated into existing systems or feel like budget-friendly options. Yet, these perceived benefits can mask their ineffectiveness when it comes to comprehensive security. While convenient, these tools often fail to address the root causes of vulnerabilities. However, for teams that do not have the budget for specialist tools, or where these tools are already available, they can be a useful first step in getting some control over API security. 

Often this isn’t the easy route but instead a challenge as organizations get as much as they can from their existing tools first, a difficult prospect for security teams. If you are not ready to invest in a full API security solution and are limited to utilizing existing tools we recommend an approach of visibility and blocking.

Get as much visibility as you can, but know you have not found everything. Work with development teams to document every API and endpoint, to better understand the API attack surface as much as possible, encourage the use of API Gateways, and provide that singular interface. You will not find every API or API endpoint though, so make sure you have a plan in place for unknown APIs and regularly check log activity for rogue APIs. While an API security solution can do this automatically, it is possible to do this manually with API word lists and fuzzing tools.

Block first, giving yourself time to investigate, while WAFs won’t find every attack but when they can configure them to block first, and then spend that time investigating logs. One of the major advantages of an API security solution is the data it offers, while it may take longer manually reviewing logs is an option. Look at a blocked user's previous requests, what were they trying to accomplish? What did they do prior to the WAF blocking them? Were they trying different permutations of payloads? These can be a useful first step to understanding if there is an underlying vulnerability or if it was the result of fuzzing.

Ensure you have a vulnerability reporting, tracking and deployment process in place. API security solutions integrate with ticketing systems such as Jira to generate issues from automated scanning, enabling developers to see security vulnerabilities in the same place as their existing feature tickets. These processes ensure that vulnerabilities can be reported, fixed and tested, without additional workload on security teams or developers, even if it is populated manually via log review.

Investing in API Security

The journey to robust API security begins with visibility and context. Identifying existing APIs, assessing their intended vs. actual usage, and discerning unauthorized activities. Beyond surface-level protections, an in-depth understanding of your APIs becomes key. Meanwhile, API governance requires more than rate limiting and access controls, understanding what regulations you must be compliant with and where sensitive data is being used.

While WAFs and gateways play roles within a broader strategy, they shouldn’t constitute the entirety of your API defense. They are nuanced and understanding these nuances helps organizations prioritize what matters in securing APIs and with a security team that can anticipate rather than just react to threats.