Shadow and Zombie APIs: How to Minimize Vulnerabilities

Application Programming Interfaces (APIs) are the backbone of modern software development and are now vital strategic assets for large enterprises.

However, with increasing API proliferation and subsequent sprawl, APIs can also pose significant security risks for enterprises. Shadow or zombie APIs running in production that your teams have forgotten about leave you vulnerable to attack. There's growing discussion on the importance of shifting left to incorporate design-time API security strategy, but how do you minimize the risk of those already lurking in your IT infrastructure?

API Security Attacks Are Exponentially Rising

API security attacks are a growing issue for enterprises. And breaches are often only discovered after the fact. Take T-Mobile's high-profile API breach; in the 41 days it took for the security team to catch and resolve, 37 million records of personally identifiable information (PII) had been seized. Even without any immediate fines (unlike a 2021 breach they've recently had to pay $350 million for), such security issues cause huge dents in customer trust, something large enterprises have worked hard to build and maintain.

More alarming still, unlike T-Mobile's breach, 78% of API attacks are now coming from authenticated users, and overall attacks have grown by over 400% in the last six months. Hackers are also specifically targeting publicly available repos and instances, such as this recently observed a spike in attacks on public Postman collections.

So what's at fault here? Hint: it's not bad for security teams.

Shadow and Zombie APIs Are Low-Hanging Fruit for Attackers

Shadow and zombie APIs are a primary cause as they're easy targets for attackers, and they're both growing in prevalence. 

Shadow APIs exist within your IT infrastructure but are not under the control of any IT or API team. These APIs are often created as one-off integrations by developers without any centralized knowledge or permission. Almost all aren't documented or managed properly. 

On the other hand, Zombie APIs are APIs that have been retired or abandoned but are still active and accessible. These APIs can create a significant security threat as they are no longer maintained, updated, or monitored, making them vulnerable to attacks.

The rise in developer productivity without effective API governance has worsened API sprawl and subsequent shadow and zombie APIs. And with APIs already deemed as low-hanging fruit for attackers, it's safe to say these two types of lurking assets are the easiest fruit of them all. This is especially true for large enterprises, who are now working with 1000s of APIs (of different types and categories) across disparate and distributed runtime environments.

Practical Steps to Minimize Risk

I'm sure you've read endless information telling you to take API security measures such as:

• Regular auditing
• Security education and training for developers and teams.
• Implementing robust security policies.

While these are all important and should not be overlooked, I want to provide an actionable example of how to identify and tackle zombie and shadow APIs.

1. Catalog and Identify

You first need to catalog all APIs across all gateways and runtimes into one place. This should be done in a way that's abstracted from the runtimes so you can unify them into one view and assess governance compliance and conformance but connected to them so you can rationalize against consumption metrics. This will help you quickly identify the following:

• Shadow APIs: these will be failing your governance checks. 
• Zombie APIs: these will have no consumers.

2. Make Shadow APIs Conformant, Compliant, and Secure

API governance still gets a bad rep with developers, but modern governance tactics can be used to quickly tackle obvious shadow APIs. Using automated, flexible, and democratized API governance, those APIs that are failing governance checks can be quickly rectified and secured without developers having to spend hours manually manipulating code against a rigid and centralized style guide. Any APIs that are identified as no longer needed as part of these checks can be quickly and safely retired.

3. Deprecate Potential Zombie APIs

Using consumption metrics from across your runtimes (ideally unified into the same catalog), APIs with no active consumers can be regularly deprecated from your runtimes after x days (however many you choose). This ensures zombie APIs are not lurking around and growingly forgotten about.

Bonus: Do So Without Impacting Your API Consumers!

Ensuring a great consumer experience for your APIs is simultaneously important. Your internal consumers, partners, and/or customers might be needing the exact API you've just identified as a zombie and deprecated. The goal state here is to have your catalog directly connected to your consumer portals, developer portals, and marketplaces; authenticated consumers can still see, request, and have these APIs redeployed. You're minimizing security risks without impacting your consumers' experience. 

In conclusion, shadow and zombie APIs, as a result of ungoverned and unmanaged API proliferation, pose a significant security threat to enterprises. Therefore, organizations need to be proactive in their approach to API security by implementing appropriate measures and best practices to mitigate the risks. Of course, choosing the right tooling to deliver these measures in a frictionless way is vital too. By doing so, organizations can ensure that their APIs are secure and their sensitive data is protected.