Do you know how many Application Programming Interfaces (APIs) you have? It’s a straightforward question and yet it’s one most CISO’s and their security teams can’t answer. The reason for this is that APIs have become a runaway success story. They’ve been prolifically deployed by organisations to provide access to services and backend systems and are rapidly replacing web applications. But because they can be developed and spun up so quickly, they’re often not inventoried, or if they are replaced, older versions become redundant APIs that are then simply left exposed to the internet.
These APIs then effectively become invisible which is why they’re often referred to as ‘Shadow APIs’ while those that become obsolete but persist are known as ‘Zombie’ APIs. Unknown, unmanaged, and unprotected, these are becoming a favourite target for attackers. During our recent research, we found 31% or 5 billion of the 16.7 billion malicious transactionsthat wemonitored in the first half of 2022 were against Shadow APIs. This is because these APIs can be easily discovered and exploited by an attacker at their leisure.
Lucrative loopholes
If a shadow API interacts with production data or with an endpoint that is coded to accept variables or wildcard inputs, it can be discovered and abused. Attackers can also discover these APIs through other known, well-coded and well protected APIs. They can slightly alter i.e. fuzz the code associated with that API, and they can enumerate, run through and discover other API endpoints on different versions, under different hostnames, or which accept random characters at the end of the Unique Resource Identifier (URI), for example.
A compromised API then acts as a manual on how the API works, enabling the attacker to automate and scale their attacks. This is a key strategy often used by those seeking to monetize their attacks using shopping bots or credential stuffing, for instance. Highly volumetric scraping bots are then used to purchase sought-after retail items, to carry out slow trickle card testing fraud on stolen credit cards, or to feed brute force attacks in credential stuffing campaigns.
Driven by high volume content scraping as a precursor to shopping bot and gift card fraud, shadow API abuse surged in April 2022 and continued to rise in volume throughout the year. We also saw API-security related incidents transpire at Peloton, ClubHouse, John Deere and at Twitter where API keys were inadvertently exposed. This explosion in attacks shows that they are on the rise due to the lucrative information that APIs have access to. We depend upon them for everything from financial services to shopping to mobile apps, putting them at the very heart of our economy, which means protecting them must become a priority.
Runtime discovery
The first step towards effectively managing shadow APIs is to discover them. You cannot protect what you cannot see so you need to start by discovering, identifying, and inventorying your API footprint. Taking an internal and external snapshot to capture all existing APIs and connections and your public-facing API footprint can be highly illuminating, revealing just what an attacker would see.
However, discovery can be challenging because APIs are typically owned by numerous development teams, who are often in different groups and locations with little security oversight. The result is a wide range of API categories – managed, unmanaged, shadow, zombie, third-party, internal, and external – that are difficult to discover and inventory, requiring an automated runtime solution.
Many organisations underestimate their API deployment, usually by around a third, so the discovery process is often a wake-up call. But once these have been discovered, how should they be managed and protected going forward?
Previous practices
The tendency in the past has been to either protect APIs at a point in their lifespan (i.e. using run-time protection, dev-ops coding analysis or risk assessment) or to repurpose web application security solutions to look for attacks. However, API security differs markedly from web application security and other forms of threat protection because APIs are computer code, with no user interface or front-end. This means traditional forms of web security such as a Web Application Firewall (WAF), an API gateway, or even API specific tools are ineffective at providing protection throughout the lifespan of the API.
WAFs are designed to protect web applications, focusing on the OWASP Top 10 Threats, using signature-based attack detection. They do not perform automated API discovery, struggle to detect unknown threats, and are unable to perform risk assessments or generate testing traffic.
API gateways, while API-specific, are designed to help organisations aggregate and manage APIs by controlling access and providing some basic security functions (e.g., rate limiting, IP block lists). They are unable to proactively discover APIs that need to be managed, nor can they perform risk analysis, threat detection, remediation, or mitigation. Similarly, API specific toolsets are designed to help the development team produce APIs with fewer errors, which helps make newly released APIs more secure, but fails to address the full gamut of post-production security.
Lifetime protection
Protecting APIs therefore requires a solution that is not signature-based and which can discover, detect and defend against OWASP API threats (and combinations thereof) throughout the lifecycle of the API. So, in addition to discovery and inventory, we also need to consider API risk analysis, remediation and threat detection and prevention. The latter sees the inventory continually scanned for threats using runtime analysis, including subtle business logic abuses and emergent malicious activity, triggering alerts and proactive mitigation through the real-time blocking of traffic and even deception techniques.
In this way, it’s possible to not only discover but protect all the APIs on the network on an ongoing basis. This prevents any shadow APIs and ensures those that are live are continually monitored to remain compliant, while machine learning analysis looks for any suspicious activity that could indicate a compromise. Using this unified approach to API security, it then becomes possible to provide protection for every API from the cradle to the grave.
