Why Zombie APIs are Such an Important Vulnerability

APIs have a lifecycle, the same as anything else. They are born, they live, and then they die. The problem is when a business moves so fast that the dead goes unburied. And just like in the movies, the “undead” can cause more problems than they ever did in life. So it is with Zombie APIs.

And, at a time when 92% of organizations plan to increase their API investment, learning about this critical API security trap is critical for those hoping to do so safely.

What are Zombie APIs?

In layman’s terms, a Zombie API is an API or an API endpoint that has been lost in the shuffle and is no longer being monitored, maintained, or even decommissioned by the security team. As updates roll out, it stays vulnerable. As old, outdated, or test APIs are removed, these linger on. As other APIs are accounted for in security strategies and corralled into protective safeguards, these remain rogue – and dangerous.

For obvious reasons, Zombie APIs are walking liabilities – shall we say vulnerabilities – for any company unlucky enough to have them. And many are.

What Makes a Zombie API?

How do these digital monsters come about? Carelessness, mostly. That, and the departure of tribal knowledge due to layoffs. “That’s the emergence of zombie APIs, because a lot of institutional knowledge lies with the people who built it,” noted Ankit Sobti, co-founder and CTO of Postman. “Once the people transition out, the change management is complex, and that’s where cataloging your API has internal APIs, in particular, becomes very critical.”

They get left behind in the API gold rush and remain forgotten as companies rush to innovate and move on – leaving deadly, exposed APIs in their wake. And without proper policies like API cataloging, their existence goes unnoticed. It is these very exposed, largely unsecured APIs that provide easy inroads for attackers and undermine the very progress fast-moving companies are looking for.

The Danger (and Lure) of Undead APIs

Just to spell it out, here’s a quick risk of the dangers of letting unused APIs run loose:

They no longer receive patches or security updates, leaving them exposed to exploits and cyberattacks.

They take up valuable resources that could be used on innovative new solutions, enhancing the user experience, and implementing more up-to-date technologies. “At worst, zombie APIs pose a security risk; at best, they deliver a poor consumer experience,” the Postman 2023 State of the API Report noted.

They are typically the easiest APIs to hack, contributing to high API attack costs, an estimated $12 billion to $23 billion in 2022 alone, due to compromises in web APIs. The Verizon 2023 Data Breach Investigation Report data indicates that the low-level attacks are raking in the most data breaches (just look at the success rates for Basic Web Application attacks).

This shows that hackers love the low-hanging fruit, and if they don’t have to resort to complex, time-consuming attacks, they probably won’t. Old APIs, riddled with stale vulnerabilities, provide just the kind of easy access they need for an easy win – and a massive inroad into various parts of your organization.

Zombie Hunting 101

Knowing how important they are to keep track of, here are some ways to find Zombie APIs (before they find you).

  • API Audits | Leverage penetration testing, vulnerability scans, and even red team engagements to ferret out all API instances in your ecosystem. Catalogue them all.
  • Activity Tracking | Monitor API usage patterns so you know which are still in use and which are dormant. Decommission the dormant ones.
  • Code Analysis | Examine your source code for any API calls that are no longer necessary – they will lead you to Zombie APIs.

Once you find them, here’s how you shut them down.

  1. Make sure you really don’t need it | This due diligence will save you a lot of time and trouble – check with the product owners, development team, and any other stakeholders.
  2. Plan it out | Create a timeline and inform everyone involved. Allow time for last-minute testing and verification. You don’t want any unforeseen consequences.
  3. Monitor the shutdown | Keep a close eye on the system as a whole to catch any adverse effects. If the planning stages have been done well, there shouldn’t be any.

You can also intermittently deactivate the API – if it’s an outdated one that just needs to be replaced – so users have fair warning, and you can avoid any confusion or downtime. Organization is the name of the game. The process is a simple but necessary one and one that can thwart a large enough subset of attacks to justify the time.

Learning from Our Mistakes

The more we invest in APIs and the growth they can give us, the more we need to learn from the security mistakes of the past. As far back as the advent of the internet, we were optimistic, and success (not security) inclined. As HTTP gave way to HTTPS and plaintext data was repeatedly hacked, we realized our mistake.

Now that new digital booms are coming with more rapidity, we need to remember to secure as we go. We need to balance form with function, and API innovation with the security practices that can make those innovations last for a long time to come. Even if that means taking a step back to secure against the API Zombie Apocalypse.

By Katrina Thompson