Why Are Zombie APIs and Shadow APIs So Scary?

Question: What is the difference between zombie APIs and shadow APIs?

Nick Rago, Field CTO, Salt Security: Zombie APIs and shadow APIs represent by-products of a larger challenge that enterprises are struggling to tackle today: API sprawl.

As companies seek to maximize the business value associated with APIs, APIs have proliferated. Digital transformation, app modernization to microservices, API-first app architectures, and advancements in rapid continuous software deployment methods have fueled the high-velocity growth of the number of APIs created and in use by organizations. As a result of this rapid API production, API sprawl has manifested itself across multiple teams who leverage multiple technology platforms (legacy, Kubernetes, VMs, etc.) across multiple distributed infrastructures (on-premises data centers, multiple public clouds, etc.). Unwanted entities such as zombie APIs and shadow APIs emerge when organizations do not have the proper strategies in place to manage API sprawl.

Simply put, a zombie API is an exposed API or an API endpoint that has become abandoned, outdated, or forgotten. At one point, the API served a function. However, that function may no longer be needed or the API has been replaced/updated with a newer version. When an organization does not have proper controls in place around versioning, deprecating, and sunsetting old APIs, those APIs may linger on indefinitely — hence, the term zombie.

Because they are essentially forgotten, zombie APIs don’t receive any ongoing patching, maintenance, or updates in any functional or security capacity. Therefore, the zombie APIs become a security risk. In fact, Salt Security’s “State of API Security” report names zombie APIs as organizations’ No. 1 API security concern over its past four surveys.

In contrast, a shadow API is an exposed API or an API endpoint whose creation and deployment were done “under the radar.” Shadow APIs have been created and deployed outside of an organization’s official API governance, visibility, and security controls. Consequently, they can pose a wide variety of security risks, including:

• The API may not have proper authentication and access gates in place.
• The API may be exposing sensitive data improperly.
• The API may not be adhering to best practices from a security standpoint, making it vulnerable to many of the OWASP API Security Top 10 attack threats.

A number of motivating factors are behind why a developer or app team would want to deploy an API or endpoint quickly; however, a strict API governance strategy must be followed to enforce controls and process over how and when an API gets deployed regardless of the motivation.

Adding to the risks, API sprawl and the emergence of zombie and shadow APIs extend beyond APIs developed in-house. Third-party APIs deployed and utilized as part of packaged applications, SaaS-based services, and infrastructure components can also introduce problems if not properly inventoried, governed, and maintained.

Zombie and shadow APIs pose similar security risks. Depending on an organization’s existing API controls (or lack thereof), one may be less or more problematic than the other. As a first step to tackle the challenges of zombie and shadow APIs, organizations must use a proper API discovery technology to help inventory and understand all of the APIs deployed in their infrastructures. Additionally, organizations must adopt an API governance strategy that standardizes how APIs are built, documented, deployed, and maintained — regardless of team, technology, and infrastructure.