Zombie API vs Shadow API: The Crashtest

The 1954 novel, “I Am Legend,” played a major role in the development of the modern zombie and vampire genre. As far as the main character, Robert Neville, knows, he’s the last survivor of the pandemic that turned everyone else into “vampires” (though they resemble more of what we think of as zombies). One distinguishing mark of the novel was the scientific explanation behind the disease, and the accompanying biological fix.


How does this relate to APIs? Two dangerous types of APIs are Zombies and Shadows. Let’s talk about how these foes present serious issues and how – like Neville found – there are non-magical, rational, logical, and reasonable fixes.


Zombies and Shadows


A zombie API is an API that has been abandoned by an organisation, lingering and forgotten. A shadow (aka Rogue) API is an organisational API that has been created but never documented, so it remains unknown by the organisation. The two are similar because, by not being in the official inventory for updating, securing, or removal, they present a serious liability regarding security, compliance, and privacy.


The difference is that the zombie API was at one time approved by the organisation, while the shadow API was never officially approved. Which is worse depends largely on how the API is being used and where it’s located. Internal and test APIs can be harder to access from the outside, but if a shadow internal API was created by a threat actor who now has active 24/7 access internally, then the internal shadow is a much higher threat than the public-facing zombie that no one has discovered.


A recent survey demonstrated that the zombie API tops the list of zombie shadow crashtest