How Zombie APIs Pose a Forgotten Vulnerability

Zombie APIs are deprecated APIs that everyone assumes have been disabled but actually are smoldering in the dark regions of the application infrastructure. They are exploitable by new kinds of API attacks and can lead to account takeover or fraudulent transactions.

It is as important to think about how to kill APIs as it is to create them. But as with many modern consumer products, planning for their disposal sometimes comes as an afterthought. When APIs, or application programming interfaces, are merely deprecated without being formally retired, they can become zombie APIs that rise from the dead to wreak havoc when compromised by an attacker.

Over time zombie APIs are forgotten and may not be included in regular security upgrades. They may also become a security risk when new attack techniques are discovered. And even if they are not actually attacked, zombie APIs are like unlocked, forgotten doors that can allow developers to inadvertently access data in ways that violate privacy mandates like the European Union’s General Data Protection Regulation.

API lifecycle management processes often focus on creating, deploying, and managing the API. Although these steps can include discussion about deprecating an API, this often means just providing a newer API and hoping everyone migrates over from the old one.

A more technical approach to accounting for zombie APIs is covered as part of the OWASP API top 10 vulnerability list as API9:2019 Improper Assets Management.

Why Zombie APIs Refuse To Die

A zombie API is any API that has been left running, even after being replaced by new versions or other APIs entirely. Security teams tend to take an active effort in properly killing APIs when a security risk is discovered, but they may invest less attention in the process when developers are simply migrated to a newer or more efficient API.

The main reason that teams don’t drive a stake through an API’s heart outright is that such actions can hurt the developers and partners that have built apps off the API, leaving a bad taste in their mouth. Overtaxed developers may struggle to upgrade their apps to support the latest version. And sometimes older APIs are left running so internal developers don’t have yet another problem to fix.

Old APIs are also left running on test/UAT systems that still have an eventual path to exposure. Finding these dark left-behinds often comes down to using external monitoring tools, because they are generally not documented or tracked after the test.

Finally, developers may think they turned off code using code flags, but that accidentally can get activated later. For example, Knight Capital Group suffered a $450 million dollar loss in 45-minutes as a result of deactivated old code that was accidentally reactivated in an update to the app — a zombie apocalypse of the worst order.

If APIs are not given a good and proper death, enterprises risk allowing their once well-protected door to rot open as new kinds of API attacks are discovered and shared across the dark web.

Justifying a Good Death

It’s important for teams to agree up front on when and why to deprecate and terminate APIs. Some common factors that can motivate an API’s replacement include:

1. Dwindling adoption against rising management costs.
2. Lack of innovation around use.
3. Concerns about how an API may cannibalize existing or new revenue models.
4. Deciding it is cheaper to start over rather than fix bugs.
5. Realizing that another approach could bring efficiency gains.
6. Adoption of a new technology stack, such as moving from SOAP to REST or JSON.
7. Discovering new security vulnerabilities that are too hard to fix.
8. Adoption of programming languages better suited for implementing endpoints.

Security vulnerabilities should always include a hard termination date. For example, most companies made a concerted effort to kill APIs that supported the Netscape Plugin API after a security issue was discovered and users had a chance to migrate to browsers that supported HTML5.

To preserve developer loyalty it’s important to be clear about when and why you are terminating an API or someone’s access to it. The National Institute of Standards and Technology terminated its SOAP Service in 2020 after releasing a more efficient API for its vulnerability database and giving developers six months to transition. In contrast, Twitter irked many developers in the early days when it unilaterally changed many properties of existing APIs without explaining why or providing time to transition. This illustrates the delicate nature of terminating APIs in a way that keeps developers loyal. Since then, Twitter has been more communicative and clear about its API termination policies.

API developers should also consider issues around deprecating and retiring APIs even as they are built. This can guide not only how APIs are developed but include thoughts about how notifications can be used when APIs are retired, and how to migrate developers when APIs are finally put down.

Recognizing that APIs have a shelf life is one thing but burying that technology into the ground where it can do no harm is quite another.

Holding a Proper API Funeral

By planning for a proper death teams can be deliberate in reducing zombie API risk. Properly killing an API requires a bit of forethought on how to communicate with developers and partners that use the API to minimize the transition. This requires a funeral, with a precise date, maybe even a dress rehearsal, and guidance on how all involved can adjust most efficiently.

Major companies like Google and Twitter are proactive and organized in announcing plans for deprecating and finally terminating APIs. Google gives developers a year’s notice for normal terminations.

Teams need to decide how to continue management and maintenance of deprecated APIs if they continue to run. For example, Square publishes a guide to its deprecation process that not only covers APIs but changes in fields and supported endpoints.

Here are decommissioning steps to consider:

1. Formally schedule the termination date of an API while providing users time to update their APIs and applications that use them. It may also be helpful to include a transition period so developers can test updates before committing to the new version.
2. Organize public announcements about the end of APIs that include a migration guide and FAQ. For example, Microsoft recently advised developers on how to migrate from the deprecated Bing Speech applications API to its newer Speech Services API as part of a major migration effort.
3. Consider intermittently shutting down the API as its termination date approaches, much like bars flicker the lights at closing time. This gives stragglers fair notice the end is near. There are also ways to inform users directly within API responses such as including a sunset header in the HTTP response. “API Evangelist” Ken Lane recommends including an X-API Warn header in all requests to a deprecated API in his list of building blocks of API deprecation.

Checking for More Undead

Even after your team has invested resources in killing deprecated APIs, it is worth pulling out the virtual flashlight, wandering around the software graveyard, and looking for undead dawdlers. It only takes one zombie to be reanimated by a hacker to cause a horrific day.

One good strategy is to adopt tools to programmatically inventory all open APIs running on your application infrastructure. For example, modern API observability tools can help automate this process. This audit should also be cross-correlated with existing API documentation to ensure all running APIs are documented.

The OWASP report on API9:2019 Improper Assets Management observed that “APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important.”

It's also important to correlate running APIs with active business owners. The OWASP report noted that “Proper hosts and API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.”

If an API lacks a business owner, one should be assigned if it is deemed to provide ongoing value to a company’s brand or business.

If not, it should be assigned to an API mortician to provide it a proper funeral.

About the Author

George Lawton is a technology writer and regular contributor to The Inside Trace.