The Critical API Security Gaps in WAAPs
Confused about the difference between a web application firewall (WAF) and a web application and API protection platform (WAAP)? Curious how intelligent a next-gen “intelligent WAF” really is? Wondering whether you need dedicated API security if you have a WAAP? Can you really trust a WAAP to secure your critical data and services?
In a session from the Salt Security API Security Summit, Mike Rothman, Techstrong Research, stated:
“With WAAPs, you’re basically throwing some API stuff on your WAF. For some requirements, it might be sufficient, but for a lot of requirements, it’s not. I want to ensure that I have visibility over everything happening – across all different layers of my application stack. I don’t think that these existing solutions – that are, in effect, being manipulated to try to meet a new need – are doing that.”
So what is – and what isn’t – a WAAP?
The term “WAAP” first originated as a way to reference a next-gen WAF designed to look beyond signature-based attacks and offer additional capabilities for API protection. In essence, a WAAP is merely a more advanced WAF. Some research firms have even listed WAF as a subset capability of a WAAP. WAF vendors, eager to avoid obsolescence, have been only too happy to adopt the moniker and promote themselves as API security vendors as well. But just because a WAF vendor now says it offers a WAAP does not mean it provides the capabilities needed to deliver on a holistic API security strategy.
When it comes to API security coverage specifically, WAAPs include API documentation support, schema analysis and validation, and some API discovery. WAAPs and their legacy WAF functionality and protection capabilities are still critical to defending APIs against a litany of pre-set attacks, including SQLi, code execution, and DDoS attacks. But WAAPs solve just one piece of the API security puzzle. Every API endpoint has its own underlying business logic and function, and defending those against abuse requires understanding API traffic over time. That’s not what WAFs or their evolved brethren WAAPs were built to do, so as organizations have embraced cloud native infrastructure and microservices, and the resulting increase in APIs, these older defenses aren’t enough to stop today’s more sophisticated and dynamic API attacks.
According to Rothman, there always comes a point with technology where you need a different capability. Thinking you can solve the problem with an existing set of solutions simply won’t work. Such is the case for WAFs/now WAAPs when it comes to API security.
Without context, gaps exist in API security
The manner of API attacks differs significantly from traditional application attacks. APIs have proliferated with the move to digitalization, changing and expanding every company’s attack surface. Because every API endpoint has its own unique business logic, each attack is unique, so attackers have to do a lot of probing to uncover an API vulnerability they can exploit. This reconnaissance activity, and any resulting exploit they can propagate, can take days, weeks, or even months to perform. Consider the recent T-Mobile breach. Attack efforts actually started in November of 2022, yet were only discovered by T-Mobile on January 5, after 37 million customer records were exfiltrated. Without proper context, adversaries can easily masquerade their attack efforts throughout an attack lifecycle.
In the case of APIs, organizations need deep and broad context to fully understand and assess potential threats. Relying solely on a WAAP alone for runtime protection leaves APIs exposed and vulnerable due to several key gaps in delivering this context. Specifically, WAAPs in general lack the context and intelligence-driven capabilities to:
- Monitor for longer attacks
- Identify behavioral anomalies that unfold slowly
- Provide extensive data classification
- Tap active learning
- Discern user intent
Even the most common API security vulnerabilities outlined in the OWASP API Security Top 10 list could not be dependably discovered with a WAAP.
WAAPs can’t monitor for longer API attacks
API attacks occur over longer periods of time. Bad attackers continuously poke and prod APIs to uncover potential weaknesses they can use to exfiltrate valuable data or cause other mayhem. Because WAAPs lack visibility across transactions over time, they cannot spot the days- and weeks-long reconnaissance activities that bad attackers need to attack today’s APIs. Viewing all traffic within the context of a single or several transactions, a WAAP misses the low-and-slow nature of API attacks.
You need to see the reconnaissance while it is happening. To protect your APIs – and the sensitive data they transport – you can’t just wait until you’re being actively attacked or notified of a successful attack in the form of a ransom demand. Even without having all the details in the T-Mobile attack, it’s safe to say that had that team had the proper API context over time, they could have identified the attack earlier – rather than 41 days later. To spot attacks, you need to have a bigger picture, built over time.
WAAPs can’t identify many API behavioral anomalies
In combination with visibility over time, API security solutions must also have the ability to pinpoint the anomalies tied to low and slow API attack campaigns, including extended reconnaissance activity, API abuse and misuse, and business logic manipulation attacks. Many organizations with mature API security programs operate under the assumption that business logic flaws and potentials for abuse exist in production systems today. This is because these organizations know it is so difficult to identify and dependably flush out business logic flaws and potentials for misuse during development and testing cycles.
As a result, the ability to accurately identify behavioral anomalies and discern user intent is viewed by most organizations as the most crucial part of their API security strategy. API attacks are behavioral, based on a string of activities. With a long view of behaviors, an advanced API solution provides an understanding of what represents “normal” behaviors within a given ecosystem, and what represents “out of the ordinary” behaviors that could flag a potential threat.
Built for yesterday’s security landscape, WAAPs (just like their related predecessor WAFs) only analyze a small subset of transactions at a time. WAAPs look for known attack patterns. Yet, because all APIs are unique, most API vulnerabilities represent zero-day vulnerabilities. Until someone misuses your API or takes advantage of a flaw that exposes data, you just don’t know the vulnerability exists.
No matter how intelligent WAAPs become, they will always have these architectural limitations. Lacking behavioral context, WAAPs cannot dependably differentiate between “ordinary” and “out of the ordinary” API behaviors to raise a red flag.
Consider the case of the Log4j vulnerability. WAAP and WAF solutions alike were unable to detect the zero day security event because the subtle changes in API parameter payloads did not raise any known attack rules or signatures these solutions were looking for. Further, these solutions were not architected to do extensive behavioral anomaly detection, so the slight change in parameter payloads could not be detected at all. As far as the WAAP was concerned, the payload was valid.
However, the Salt Security API Protection Platform spotted the flaw in our customers’ environments even before news of it hit the public – we didn’t know yet what we were seeing, but we spotted exploits of Log4j in our customers’ environments. Our artificial intelligence (AI) and machine learning (ML) engine flagged those exploits as deviations from existing API behavioral baselines. WAAPs have no baseline.
WAAPs have no extensive active learning capabilities
With time and exposure, AI-based solutions can “learn” from things that they have seen before. Having this wealth of learned intelligence available within a security system enables more accurate detection and drives a more effective response. Tapping the power of cloud-scale big data, learning in one customer’s environment enriches the algorithm, in turn benefitting every other customer, so the learning happens exponentially.
With its time-tested AI and ML algorithms, the Salt API security platform can deliver extensive insights and details about the nature of many API security gaps and how to fix them. WAAPs lack this intelligence.
WAAPs can’t discern user intent
Intelligence also provides insights regarding user intent. Cloud-scale, mature AI and ML models can analyze vast amounts of data and traffic, searching across 100s and 1000s of structural and behavioral attributes looking for signatures and patterns. The Salt API security platform continuously analyzes user attributes and past behavior across users and APIs to not just simply look for behavioral anomalies, but to discern user intent.
A WAAP is just not built to identify a slow-frequency, single ID broken object level authorization (BOLA) attack in an API fielding in excess of a billion requests a month. And BOLA represents the top API security vulnerability according to the OWASP API Security Top 10 list!
APIs are also often abused even though someone is using them exactly as designed. If an attacker stole and used legitimate access credentials against a privileged API for nefarious purposes, a WAAP typically could not spot the unauthorized access of the attacker and their masqueraded attack. Without context into user behaviors, the access would appear appropriate to a WAAP. Because WAAPs don’t deliver full visibility across all the different layers of an application stack, they cannot stitch together related transactions over time to see a potential threat.
API security – more than an “add-on” to your WAF
Recently, in the 2022 Gartner® Innovation Insight for API Protection, Gartner stated:
“Security leaders are looking for additional security capabilities to protect their APIs. They are expanding beyond their existing API gateways (GW) and web application and API protection (WAAP) solutions – especially in industry verticals with high security requirements.”
At the end of the day, WAAPs are more advanced than WAFs, and play an important role in an organization’s larger API security strategy, but still don’t and can’t holistically solve the problem of API security. They retain nearly all of the same shortcomings in their architecture that prevent them from meeting the technology requirements for API security. WAAPs simply do not have the depth and breadth of visibility, the intelligence, or the context over time to defend against increasing and ever-changing API attacks. Relying on WAAPs solely for API security leaves today’s blind spots in place – putting organizations at risk.
To secure today's growing and ever-changing API ecosystem, organizations require proper API security runtime protection in addition to their WAAPs. The Salt Security API Protection Platform provides organizations with the context needed to fully protect their APIs across build, deploy and runtime phases. For a customized demo, contact us.
Gartner, Innovation Insight for API Protection, Dionisio Zumerle,Jeremy D'Hoinne, et al.., 10 October 2022. GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.
