What’s The Difference Between Shadow APIs and Zombie APIs?

Shadow APIs and zombie APIs are, unfortunately, all too common. While they have cool names, their impact on organizations, data security, and user privacy is very uncool, threatening proper security best practices. In this piece, we’ll look at the difference between these types of APIs and suggest some ways to mitigate their negative effects.

What is a Shadow API?

First, let’s define a shadow API. When APIs are developed, they come with a bevy of associated tasks. Chief among these is documenting the API, ensuring that they are cataloged with an explanation for its use.

Shadow APIs arise from a lack of proper documentation practices. While documentation is a best practice for API development, it’s not technically a requirement for an API to run. As such, APIs are sometimes developed without any documentation, without any note that the API exists, and without any addition to a catalog or corpus of other APIs.

These APIs exist in the shadows of the organization, and in many cases, awareness is lost due to siloed knowledge, organizational shifts, or just plain forgetfulness. This can result in an API with privileged access or critical functionality existing without the organization’s awareness, introducing significant issues in the general security posture.

Shadow APIs are APIs that exist without organizational awareness or documentation.

What is a Zombie API?

Let’s imagine your API is developed, has a decent security posture, and is well-documented. The reality of documentation is that it’s only as good as it is current and maintained. Regular maintenance and auditing are required to make it worthwhile.

So what happens, then, when an API is left to linger even though it has been abandoned, deprecated, or otherwise left accessible but rendered unnecessary? In this case, an API becomes a zombie API.

Zombie APIs are still accessible and usable despite being no longer part of the regular product offering. Like zombies of pulp fiction, they shuffle in the API graveyard, not quite dead but not quite alive, wreaking havoc just by being present. This can cause major issues. The API is still usable, accessing data, and working on the network, yet has none of the maintenance or attention required of a standard API.

Zombie APIs are APIs that have been deprecated or abandoned but are still usable.

How Shadow APIs and Zombie APIs Are Similar

Firstly, it should be noted that both of these types of APIs arise from a lack of attention. Poor documentation practices and lifecycle management processes ultimately result in a product being developed that flies under the radar in the case of the shadow API, and poor sunsetting and deprecation standards resulting in lax communication and policy adherence results in zombie APIs.

In both of these cases, this lack of attention could be negligent as well as accidental. Regardless, the result is the same: visibility is reduced, and the security posture is dramatically damaged.

How Shadow APIs and Zombie APIs are Different

That being said, these types of APIs do have some stark differences. Shadow APIs arise from organizational issues that can be rectified by simply creating and sustaining the proper documentation culture alongside strong tooling for version tracking and development. No product should be developed and released into the shadows, and the existence of shadow endpoints underscores the need for internal discovery as much as an organizational overhaul.

In the case of zombie APIs, however, the problem is foundational. Outside of just the organizational issue inherent in shadow APIs, zombie APIs suggest a lack of cultural alignment. In an API-first culture, the API is the product, so the idea of leaving a zombie API shambling in the graveyard is like leaving a sack of gold on the ground. It’s fundamentally incompatible with healthy business and points to a large cultural misalignment that needs to be corrected.

Mitigating Issues From Shadow and Zombie APIs

Thankfully, you can take certain steps to improve organizational alignment and decrease the likelihood of creating shadow and zombie APIs. Here are ways to mitigate a handful of concerns that arise from these types of APIs.

Security Concerns

Shadow APIs might connect with secure resources, as they were designed to act as a standard API. The big problem with shadow APIs is their lack of documentation. Accordingly, the first step to resolving security concerns is ensuring the API is necessary, up-to-date, and documented. Once documented, the API must be reviewed to ensure that it fits with the current product offering and adheres to the security posture rules and regulations currently implemented.

On the other hand, zombie APIs represent a problem because they have outlived their intended timelines. Zombie APIs were meant to be deprecated or abandoned for good reason, and as such, the only real step that must occur to rectify security issues is to find them and cut off access entirely.

Compliance Concerns

Compliance concerns can arise from either of these API types. With shadow APIs, the problem is whether or not the route of accessing the information complies with industry and regulatory standards. With zombie APIs, the concern will be whether or not the API is still compliant regardless of whether it once was — if it was knowingly abandoned, this could be negligence, and if this abandonment happened when its security was known to be weak, this could be even worse.

Without documentation, none of this can be known. Accordingly, your first step is to either locate documentation or create it. Next, review and audit all configurations and functions to ensure they are actually compliant, as well as review transactions over time to ensure that no data has been exfiltrated and that security was maintained.

Privacy Concerns

Finally, you must review the privacy considerations of both API types. With shadow APIs, privacy should be aligned with the organization’s standard, but without documentation, this must be audited and reviewed in great detail. With zombie APIs, this is more complicated. The APIs may have adhered to privacy expectations when developed but could be outdated.

In such a situation, you must not only fix the problem but also document the problem and do your due diligence to ensure no private data has been accessed and no vulnerability was exploited. In many cases, this will be required by regulatory bodies, but even if it’s not, it’s morally correct and should be done as a standard course.

Final Thoughts on Securing Shadowy APIs

Ultimately, shadow and zombie APIs are significant concerns that should be handled immediately when detected. The causes of the issue should be identified and swiftly rectified to ensure the problem does not continue unabated.

Organizations often view their security posture as the sum of all its parts, including the firewall, gateway, and other components. However, the reality is that your security posture is only as good as the information you have about your system. As they say, you can’t secure what you don’t know.

Accordingly, understanding and clarity are key elements of your security posture. Shadow APIs and zombie APIs undermine understanding and clarity, and the presence of either represents a substantial weakness in this overall posture. Accordingly, doubling down on these areas is crucial to heighten overall security.

What do you think of our strategies for dealing with these spooky APIs? Let us know in the comments below!