A Shadow API: The Ant that Turns into an Elephant

A shadow API is an undocumented, unmanaged, unmonitored, and untracked API with typically weak to nonexistent security mechanisms. In the beginning, it may appear like an ant—naive, tiny, and maybe even no problem at all.

But this ant turns into an elephant—indeed, the elephant in the room—in a jiffy. And if you comprehend its weight only after you’ve been trampled underfoot, that would be a tragedy of ancient Greek proportions.

Read on to learn how to avoid becoming the main character in a Greek tragedy.

What Is a Shadow API?

A shadow API is an active API that doesn’t operate within an organization’s established control and defense systems, such as API management and security programs and tools. For this reason, it’s sometimes called a rogue API.

The notion of a shadow API derives from the concept of shadow IT. Just as “shadow IT” refers to the active use of a piece of software without the knowledge or approval of the relevant authority in the organization (the IT department), so does “shadow API” refer to an API that exists outside of the boundaries of officially approved and known APIs.

The above implies that shadow APIs are known to dev team members but remain out of sight of most organization members, regardless of department and hierarchical position. Over time, that can make your life much more complicated than you have ever anticipated.

Shadow APIs are supposed to be a transient means of achieving expedient development, so they’re meant to be dispensable. Usually, developers create them for a temporary purpose to facilitate development tasks, such as testing or connecting apps that don’t include official out-of-the-box APIs. In that sense, they’re more of an API governance than an API security issue per se.

The real security headache begins if a temporarily useful shadow API:

• Is discoverable and accessible outside of the organization (instead of strictly internally by developers)
• Is under-authenticated and, generally, under-secured
• Becomes an overlooked leftover from some forgotten earlier use case

It’s worth noting that third-party APIs are also shadow APIs if you’re not aware of their presence in your environment and fail to include them in your API management program. It’s especially problematic if they remain invisible for a month of Sundays.

Shadow APIs and Zombie APIs

Shadow APIs are often discussed together with zombie APIs, and there’s a good reason for that:

• They both exist off the organization’s radar—they’re non-official APIs.
• They’re both largely by-products of the pressure of a fast-paced development environment.
• They both lead to virtually the same security consequences.

Despite their similarities, shadow and zombie APIs should not be reduced to each other. Their differences are important to know because they entail distinct approaches to eliminating or, at least, reducing the occurrence of these problematic APIs.

So, how does a zombie API differ from a shadow API?

At least two differences make these two types of non-official APIs separate security problems:

• Unlike a shadow API, a zombie API is created with the knowledge and approval of the organization, that is, its decision-makers.

  A zombie API is a deprecated API that you abandoned without properly decommissioning and deactivating it. For instance, if v3 is your current API version, and you’ve never officially and procedurally retired an older API version, v1 and v2 are zombie APIs.

  Your organization originally approved and monitored each of these two versions, and there was nothing shadowy about it. Each was an official API that served a good purpose. However, each became non-official when a new API version replaced it.

  The problem began when you failed to retire v1 and v2. Presumably, both API versions had deficiencies that made them obsolete and no longer supported in the first place. Consequently, when you left them unretired, you exposed them wide open to external access and abuse. And that’s how they became zombies.

• While a shadow API can cause issues because it’s actively used, a zombie API can generate problems because it’s no longer actively used.

  The active use of shadow APIs is precisely the problem. These APIs shouldn’t exist in the first place. However, their helpfulness, from a dev’s perspective, justifies their active use despite circumventing the set API governance protocols. And that’s what creates an unanticipated security risk.

  In contrast, the problem with zombie APIs is not that they come into existence but that they stay in existence—excuse our philosophical language—though forgotten and deserted. Zombie APIs pose a security risk because they’re no longer helpful and actively used but continue to be.

  It’s important to note that shadow APIs can also be forgotten, but that’s not what makes them shadow APIs. Instead, that means you have a double problem: A shadow API (the first problem) roaming unattended and unbeknownst to most (the second problem) in your information environment.

  

Shadow APIs and API9:2023 Improper Inventory Management

Proper API inventory management is hard. A recent study, 2023 State of API Security: A Global Study on the Reality of API Risk, found that maintaining an accurate API inventory is the second biggest challenge (37% of the responses) for organizations trying to secure APIs. It lags only behind API sprawl (48%), a related but not identical phenomenon.

Shadow APIs, along with zombie APIs, fall within the OWASP API Security Top 10, API9:2023 Improper Inventory Management category of API vulnerabilities.

The OWASP Top 10 API Security Risks is the most authoritative API security project yet. It lists and describes the ten most common and severe API security vulnerabilities. Improper Inventory Management, previously Improper Assets Management, holds the ninth position in both the 2019 and 2023 top ten lists.

As the current name suggests, the common denominator of the security issues this API vulnerability category comprises is API inventory. Your API inventory must be a complete list or catalog of well-documented APIs and API endpoints. When this catalog is missing, inconsistent, incomplete, or poorly maintained and done, it entails a grave security risk.

But why is improper inventory management such a severe problem?

The reasons are the following:

• This API vulnerability is easily exploitable.

  Uninventoried APIs are invisible APIs, and, as the constantly repeated saying goes, “You can’t protect what you don’t see.” This saying might have bored you to death already, but it expresses a fundamental truth.

  We cannot emphasize enough how critically important visibility is in API security and cybersecurity in general. How can you prevent or respond to a cyberattack taking place via a shadow API endpoint when you don’t even know this endpoint exists? Well… you can’t.

  Paradoxically, you’re usually the only one who doesn’t know about your potentially vulnerable API endpoints. Threat actors, on the other hand, discover them with as simple techniques as Google Dorking and DNS enumeration.

• Unaccounted for APIs, such as shadow APIs, are usually weakly secured and unpatched.

  That leaves the gates of your information environment open to all kinds of exploitation, including a leak of sensitive data in cases where the non-official APIs retain access to databases with genuine user or company information.

• Related to the previous point, uninventoried APIs lead to a host of other problems.

  More precisely, uninventoried APIs do not have to be the primary target of a cyberattack.

  Due to their invisible nature and loose or completely absent security mechanisms, they make for an easy entry point to an otherwise well-secured underlying system.

  Once discovered by a threat actor, they allow lateral movement, that is, spreading progressively across a network to penetrate deeply into a system, find and abuse weaknesses, escalate privileges, and inflict extensive (sometimes irreparable) damage.

If you were wondering how often attackers target organizations suffering from improper inventory management, prepare to be stunned.

A comprehensive study from 2022, API Protection Report: Shadow APIs and Automated Abuse Explode, revealed that 5 billion out of the 16.7 billion observed malicious API transactions had shadow APIs as their target. That’s approximately 31%, that is, almost a third of all the malicious API transactions, which made shadow APIs the No. 1 attack vector in the first half of 2022.

The Consequences of Shadow APIs

What makes shadow APIs such a dreadful risk is the consequences they can lead to. When we say consequences, we mean the following:

• Data exposure, leak, or theft—the biggest security concerns regarding shadow APIs
• Operational issues such as enormous resource consumption

• Unstable systems
• Non-compliance

These can be related. For instance, if a hacker steals sensitive data like personally identifiable information (PII) from your system by abusing a shadow API, you can be fined for non-compliance with GDPR.

We’ll look at three real-life security incidents to illustrate what happens when shadow APIs inhabit your information environment.

The Optus API Breach

The Optus API breach happened in 2022 between 17 and 20 September, when a threat actor stole the data of nearly 10 million customers of this Australian telco.

The attacker achieved this feat by abusing a publicly exposed dormant API used for testing. The API lacked authentication and authorization mechanisms and had been out of use for some time.

Optus was fined, suffered additional financial losses, and ended up with an irretrievably damaged reputation.

The Optus data breach is considered one of the worst security incidents ever.

An Apple Pay API Abuse

The same API Protection Report we referred to earlier mentions a security incident in which a sneaker cook group discovered a shadow API that invoked Apple Pay on a prominent footwear and apparel retailer’s platform.

Because the API lacked strong security mechanisms and was unknown to the retailer, the attackers could send over 100 million malicious API requests during the launch of a new, eagerly awaited sneaker.

The Facebook Hack

In 2018, an ethical hacker disclosed a Facebook vulnerability involving shadow API endpoints.

The official Facebook website includes rate-limiting, which prevents users from sending more than ten password recovery requests. Unfortunately, the shadow API endpoints beta.facebook.com and mbasic.beta.facebook.com lacked this security mechanism. That allowed the hacker to send myriads of requests and successfully brute force password recovery codes.

How to Prevent and Find Shadow APIs

Hackers can find shadow API endpoint information in the path, header, query parameters, or request body of API requests and responses (basically everywhere). All they need to do is look for something like api.test.target.com, beta.api.com, /api/private, /api/partner, or /api/test in API transactions.

Informed guessing, automated fuzzing, and brute forcing are some additional techniques threat actors use to find shadow APIs, as well as other instances of improperly inventoried and managed APIs.

The good news is that you can do the same. How? Through API security testing or, more specifically, API penetration testing.

Both manual and automated API pentesting adopt the same approach and techniques, some of which we mentioned above, as malicious actors. The difference is that they’re ethical. Their purpose is not to attack and harm APIs but to attack and secure them by finding the same bugs, issues, and vulnerabilities threat actors find, including shadow APIs.

After they find them, they report and provide remediation guidelines. That’s one effective method for improving API inventory management.

In addition to API security testing/pentesting, you can implement the following methods to eliminate or reduce the security risk from shadow APIs:

• Continuous and detailed, if possible, automated API inventory
• Automated API documentation as part of the CI/CD pipeline to eliminate blind spots
• Training on security best practices and secure coding, since devs are key in preventing the proliferation of shadow APIs
• API gateways for early detection and deterrence of shadow API attacks
• Static code analysis to find shadow APIs in development
• Data classification to eliminate data flow blind spots
• API discovery through monitoring network traffic
• Limited network access for non-production APIs
• Outbound proxy monitoring
• Log analysis
• API audit

Conclusion

Shadow APIs are APIs that are not visible to you even though they’re active in your information environment. They fall within the category of Improper Inventory Management, one of the OWASP top ten API security vulnerabilities. Despite being relatives, shadow and zombie APIs are not identical.

Although they may not seem like a big threat at first, shadow APIs can lead to terrible consequences, such as data breaches and the theft of sensitive information. You can implement a range of measures to prevent this from happening, find shadow APIs in your environment, and minimize their occurrence. Some of them are continuous API inventory, automated documentation, and API security testing.

Contact us to learn how Equixly can help you find shadow APIs and improve your API security posture through precise data classification. We look forward to hearing from you.

Carlo De Micheli

Director of Product Marketing

Carlo is a versatile professional with extensive international experience. His enthusiasm for innovation extends across cybersecurity, automotive, and aerospace, where he actively engages in pioneering projects. Holding a technical background in aerospace engineering and supplementing it with independent studies in programming and security, Carlo has organized and presented at international conferences and established tech startups related to the sharing economy and fashion before embracing marketing and sales.

Zoran Gorgiev

Technical Content Specialist

Zoran is a technical content specialist with SEO mastery and practical cybersecurity and web technologies knowledge. He has rich international experience in content and product marketing, helping both small companies and large corporations implement effective content strategies and attain their marketing objectives. He applies his philosophical background to his writing to create intellectually stimulating content. Zoran is an avid learner who believes in continuous learning and never-ending skill polishing.