API sprawl and shadow exposure are widening attack surface risk

At a glance

What this is: Salt argues that API sprawl and shadow exposure are expanding attack surface risk because many organisations do not have an accurate inventory of what they expose.

Why it matters: This matters to IAM practitioners because API security increasingly depends on identity, inventory accuracy, entitlement scope, and runtime governance across human, machine, and third-party access paths.

By the numbers:

• More than 80% of internet traffic now routes through APIs.
• 64% of organizations have encountered an API attack or security breach in just the past year.
• Many organizations underestimate their API count by 70% to 80%.
• 87% of organizations are uneasy about data governance or data exposure from insecure APIs.

Context

APIs are now a core control plane for digital business, not just a software integration layer. When organisations lose track of internal, external, shadow, and third-party APIs, they also lose track of who or what can reach sensitive data and functions. That turns ordinary interface growth into an identity and exposure problem, because unmanaged API inventory usually means unmanaged authentication, authorisation, and monitoring boundaries.

The central governance gap is not simply attack volume. It is the mismatch between fast-changing API estates and slow-moving control processes, especially where machine-to-machine access, delegated tokens, and third-party integrations are involved. Salt’s article points to a pattern that is increasingly typical: exposure grows faster than inventory, and once APIs are forgotten or poorly classified, security teams cannot enforce consistent policy across the environment.

Key questions

Q: What breaks when API inventories are incomplete?

A: When inventories are incomplete, teams cannot reliably know which APIs exist, what data they expose, or which identities and tokens can reach them. That breaks risk assessment, ownership, logging coverage, and incident scoping. The result is usually delayed remediation, hidden exposure, and inconsistent control enforcement across production services.

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: What are the signs that an API control program is failing in practice?

A: Common warning signs include spikes in 403 responses, bursts of schema violations, sequential ID access, repeated webhook IDs, and tokens reused across services. Those patterns usually mean authorization is weak, contract enforcement is drifting, or replay protection is incomplete. Teams should correlate runtime signals with negative tests and owner metadata to find the broken control quickly.

Q: How should security teams govern AI infrastructure that depends on APIs and microservices?

A: They should treat the combined stack as one identity system and map every machine-to-machine handoff, token, and delegated permission to an accountable owner. The key control is not the API gateway alone. It is the ability to trace, limit, and revoke access across the entire runtime path without relying on manual exception handling.

Technical breakdown

Why API sprawl creates a governance blind spot

API sprawl means the organisation has more live interfaces than its inventory, ownership model, and control processes can accurately track. That becomes dangerous because security controls depend on knowing what exists, who owns it, what it exposes, and which identities can call it. Shadow APIs, deprecated endpoints, and third-party interfaces often bypass standard review cycles, so they are left with stale policies, weak authentication assumptions, or no monitoring at all. In identity terms, the problem is not only the API itself but the delegated access and trust relationships attached to it.

Practical implication: Map every API to an owner, authentication method, and data classification before applying policy or runtime controls.

How shadow APIs expand the attack surface

Shadow APIs are interfaces that remain reachable but are not visible in normal governance workflows. They often persist after application changes, mobile releases, acquisitions, or partner integrations, and attackers target them because they are less likely to have current testing, logging, and authorisation checks. The risk is amplified when business logic is exposed through APIs, because a technically valid request can still be abusive if the workflow was never designed to resist automation or data scraping. This is where identity governance meets application security: access may be authenticated, but still over-broad or unreviewed.

Practical implication: Continuously discover APIs that are reachable but not in the approved inventory, then retire or reclassify them.

Why runtime protection must go beyond perimeter inspection

Perimeter tools can see traffic patterns, but they often miss whether a request is legitimate in context. API business logic attacks exploit normal functionality, valid tokens, or ordinary request flows, which makes signature-only inspection insufficient. Runtime governance has to evaluate request intent, entitlement scope, object access, and unusual use of legitimate credentials, especially where APIs are encrypted or spread across cloud and on-premise systems. For IAM and NHI teams, this is the critical distinction: authenticating a caller is not the same as controlling what that caller should be allowed to do once inside the API.

Practical implication: Apply behaviour-aware controls that evaluate request context, entitlement scope, and anomalous use of valid API credentials.

Threat narrative

Attacker objective: The attacker aims to turn hidden or over-permissioned API access into unauthorised data exposure or functional abuse at scale.

1. Entry occurs through exposed, forgotten, or unauthenticated APIs that were not captured in the organisation’s current inventory.
2. Attackers abuse legitimate API functions or weak object-level checks to access data or actions that exceed the intended entitlement scope.
3. The impact is unauthorised exposure of sensitive records, business logic abuse, and broader trust erosion across the API estate.

Breaches seen in the wild

• T-Mobile API breach 2023: An attacker pulled data on 37 million T-Mobile accounts through one API, without authorisation, for six weeks before detection.
• Sourcegraph breach 2023: A site-admin token left in a Sourcegraph commit for 47 days let an attacker become admin and offer free access to its APIs and LLM via a proxy.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

API visibility has become an identity control problem, not just an application inventory problem. If teams cannot reliably enumerate internal, external, shadow, and third-party APIs, they cannot govern the machine identities and delegated access paths that depend on them. That makes API sprawl a structural weakness in IAM and NHI programmes, not a perimeter issue. The practitioner conclusion is simple: inventory quality now determines control quality.

Shadow API exposure creates a standing trust gap that attackers can exploit without breaking authentication. APIs may accept valid tokens or requests while still exposing data or functions that were never meant to be reachable. This is why runtime governance matters more than static approval lists, especially where AI systems and third-party services consume APIs at scale. The practitioner conclusion is to treat API visibility, entitlement scope, and runtime authorisation as one control surface.

API business logic abuse is the named concept this article reveals. The failure is not only unauthorised entry but unauthorised use of valid functionality, which slips past controls that focus on signatures or simple blocking. In practice, that means security teams must govern how an API can be used, not only whether it is reachable. The practitioner conclusion is to align API security with authorisation, monitoring, and workflow abuse detection.

API security and NHI governance are converging. As APIs become the backbone for mobile, IoT, cloud, and AI workloads, the identities calling them are increasingly non-human and often ephemeral. That raises the bar for lifecycle management, token scope, and offboarding discipline. The practitioner conclusion is to extend identity governance to every API consumer, not just human users.

The market signal is moving toward unified discovery plus runtime control. Point-in-time review is not enough when APIs update frequently and new interfaces appear outside normal change control. Organisations need governance that combines discovery, risk classification, and behavioural enforcement. The practitioner conclusion is to measure API security by coverage and control enforcement, not by policy existence alone.

From our research library:

• Secrets management is a top five cybersecurity priority for only 33% of organisations, behind cloud security (45%), API security (42%), and endpoint security (36%), according to the 2024 State of Secrets Management Survey.
• 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
• Read next: LLM Provider API Key Security and LLMjacking Guide

What this signals

API sprawl is now an identity governance issue because machine and delegated access paths expand faster than inventory accuracy. When organisations cannot keep a current record of APIs, the entitlement model around those interfaces becomes unreliable, and the control boundary shifts from approval to discovery. The practical response is to govern API consumers the same way other high-risk identities are governed: by ownership, scope, and continuous review.

API business logic abuse is the signal practitioners should watch for as the category matures. The most useful controls will increasingly be the ones that detect legitimate requests behaving illegitimately, not just blocked requests. That pushes teams toward runtime inspection, entitlement analysis, and tighter alignment between application security and identity governance.

More than 80% of internet traffic now routes through APIs, according to the 2024 State of Secrets Management Survey. That scale makes API exposure a board-level governance issue, not a niche engineering concern, because every unmanaged interface expands the number of identities, tokens, and workflows that security teams must control.

For practitioners

• Build a complete API inventory Discover internal, external, shadow, and third-party APIs, then tie each one to an owner, data classification, and authentication method.
• Classify API entitlements and exposed data Document which identities, tokens, and service accounts can call each API and what objects or records they can reach.
• Replace perimeter-only protection with runtime governance Use behaviour-aware controls that can detect legitimate but abusive requests, especially where business logic is the attack path.
• Retire or re-approve shadow and neglected APIs Remove endpoints that no longer have a business owner, or force them through formal review before they remain exposed.

Key takeaways

• API sprawl turns incomplete discovery into an exposure problem because hidden interfaces often retain reachable data and functions after governance has moved on.
• The most damaging API weaknesses are often not broken logins but valid requests that are allowed to do too much, which makes runtime authorisation critical.
• For IAM and NHI programmes, API security has to include ownership, inventory accuracy, token scope, and behaviour-aware enforcement.

Key terms

• API sprawl: API sprawl is the uncontrolled growth of application programming interfaces across systems, teams, and environments. It creates duplicated endpoints, inconsistent authentication, weak ownership, and hidden data exposure. In security terms, API sprawl expands the attack surface, complicates inventory and governance, and makes policy enforcement, monitoring, and lifecycle control harder to sustain.
• 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.
• API Business Logic Attack: An API business logic attack abuses the intended workflow of an application by manipulating calls, sequences, or states in ways the system was not designed to allow. The attacker is not necessarily breaking syntax or authentication, but exploiting gaps in how the application handles valid actions.
• Runtime API Governance: Runtime API governance is the practice of evaluating API behaviour while requests are happening, not only during design or approval. It combines visibility, authorisation context, and anomaly detection so security teams can spot legitimate traffic that is behaving like abuse.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in the context of modern access control. It gives identity and security practitioners a common base for governing human and non-human access paths across the enterprise.