API sprawl is the growth of APIs that nobody has recorded or retired: shadow APIs that were never documented and zombie APIs that were replaced but left running. NIST SP 800-228 says most organizations have gaps in their API inventories, and OWASP ranks improper inventory management ninth in its 2023 API Security Top 10. This post explains the types and a one quarter plan.
Ask a security team how many domains it owns and you will get a number. Ask how many cloud accounts, how many endpoints, how many suppliers, and you will get numbers for those too. Ask how many APIs are running in production right now and the honest answer is an estimate, usually delivered with a pause. That pause is the whole problem. It is called API sprawl: the one part of the modern estate that grows every week through normal engineering work and shrinks almost never.
Only 15 percent of organizations say they are strongly confident that their API inventory is accurate, and only 20 percent have measures in place to monitor their APIs continuously. In the same survey, 99 percent had encountered an API security issue within the previous twelve months. Those three numbers describe a single condition: almost everyone has the problem, almost nobody can see the estate it lives in.
| 99% of organizations encountered an API security issue in the past 12 months | 15% are strongly confident their API inventory is accurate | 20% have measures in place to continuously monitor their APIs | 98% of attack attempts targeted external facing APIs |
What Are Shadow, Zombie and Inherited APIs?
API sprawl is not one problem. It is three problems that share a symptom, and separating them matters because each is created by a different process and each needs a different fix.
| TYPE | HOW IT IS CREATED |
| Shadow API | An endpoint that reached production without ever entering documentation. Created by a team shipping under deadline, a proof of concept that quietly became load bearing, or a service exposed through a gateway rule nobody reviewed. It works, it serves traffic, and no register lists it. |
| Zombie API | An endpoint that was documented, formally superseded and then left running. Version one stays online after version two ships, because switching it off requires knowing who still calls it and nobody wants to be the person who broke an unknown integration. |
| Inherited API | An endpoint that arrived with an acquisition, a partner integration or an outsourced build. It was designed under someone else’s standards, authenticated against someone else’s identity provider, and documented in a repository your team may not have. |
The three behave differently under attack. A shadow API is usually current code with missing oversight. A zombie API is usually old code with missing everything: outdated authentication logic, unpatched libraries, no rate limiting and, most importantly, no logging that anyone reads.
Why Is an API Inventory Always Wrong?
The instinct is to treat this as a documentation discipline problem, solved by a stricter policy. That instinct fails for a structural reason: the rate at which endpoints appear is set by engineering velocity, and the rate at which the inventory updates is set by an assessment calendar. Those two clocks run at completely different speeds.
An organization deploying hundreds of times a month can create dozens of undocumented endpoints between two annual penetration tests. The test is accurate on the day it runs and stale within a fortnight. This is why only one organization in five reports any continuous monitoring of its APIs at all: the practice most teams have is an assessment, and an assessment is a photograph of something that keeps moving.
Four ordinary engineering practices generate sprawl without anyone behaving badly. Versioning leaves the previous release running for backwards compatibility. Microservice architecture turns every internal service into an addressable endpoint. Mergers and acquisitions transfer entire estates that were never mapped, a pattern familiar to anyone who has watched a forgotten domain resurface after a deal. And mobile applications ship with backend endpoints that exist nowhere in the web estate at all.
Why Attackers Map Your API Attack Surface First
There is a comfortable assumption buried in most API programs: that an endpoint nobody documented is also an endpoint nobody can find. It does not survive contact with how discovery actually works.
An undocumented endpoint is not hidden. It resolves in DNS. It appears in certificate transparency logs the moment a certificate is issued for it. It is referenced in the JavaScript bundle your web application serves to every visitor. It is embedded in the mobile application binary that anyone can download and decompile. It shows up in archived crawls of pages you deleted years ago. None of that requires access, credentials or anything a defender would recognize as an intrusion.
The targeting data confirms where this leads. In the same survey, 98 percent of attack attempts were aimed at external facing APIs, and 95 percent of API attacks came from authenticated sources, meaning the attacker had already obtained a way in and was working through endpoints from the inside. The asymmetry is the part worth internalising: the defender needs a complete list to be safe, and the attacker needs one endpoint to be successful.
This Is Not a Vulnerability Problem, It Is an Authorization Problem
Treating API sprawl as a patching exercise misreads it. The dangerous flaws in this category are rarely memory corruption bugs with a CVE attached. They are authorization failures: an endpoint that checks whether you are logged in but not whether the record you requested belongs to you. There is no vendor advisory for that, no version number to compare, and no signature for a web application firewall to match, because every request looks syntactically valid. A public example is the Liechtenstein beneficial owner register breach, where the government says faulty permission checks let the register’s API be used in a way it was not meant to be.
The second order effect is worse than the flaw itself. Detection content, rate limits and log forwarding are all configured against known assets. An endpoint absent from the inventory is therefore absent from the monitoring pipeline, which means the first evidence of abuse tends to arrive from outside the organization rather than from a dashboard inside it.
What Continuous Discovery Actually Requires
Continuous discovery is often sold as a feature and is better understood as a change in cadence. The objective is not a perfect list. It is the ability to notice a new endpoint within days of it appearing, from the outside, without depending on the team that deployed it to remember to file anything.
| SIGNAL | WHAT IT SURFACES |
| DNS and subdomain enumeration | Hosts that were provisioned for a service, a demo or a migration and left resolving after the project ended. |
| Certificate transparency logs | Every certificate issued for a hostname is published, which makes new endpoints observable from the moment they are secured, often before they are announced internally. |
| Client side artifacts | JavaScript bundles and mobile application binaries contain the endpoints they call, including the ones that no longer appear in any specification. |
| Archived and historical crawls | Endpoints referenced by pages that were removed from the site but never removed from the infrastructure behind it. |
| Change detection over time | The difference between this week’s observed estate and last week’s, which is the only reliable way to catch sprawl as it happens rather than annually. |
The practical test of whether discovery is continuous is simple. If a developer exposes a new endpoint on a Tuesday, does anything in your security program know about it before the next scheduled assessment? If the answer depends on that developer filing a ticket, discovery is not continuous, it is voluntary.
What Can You Do About API Sprawl in One Quarter?
| STEP | WHAT IT DELIVERS |
| 1. Establish the external baseline | Enumerate what is reachable from the internet without relying on internal records, then compare against the documented inventory. The delta is the working list and it is usually uncomfortable. |
| 2. Separate zombie from shadow | Undocumented but current endpoints need ownership. Deprecated but live endpoints need a decommissioning decision. Treating both the same wastes the effort on the wrong half. |
| 3. Answer the traffic question before switching anything off | The reason zombie endpoints survive is fear of breaking an unknown consumer. Observe traffic first, then retire with evidence rather than with hope. |
| 4. Close the logging gap | Every endpoint that survives the review must forward logs. An asset that cannot be monitored is not an asset that has been secured. |
| 5. Make discovery recurring | Set the comparison to run continuously and alert on new external endpoints. Without this step the exercise produces a clean inventory that begins decaying the same afternoon. |
Brandefense Coverage
| CAPABILITY | WHAT IT ADDRESSES |
| EASM | Continuous external enumeration of hosts, subdomains and exposed services, with change detection that surfaces new endpoints as they appear rather than at assessment time. |
| Certificate and DNS monitoring | Observation of certificate transparency and DNS records so that newly provisioned endpoints become visible from the moment they are created. |
| Brand Protection and DRPS | Identification of infrastructure registered against the brand, including endpoints standing up outside the sanctioned estate. |
| Cyber Threat Intelligence | Visibility into the tooling and tradecraft used to enumerate and abuse exposed endpoints, mapped to observable technique. |
| Dark Web Monitoring | Detection of exposed API keys, tokens and internal documentation appearing in leak channels, which is frequently how an undocumented endpoint becomes a targeted one. |
RELATED READING
The 62% Problem: Why Most Enterprises Only See Two-Thirds of Their Real Attack Surface: brandefense.io/blog/the-62-percent-problem-external-attack-surface/ The measured size of the visibility gap that API sprawl sits inside.
Shadow IT: Why the Assets Your IT Team Doesn’t Know About Are Your Most Dangerous Entry Points: brandefense.io/blog/shadow-it-hidden-attack-surface/ The same failure pattern one layer up, at the level of whole services rather than endpoints.
Merger, Acquisition, Forgotten Domain: How M&A Activity Quietly Expands Your Attack Surface: brandefense.io/blog/ma-attack-surface-easm-due-diligence/ Where inherited endpoints come from and why nobody ever owns them afterwards.
Vulnerability Exploitation Trends: H1 2026: What Threat Actors Are Actually Using: brandefense.io/blog/vulnerability-exploitation-trends-h1-2026/ Why waiting for a patch cycle is the wrong clock for an asset you did not know you had.
The uncomfortable summary is that API sprawl is not caused by negligence and cannot be fixed by a policy. It is produced continuously by teams doing their jobs well, at a speed no periodic inventory can match. The organizations that handle it are not the ones with the strictest documentation rules. They are the ones that stopped asking engineering what exists and started measuring what is reachable.
