API sprawl is widening attack surfaces faster than teams can govern

At a glance

What this is: This analysis shows how API proliferation turns cloud-native growth into a governance and security problem by expanding attack surface, fragmenting controls, and leaving shadow or zombie APIs exposed.

Why it matters: For IAM, PAM, and adjacent security teams, API sprawl matters because every unmanaged endpoint can carry privileged access, sensitive data flow, or weak authentication into production without consistent oversight.

By the numbers:

• Over 63% of organizations experienced security incidents due to unmonitored or inadequately secured APIs in 2024.
• The USPS Informed Visibility API exposed data for over 60 million USPS users after lacking proper access control and anti-scraping protections.

👉 Read Salt's analysis of API sprawl, shadow endpoints, and lifecycle risk

Context

API sprawl is the accumulation of many service endpoints, often created by different teams across cloud environments, until no single control point can reliably govern them. In practice, that creates an identity and access problem as much as a security problem, because APIs frequently rely on keys, tokens, and delegated access that are easy to lose track of.

The article argues that traditional tooling struggles because it was not designed for the scale, decentralisation, and lifecycle churn of modern APIs. That is a credible pattern across cloud programmes: once endpoints outnumber governance processes, exposure becomes routine rather than exceptional, and the organisation starts discovering risk only after data flows or access patterns have already drifted outside policy.

Key questions

Q: What breaks when API sprawl is not controlled centrally?

A: When API sprawl is unmanaged, teams lose visibility into where data flows, which credentials remain active, and which endpoints are still live. That makes consistent authentication, logging, and remediation impossible at scale. The practical failure is not just more endpoints, but more undocumented access paths that attackers can discover before defenders can govern them.

Q: Why do shadow APIs increase insurance and breach risk?

A: Shadow APIs expand the attack surface without corresponding ownership, testing, or monitoring. That creates unmanaged paths to sensitive data and business functions, which increases the chance of loss and makes claims harder to defend. If a team cannot identify an API, it usually cannot prove it is tested, monitored, or retired on schedule.

Q: How can teams tell whether API governance is actually working?

A: A working programme can answer four questions quickly: who owns the consumer, what it can access, where the policy is enforced, and how the call is logged. If any of those answers differ across protocols or gateways, the control model is fragmented and needs consolidation.

Q: Who is accountable when a partner API exposes customer data?

A: Accountability sits with both the API owner and the team governing the credential lifecycle. If third-party access is not scoped, monitored, and revoked when no longer needed, the organisation has accepted standing trust without lifecycle control. Frameworks such as NIST CSF and zero trust place that responsibility on access governance.

Technical breakdown

Why API sprawl defeats traditional security tooling

API sprawl makes endpoint inventory and policy enforcement drift apart. Traditional tools tend to assume a stable asset set, but APIs are created by multiple product teams, deployed across cloud and on-prem environments, and often change faster than central security review cycles. Each endpoint can have different authentication, rate limits, logging, and data exposure characteristics. That means security teams may see traffic, but not the business logic or access intent behind it. In identity terms, the problem is that credentials and authorisation rules are spread across hundreds of interfaces, not managed as a coherent control plane.

Practical implication: centralise API discovery and policy enforcement so security teams can map every endpoint to an accountable owner and access model.

How inconsistent API authentication creates exposure

When teams use different standards for authentication and access control, the result is not just inconsistency but exploitable weak spots. Some APIs may use robust federated identity, while others still accept static API keys or basic authentication that is hard to rotate and monitor. Once an endpoint is undocumented or rarely used, its controls often degrade further, especially if logging and anomaly detection are not tuned for it. This is where API governance intersects with NHI management, because service credentials and machine-to-machine trust often become the hidden identity layer of the application stack.

Practical implication: standardise authentication requirements for all APIs and eliminate legacy credential patterns that cannot be rotated, scoped, or monitored consistently.

What zombie APIs change in lifecycle risk

Zombie APIs are endpoints that remain active after their original purpose has ended. They are dangerous because they preserve access paths that teams no longer actively monitor, test, or own. From a lifecycle perspective, the failure is not only exposure but persistence: an old API can continue to serve data long after the application team has moved on, and attackers often target these forgotten interfaces because they are less likely to have modern controls such as anti-scraping protections, fine-grained authorisation, or current inventory records.

Practical implication: add API decommissioning, periodic revalidation, and continuous shadow API discovery to the application lifecycle, not as an afterthought.

Threat narrative

Attacker objective: The attacker wants to find overlooked APIs that provide unauthorised access to sensitive data, then harvest or query that data at scale before defenders can inventory the exposure.

1. Entry occurs through exposed, undocumented, or weakly protected API endpoints that were created outside consistent governance.
2. Escalation happens when the attacker queries permissive endpoints, abuses static credentials, or finds missing access controls and anti-scraping protections.
3. Impact follows as sensitive customer, health, or transactional data is exposed or exfiltrated at scale, often before the organisation realises the endpoint is still live.

NHI Mgmt Group analysis

API sprawl is now an identity governance problem, not just an application security problem. Once APIs become the dominant interface between services, the real control issue is who or what can invoke them, under which credential, and with what lifecycle oversight. That brings machine credentials, access scoping, and offboarding into the same governance conversation as endpoint discovery. Practitioners should treat APIs as identity-bearing assets, not just technical endpoints.

Shadow and zombie APIs create a standing-access problem for machine credentials. An endpoint that remains live after its business purpose ends often retains keys, tokens, and trust relationships that were never formally retired. That is a non-human identity failure mode because the access path can persist even when no team can clearly explain why it still exists. The discipline should shift from occasional cleanup to continuous ownership and expiry control.

Consistent API policy is the named control gap that most organisations still miss. The article points to a fragmented environment where some APIs use stronger controls while others fall back to basic authentication or API keys. That creates a policy drift problem: governance exists in documents, but not across the full inventory. Practitioners should assume that inconsistent enforcement, not isolated misconfiguration, is the default failure mode.

Lifecycle management is the only durable answer to API exposure at scale. Discovery tools help, but they do not close the risk if deprecation, rotation, and owner revalidation are missing. The organisation needs a defined process for API creation, review, retirement, and exception handling so that yesterday's integration does not become today's breach path. Security teams should measure how quickly undocumented APIs are found and removed.

What this signals

API governance will increasingly be judged by lifecycle speed, not policy volume. Security teams that can discover, classify, and retire APIs quickly will outpace the exposure created by cloud-native development. The operational signal to watch is whether undocumented endpoints are shrinking faster than new ones appear, because inventory lag is where risk accumulates.

Machine credentials turn API sprawl into a hidden identity programme. Every static key or long-lived token attached to an API is a non-human identity that needs ownership, scope, and expiry. If teams cannot explain where those credentials live and how they are retired, the environment already has an access governance problem.

API Tsunami: a useful shorthand for the gap between service growth and control capacity. The term captures how decentralised development creates more endpoints than central security processes can absorb. That means practitioners should invest in discovery, ownership, and automated decommissioning as core programme capabilities, not optional hardening.

For practitioners

• Implement continuous API discovery Build an always-on inventory that detects shadow and undocumented APIs across cloud environments, then tie each endpoint to an owner, data classification, and authentication method. Discovery without ownership does not reduce risk.
• Standardise authentication across all APIs Require consistent authentication, authorisation, and logging controls for every API, including legacy endpoints that still rely on static API keys or basic authentication. Exceptions should be time-bound and formally approved.
• Retire zombie APIs on a fixed schedule Add decommissioning checkpoints to the application lifecycle so endpoints are reviewed for continued use, business justification, and access scope before they remain live in production.
• Enforce anti-scraping and rate-limit controls Protect exposed data-bearing APIs with rate limits, abuse detection, and anti-automation controls, especially where endpoints surface customer or transactional information that attackers can enumerate at scale.

Key takeaways

• API sprawl turns routine application growth into a governance problem because every unmanaged endpoint can become an unauthorised access path.
• The evidence is already visible in real incidents, with more than 63% of organisations reporting security events tied to unmonitored or poorly secured APIs.
• The control that matters most is lifecycle discipline, combining discovery, authentication standardisation, ownership, and decommissioning.

Key terms

• API Secret: An API secret is a credential that allows a machine or application to access an API. It may be a key, token, password, or certificate. If exposed, reused, or left long-lived, it can be copied by attackers and used to impersonate the original workload.
• Shadow API: An API endpoint that exists in production but is not fully known, reviewed, or governed by the security programme. Shadow APIs often emerge through fast delivery, copy-paste development, or overlooked internal routes, and they create untracked exposure because they sit outside inventory, policy, and ownership processes.
• Zombie API: A zombie API is a deprecated or abandoned interface that remains accessible after the organisation believes it should be retired. It is risky because old permissions, secrets, or backend trust can survive the business purpose, turning legacy access into an active exposure.
• Machine Credential: A machine credential is a secret or identity artifact used by software rather than a person. It includes service account credentials, API keys, tokens, and certificates. In practice, the main risk is not just exposure, but unmanaged lifecycle, unclear ownership, and overbroad access.

What's in the full article

Salt's full article covers the operational detail this post intentionally leaves for the source:

• Specific examples of how API sprawl creates blind spots across cloud environments and business units
• Detailed discussion of how inconsistent authentication choices leave older APIs with weaker protections
• Case material on zombie APIs and the USPS Informed Visibility exposure, including the access-control failure pattern
• Practical recommendations for centralised API management, discovery, and lifecycle tracking

👉 Salt's full article covers the USPS case, API discovery challenges, and control recommendations in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the wider access and lifecycle decisions that modern security programmes depend on.