Home / Knowledge hub / Zombie API
Knowledge hub
Zombie API
An old API version that should be retired but still answers requests.
What it means
A zombie API is an old version or endpoint that was meant to be retired but is still running and still answers requests. It might be /v1/ kept alive for an old mobile app, or a route left after a feature was replaced.
Unlike a shadow API, it was once known and documented. The trouble is that it stopped being maintained while it kept working, so it falls behind on fixes and sits outside the attention given to the current version. Everyone assumes it is gone, or harmless.
Why it matters
Old versions usually have the weaknesses you already fixed in the new one: missing authorisation checks, looser limits, older libraries, more data in responses. An attacker does not need to beat the new API if the old one is still open.
This also undermines your own fixes. You close a gap in version three, report it fixed, and the same request still works on version one. Auditors and customers asking about your patching will not accept a fix that covers only some routes.
How it shows up
Zombies survive because someone, somewhere, still calls them: an old app release, a partner integration, a script. Nobody wants to break that, so nobody switches it off. Without usage data, the decision is guesswork, and the safe-looking choice is always to leave it running another quarter.
Handle it deliberately. Track traffic per version, announce a sunset date, tell remaining callers, return clear deprecation notices, then switch it off. When a security fix lands, test every live version for the same flaw. See API versioning for how to plan this from the start.
Questions people ask
Zombie API, answered
What is the difference between a zombie API and a shadow API?
A zombie was documented and should have been retired. A shadow API was never documented.
Both are inventory problems, and the remedy starts the same way: know what is running.
How do we know who still uses an old version?
Log the version, client and key on every request, then review the traffic. If a small number of callers remain, contact them directly.
If you have no logs, you cannot safely retire anything.
Can we just return an error from the old version?
Yes, once callers have migrated. Until then, a response with deprecation notices and a clear end date gives them time without leaving the weaker version open indefinitely.
Set the date, announce it, and keep to it.
Do older versions need security fixes?
If they are reachable, yes. A flaw fixed only in the new version is still a flaw. Either back-port the fix or retire the old version.
Treat it as part of the fix, not a follow-up.
How do we test for zombies?
Request known and guessed older paths, such as /v1/ and /v2/, with and without credentials, and repeat any test that was fixed in the current version.
Compare behaviour between versions for the same request.
Sources
Where this comes from
Related
Terms that sit next to this one
Shadow API
An API running in production that nobody has documented, tracked or secured.
API versioning
Running old and new API versions together, and the security gaps the old ones keep.
API inventory
A maintained list of every API you expose, who owns it and what it returns.
Patching
Applying the fixes that vendors and maintainers publish.
End-of-life software
Software its maker no longer supports, so new flaws stay unfixed.
Did the fix reach the old version?
When a finding is fixed we re-run the exact exploit, so an old route that still allows it shows up as unclosed. Closed-loop retest beats a fresh scan here. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.