This guest post was contributed by Dan Hopkins, VP of Engineering, StackHawk.
Are you haunted by Zombie APIs? Unfortunately, Halloween isn't the only time Zombies come back from the dead. Zombie APIs are lurking in the shadows, hiding in plain sight and living year round inside many organizations, haunting even the most experienced professionals. Unbeknownst to many, Zombie APIs are widening an organization's attack surface and living amongst other published APIs. According to a State of API Security Report earlier this year, findings showed that outdated/Zombie APIs were amongst respondents top concerns, with 54% indicating that this risk is of high concern. This piece will give insights into the risks of Zombie APIs as well as ways enterprise organizations can mitigate risk.
As organizations across every industry continue to scale and maximize the business value that comes with APIs, API usage has grown at a rapid speed. Everything from digital transformation, app modernization, cloud migration and advancements in software development have fueled this tremendous growth. However, as with anything that grows rapidly, unwanted APIs such as Zombie and Shadow, have become real threats to organizations as they do not have proper governance, API visibility and lifecycle strategies in place.
What even is a Zombie API?
A Zombie API is an exposed API or API endpoint that has become outdated, abandoned or forgotten by security and development teams. At one point in its “life” this now Zombie API served a specific function or purpose. However, that purpose or function was no longer needed or the specific API underwent updating with a newer version or was simply moved to a different location and forgotten about. Because there are no regular patching or updates being made in either a functional or security capacity, Zombie APIs have the ability to become an incremental security risk. They are removed from API documentation and security testing programs, leaving them to linger in their everlasting undead existence and expose new vulnerabilities.
Do you know what is lurking in the API shadows?
Similar to a Zombie API, a Shadow API is an exposed API or an API endpoint which was created and deployed under the radar, existing outside of an organization's official API ecosystem. A Shadow API can remain invisible to most and void of security controls. You may assume these APIs were created with poor intentions, but that is usually not the case. Most often, Shadow APIs are created and deployed by well-meaning developers who are working against the clock to meet business and application innovation demands. Despite there being no ill-intent from a developer, these unmanaged, non restricted APIs have the potential to cause severe vulnerabilities and widen the attack surface. Shadow APIs often fail to adhere to correct API governance standards, may not meet security best practices such as those outlined in the OWASP API Security Top 10, and may also expose sensitive data.
What causes the presence of Zombie and Shadow APIs?
Many ask why there is such a widespread presence of Zombie and Shadow APIs across organizations, opening the door to bad actors. The answer is simple: broken and siloed communication between security and developer teams. From a developer and engineer teams perspective, they are under pressure to rapidly create APIs in order to keep pace with innovation. From a security team's perspective, they are trying to protect and manage APIs to protect the entire organization. Both teams play an important role in securing the wider API ecosystem. There must be better communication between these two teams when it comes to API documentation and inventory management. Developer and engineering teams not only have a shared responsibility to keep a detailed log of all APIs created and deployed, they also have a duty to communicate and brief appropriate parties like security teams on deprecated APIs that are no longer in use. The only way to tighten the attack surface and minimize vulnerabilities is for teams to communicate so that it is clear that appropriate patching and testing initiatives are carried out and allow the complete removal of expired APIs.
Similarly, when it comes to the threat of Shadow APIs collaboration amongst teams and strong DevSecOps practices is key. Security teams must work with developers and engineers to create, clearly define and enforce governance policies for APIs being created. These policies should clearly describe who can create new APIs, how they should be designed, deployed and utilized as well as which testing requirements are needed for new APIs before they can go into production.
Zombie and Shadow APIs will continue to exist because of human error and poor communication. By working on improving collaboration and communication between developers, engineers and security teams API documentation, inventory management as security best practices will be strengthened. If these teams continue the way they have been, they will only face more API risk, threats and be more susceptible to the tactics of bad actors.
###