DEVOPSdigest

While most may be scared of goblins and ghouls this Halloween, the real threat to enterprise organizations this spooky season are zombie APIs. Though it may be Halloween, developer and security teams are spooked year round by these undetected threats. According to a recent report, approximately 92% of organizations have been impacted by at least one API security-related incident in the past 12 months, while 57% reported experiencing multiple API security incidents in the same time frame. Instead of falling victim to these undead APIs, here are a few reasons why zombie APIs are more dangerous than others and how enterprise organizations can implement best practices to prevent their damage.

What Are Zombie APIs?

In DevSecOps, zombie APIs are endpoints that are supposed to be turned off, but remain active — unbeknownst to developer and security teams. These can be unused endpoints caused by a variety of mistakes ranging from miscommunication between security and developer teams to newer APIs replacing old ones that are then forgotten about. Like zombies, these APIs are supposed to be "dead," but they're not.

What Security Concerns Come with the Presence of Zombie APIs?

Ultimately, the overarching security concern that allows for the existence of zombie APIs is the insufficient communication between developer and security teams about what a zombie API is, whether or not they exist, how to mitigate the damage they cause, and how to prevent them in the future. If organizations don't have smooth lines of communication between the two sides of DevSecOps, one may not be on the same page as the other when it comes to being fully aware of the life cycles or procedures behind deprecating an API.

Another major concern behind zombie APIs is their ability to go undetected and, therefore, untested. Because these APIs are forgotten about, but still remain alive, DevSecOps teams aren't regularly running patching or maintenance processes to ensure they're not exposing an organization's vulnerabilities that are lingering in the shadows. In addition, Zombie APIs are removed from documentation and an organization's API security testing program, leaving them to rot over time and expose new vulnerabilities.

With software applications, developer teams build and deploy a new version of an already existing API, often resulting in the older version becoming a legacy API — one that's still used, but not as much. Often, product teams will want to keep both versions active because someone is still using the legacy API or it's still generating revenue, security teams on the other hand, view this older version with the potential to be forgotten about, creating a zombie API by their subjective definition, and as a result will leave developer teams caught in the middle. The real issue here is security, developer and product teams lacking a unified definition of what a zombie API truly is, which creates internal tension and leaves wide room for human error.

What Can Developer Teams Do to Prevent the Zombie API Plague?

With zombie APIs posing significant threats to enterprise infrastructure and software application security and development, it's important to implement the following best practices to detect the undetected threats they pose:

■ Open communication with developers and security - Engineering and security teams share the responsibility of documenting and deprecating software that's no longer in use. Lack of communication between developers and security experts can cause zombie APIs to go undetected to one or both teams, leaving room for critical vulnerabilities. As a developer, it's most important to maintain constant, open, and effective communication with security teams to ensure all key stakeholders in API security are on the same page in terms of definitions, processes, roles, and responsibilities within an organization.

■ Use self-documenting code - As developers, we know that most documentation, testing, and remediation should be done at the code level and implemented as tests that run against the code before it hits production. By comparison to manual processes that are slow and error-prone, utilizing source code that self-documents every single API allows each API to be accounted for. This means no zombie gets left behind, and as long as security and application testing teams can see APIs documented in code, they can test it for major vulnerabilities.

■ Enforce and communicate clear product retirement procedures - Developer and security teams need to work together to define and agree upon precise product retirement procedures and maintain those policies whenever a product is deemed unnecessary. This will not only ensure all APIs deemed inactive are actually shut off, but also maintain consistency across the board to avoid zombie APIs creeping up.

Ultimately, as long as humans play a role in software application development and security, there will always be room for human error. Until security teams and developers can get on the same page with effective and efficient communication, zombie APIs will continue to be a widespread issue among modern enterprises.