Many zombie films convey the message that the real monsters are not the shambling horde outside but right here among us. Fear, mistrust, betrayal, bad decisions…that’s what leads to everyone being picked off one at a time.

The same can be said with Zombie APIs. Okay, maybe not fear, mistrust and betrayal, but bad decisions certainly contribute to unused, abandoned APIs offering a route for threat actors looking to breach a perimeter.

The State of API Security Q1 2023 report from Salt Labs shows the magnitude of this problem. The use of Zombie APIs in cyberattacks is four times as common as it was six months ago and is increasingly seen by attackers as an easy way in. It’s vital that businesses identify this problem and shore up their defences. But what exactly is a Zombie API?

They’re coming to get you, Barbara

APIs are indispensable, powerful interfaces that connect our world and mean we can share data in simple, streamlined ways. The creation of Open Banking APIs in the UK is just one example, allowing new fintechs to flourish and giving consumers new ways to link up their different financial products. Remote and hybrid working has also had an effect on the number of APIs, thanks to an increased need for software integration.

The usefulness of the APIs means they are more widespread than many people realise. According to Noname Security, the average organisation uses more than 15,000, and this number increases to 25,000 for large enterprises. 

It’s a seemingly impossible number, and that’s for good reason—a much smaller number of APIs are in active use. Some may be used for testing, others for abandoned projects, and many others are simply forgotten about once they are no longer needed or have been supplanted by another. This isn’t unusual—many businesses that have been around a while have documents or code hanging around on servers that are no longer needed. 

Aside from taking up space, these vestiges aren’t usually a problem, but APIs are different, designed to allow open communication between programs and often left wide open for functionality and ease of use. If not properly decommissioned, an API can be an access point, potentially to an entire system. With hundreds, or even thousands, of dormant APIs to try and exploit, it’s no wonder that threat actors are ‘re-animating’ Zombie APIs for their own advantage.

The Marsh McLennan Cyber Risk Analytics Center has estimated that API vulnerabilities cost businesses anywhere up to $75 billion annually. Clearly, businesses should be decommissioning those old APIs. What’s stopping them?

Remove the head, or destroy the brain

It seems simple: the team responsible for the API should ensure it’s no longer exposed when there’s no need for it. But there is a distinct lack of ownership—security teams and development teams see it as the other guys’ problem. One study by Traceable AI illustrated this perfectly: 38% said the CISO was responsible, 25% said the development team and 24% had no answer—they just didn’t know who should take ownership. 

The problem is partly that while developers spend the most time creating APIs, the security team is usually saddled with the full burden of upholding security best practices. However, developers are best placed to share some of the responsibility, especially when it comes to APIs. How can businesses ensure that they are adequately upskilled to do so?

Training: Developers need to be trained in API security in order to take control of API security best practices. Training should be a part of a developer’s schedule, with adequate time allocated, using a microlearning approach that results in contextual awareness. We know that standard, static, enforced training doesn’t result in lessons sinking in—people learn the most at the moment of need and when training occurs in “microbursts” embedded within everyday work activities. If we want developers to be more security conscious, we need to give them the tools to do so—if we don’t, then we’re simply setting them up for failure.

Ownership: Every security process must have an ownership structure. Responsibility for API security needs to be assigned and communicated from the executive level, not just an email or a meeting. Getting a team to take ownership needs to be about making sure they have the resources and information necessary to tackle the problem rather than assigning blame.

Documentation: Just as there’s an increasing need to document every aspect of development through a Software Bill of Materials (SBOM), every API needs to be documented and decommissioned when no longer in use. Even a mature, security-conscious development team cannot contend with thousands of Zombie APIs if there is no way to know where they are implemented. New APIs need to be documented using a standard process, and those that exist need to be surveyed and either documented or removed depending on their status.

Just like understanding the origins of a virus to cure the infected, businesses need to know where an API has come from, who maintains it, and its level of access—is it secure? Is it needed? Can anyone get in? Eradicating Zombie APIs is the only way to avoid a security jump-scare.