API Sprawl: The Attack Surface You Never Inventoried

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 organisations 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 organisations 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

Three Kinds of Endpoint Nobody Owns

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 the Inventory Is 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 organisation 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 organisation 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 programmes: 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 recognise 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 Authorisation 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 authorisation 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.

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 organisation rather than from a dashboard inside it.

Turn a point in time inventory into continuous discovery with Brandefense. — Brandefense offers solutions to transform inventory data into ongoing insights.

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 artefacts	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 programme 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.

A Sequence That Fits 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: https://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: https://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: https://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: https://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 organisations 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.