API sprawl and shadow exposure are widening attack surface risk

At a glance

What this is: This analysis argues that API security failures are increasingly driven by hidden inventory, rapid change, and weak governance across shadow and external interfaces.

Why it matters: It matters to IAM practitioners because APIs often carry the same access and trust assumptions as identities, tokens, and service accounts, so poor governance expands both data exposure and control failure across NHI and human identity programmes.

By the numbers:

• 80% of internet traffic now routed through APIs.
• 64% of organizations have encountered an API attack or security breach in just the past year.
• Organizations underestimate how many APIs they have by 70% to 80%.

👉 Read Salt's analysis of API attack prevention, posture governance, and runtime protection

Context

API security has become an identity and governance problem as much as a network or application problem. When organisations cannot reliably inventory their APIs, they cannot reliably know which services are exposed, which credentials are in play, or which business flows can be reached through legitimate-looking requests.

The article’s central point is that traditional perimeter controls are not built to manage fast-changing API estates, especially where tokens, access keys, and service-to-service trust are embedded in the application layer. That intersects directly with NHI governance because API access often depends on non-human identities, delegated tokens, and other machine credentials that outlive the business context they were meant to protect.

Key questions

Q: What breaks when API security depends only on gateways and WAFs?

A: Teams lose visibility into business logic abuse, object-level authorisation failures, and low-and-slow reconnaissance that looks legitimate at the transaction layer. Gateways and WAFs still have value, but they cannot reliably judge intent, object ownership, or whether a valid session is being used outside its intended scope. That leaves a major gap in runtime control.

Q: Why do shadow AI tools create identity governance risk?

A: Shadow AI is risky because users often reach those tools through identities, browser sessions, or tokens that were never assessed for data handling or access scope. The issue is not just policy compliance. It is whether the identity path into the tool is authorised, reviewable, and reversible.

Q: How can security teams tell whether API risk controls are actually working?

A: Look for reduced abuse volume, fewer successful automated attacks, and clearer visibility into which non-human clients are making requests and why. If the control is effective, suspicious traffic should be slowed, challenged, or blocked before it reaches core systems, while legitimate integrations continue to function normally.

Q: Who is accountable when a public API leaks data through valid access?

A: Accountability usually spans application owners, IAM or platform teams, and security leadership, because the failure is shared between access design, endpoint logic, and monitoring. In regulated environments, the organisation must also be able to show that access controls and logging were proportionate to the sensitivity of the data involved.

Technical breakdown

Why API discovery fails in dynamic estates

APIs are not static assets. They are created in application releases, exposed through gateways, embedded in mobile clients, shared with partners, and sometimes left undocumented after teams move on. That is why inventory drift becomes the first governance failure: security teams cannot protect what they cannot enumerate. Shadow APIs, forgotten test endpoints, and third-party integrations all widen the effective attack surface. In practice, the problem is less about the existence of APIs and more about the lack of authoritative ownership and continuous discovery.

Practical implication: maintain a continuously updated API inventory tied to ownership, environment, and authentication method.

How API business logic attacks bypass conventional controls

Many API attacks do not rely on malformed packets or obvious exploit signatures. Instead, they abuse valid functions in ways the application designer did not intend, such as excessive data exposure, broken object-level authorisation, or token misuse across trusted workflows. CDN filters, WAAP rules, and schema checks can miss these attacks because the requests look legitimate. This is why API security needs runtime policy enforcement and behavioural detection, not just edge inspection. The core issue is trust placed in the request path rather than in the identity and purpose behind each call.

Practical implication: test for broken authorisation and data overexposure at runtime, not only at design time.

Why API security is inseparable from machine identity governance

APIs are frequently accessed by service accounts, application tokens, certificates, and other non-human identities. When those credentials are over-scoped, long-lived, or poorly rotated, an API issue becomes an identity governance issue. The article’s examples show how exposure often follows from weak control over who or what can call an API, not simply from code defects. For NHIMG readers, the key insight is that API security and NHI security overlap wherever a machine identity authorises data access, administrative action, or delegated trust.

Practical implication: align API protection with NHI lifecycle controls, including issuance, scope, rotation, and offboarding.

Threat narrative

Attacker objective: The attacker aims to exploit trusted API paths to extract data, abuse functions, or gain access that legitimate request checks fail to constrain.

1. Entry occurs when attackers find exposed, undocumented, or unauthenticated APIs that sit outside normal security review and monitoring.
2. Escalation follows when the API accepts valid-looking calls that bypass object-level authorisation, returning data or actions beyond the caller’s intended scope.
3. Impact is achieved through bulk data exposure, privacy violations, account takeover, or business logic abuse at scale.

NHI Mgmt Group analysis

API security is now a governance discipline, not a point-solution problem. The article is right to focus on discovery, posture, and runtime threat protection, because those are three distinct control layers. Security teams fail when they treat API protection as a gateway tuning exercise instead of a lifecycle problem that spans ownership, authentication, and data exposure. For identity programmes, that means API governance must be tied to entitlement management and machine identity oversight.

Shadow APIs create a visibility gap that mirrors NHI sprawl. Undocumented APIs behave like unmanaged service accounts: they persist, they drift, and they are often invisible to the people who would be accountable for them. Cloud identity sprawl: this is the condition where services, tokens, and interfaces accumulate faster than governance can track them. Practitioners should treat inventory reconciliation as an ongoing security control, not an occasional audit task.

Traditional inspection layers are not enough when valid requests are the attack path. WAAP, CDN, and schema controls can reduce noise, but they do not solve business logic abuse, excessive data exposure, or delegated trust abuse. That is why runtime authorisation and behavioural validation now matter more than perimeter confidence. The practical conclusion is that teams need controls that verify both the caller and the purpose of the call.

API risk and machine identity risk are converging faster than many programmes recognise. When a token or service identity can reach sensitive data through an API, the governance boundary is no longer the application alone. The same control weaknesses that create NHI exposure, long-lived credentials, weak scoping, and poor offboarding, also create API exposure. Organisations should therefore align API security with identity governance, not keep them in separate operating models.

What this signals

API programmes will increasingly be judged on whether they can prove inventory accuracy, not just report gateway coverage. The practical shift is toward continuous reconciliation between application releases, identity systems, and runtime telemetry, because hidden interfaces behave like hidden credentials: they are invisible until they are abused.

Authorised-request abuse: this is the governance gap where valid API calls still produce unsafe outcomes because authorisation is too coarse or too trusting. Security teams should expect more pressure to prove object-level controls, especially where APIs expose regulated data or are called by service accounts and delegated tokens. For a broader identity frame, review Top 10 NHI Issues and the The 52 NHI breaches Report.

The next maturity step is not more perimeter tooling alone. It is a joined-up operating model where API security, NHI governance, and application security share one view of ownership, access scope, and exposure so that runtime controls can actually match the pace of change.

For practitioners

• Build a continuously reconciled API inventory Map every internal, external, shadow, and partner-facing API to an owner, environment, authentication method, and data classification. Reconcile the inventory against CI/CD and gateway telemetry so undocumented endpoints do not remain outside governance.
• Enforce runtime authorisation on sensitive API paths Validate object-level access, data scope, and tenant boundaries at request time for every high-value API. Do not rely on edge filtering alone when valid requests can still expose sensitive records.
• Tie API access to NHI lifecycle controls Treat API keys, OAuth tokens, certificates, and service accounts as governed machine identities. Apply issuance approval, rotation, revocation, and offboarding controls so abandoned credentials do not keep calling live APIs.
• Test for business logic abuse, not just injection Add negative tests that try to overread objects, bypass tenant restrictions, reuse tokens across functions, and enumerate hidden fields. The goal is to confirm that legitimate requests cannot be repurposed into data extraction.

Key takeaways

• API security failures increasingly begin with inventory blind spots, not with sophisticated exploits.
• When valid requests can still expose data, runtime authorisation becomes more important than perimeter inspection alone.
• API governance and NHI governance are converging, because machine credentials often decide what an API can reveal or do.

Key terms

• 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.
• Business Logic Attack: A business logic attack abuses a system’s intended functions rather than exploiting a technical flaw in the code. In API security, the request can look valid while still causing overexposure, privilege misuse, or unauthorised actions that the application fails to constrain.
• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• Machine Identity: The digital identity of a machine, device, or workload — such as a server, container, or VM — used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.

What's in the full article

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

• A breakdown of API discovery and posture governance steps for teams that need to build an authoritative inventory.
• Examples of runtime threat patterns and business logic abuse cases that illustrate where gateway-only inspection falls short.
• Operational discussion of how to prioritise shadow APIs, third-party integrations, and high-risk data paths for remediation.
• Implementation context for teams aligning API controls with access governance and machine identity lifecycle management.

👉 Salt's full article covers the breach examples, control gaps, and API security actions in more 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 gives practitioners a common framework for connecting identity controls to broader access and exposure risks.