TL;DR: API traffic has grown 168% in the past year and 94% of companies report an API security problem in production, according to the State of API Security report Q3 2022, underscoring how quickly shadow APIs, business logic abuse, and authorization flaws expand attack surface. Traditional WAF and gateway controls are not enough when attacker activity looks like normal API traffic and machine-to-machine access bypasses assumptions built for human workflows.
At a glance
What this is: This is an analysis of why API security programmes fail when they depend on inventories, proxies, and signatures that cannot keep pace with fast-changing API estates.
Why it matters: It matters to IAM and security teams because API access, machine credentials, and authorisation logic sit at the intersection of identity, runtime control, and data exposure.
By the numbers:
- API traffic has grown 168% in the past year.
- 94% of companies reporting they have suffered an API security problem in production in the same period.
👉 Read Salt's analysis of API security visibility gaps and runtime controls
Context
API security is no longer just an application-layer issue. As API estates expand, organisations struggle to maintain an accurate inventory, enforce consistent access control, and detect abusive behaviour that blends into normal traffic. The primary governance gap is visibility, followed by weak runtime detection and overreliance on controls that were built for web sessions rather than machine-to-machine access.
This is where identity intersects with API security. APIs are authenticated by keys, tokens, session cookies, and service credentials, which means broken authorisation or unmanaged machine identity can become the fastest route from normal usage to data exposure. For practitioners, the question is not whether to use controls like gateways or shift-left testing, but whether those controls can still see the real attack surface as the environment changes.
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 APIs create more risk than normal monitored traffic?
A: Shadow APIs bypass the assumptions behind monitoring because the organisation does not know they exist, so no one has reliably reviewed their authentication, authorisation, or data exposure. That makes them especially dangerous in fast-moving environments where service accounts and tokens may be created alongside the endpoint but never formally governed.
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 API access controls fail?
A: Accountability should sit with the team that owns the API lifecycle, including design, deployment, access scope, and retirement. Security may set policy, but engineering and product owners must own the data and behaviour exposed by each interface. Without explicit ownership, APIs tend to outlive their controls and inherit stale permissions.
Technical breakdown
API discovery and the shadow API problem
An API security programme begins with discovery, because undocumented, deprecated, and externally exposed APIs create blind spots that attackers can enumerate before defenders do. Shadow APIs are live interfaces that never made it into governance records, while zombie APIs are old endpoints that remain reachable after teams think they are retired. Both expand the attack surface and often carry stale permissions or exposed data paths. Continuous discovery is therefore not a reporting exercise but a control plane for risk reduction, especially in environments where DevOps delivery outpaces documentation discipline.
Practical implication: maintain continuous API inventory coverage across internal, partner, and customer-facing services rather than relying on periodic manual reviews.
Why WAFs and API gateways miss business logic abuse
WAFs and gateways are useful for known patterns, but they struggle when the attack is not a payload signature problem. Broken object level authorization, or BOLA, happens when a requester is authenticated but allowed to access another object's data because object ownership checks are missing or inconsistent. A proxy can see the request, but it cannot infer intent or business context well enough to decide whether the action is legitimate. That is why modern API attacks often bypass perimeter-style controls while still appearing normal at the transaction level.
Practical implication: pair perimeter controls with object-level authorisation testing and runtime behaviour analysis that can inspect context, not just syntax.
Machine-to-machine trust and zero trust architecture limits
Zero trust architecture assumes every request should be verified, but APIs need to exchange data continuously and at scale, often between services that have no human in the loop. In practice, machine-to-machine communication depends on tokens, keys, certificates, and metadata that may be incomplete, stale, or mislabelled. IP-based policy and manual step-up checks do not map cleanly onto ephemeral workloads, serverless components, or direct API calls. The result is a trust model that can authenticate the channel but still fail to govern the object, action, or machine identity behind it.
Practical implication: govern API access with machine identity, metadata quality, and context-aware authorisation instead of assuming ZTNA alone can secure service-to-service calls.
Threat narrative
Attacker objective: The attacker aims to turn legitimate API access into unauthorized data access or business logic abuse without triggering signature-based detection.
- Entry typically begins with reconnaissance against public, partner-facing, or poorly catalogued APIs, where attackers learn endpoints, object patterns, and business logic by observing normal traffic.
- Escalation occurs when the attacker reuses valid sessions, API keys, or tokens and then abuses missing object-level checks to access data or functions outside the intended scope.
- Impact follows when abused APIs expose sensitive records, allow unauthorized actions, or become a foothold for broader cloud and application compromise.
NHI Mgmt Group analysis
API sprawl has become an identity problem as much as an application problem. When APIs change faster than governance records, teams lose visibility into who or what is allowed to call them. That creates a control gap across machine identity, authorisation, and decommissioning. The practical conclusion is that API security must be governed as an identity and lifecycle issue, not just as traffic monitoring.
Business logic abuse is the failure mode that legacy perimeter tools are least equipped to handle. Signature-based inspection works for known malicious patterns, but it does not understand whether a legitimate request is being used in an illegitimate way. That is why broken object level authorization remains such a persistent issue. Practitioners should treat context-aware authorisation as a first-class control objective.
Shadow APIs and zombie APIs are really unowned access paths. The named concept here is inventory drift, where the live API estate and the documented estate no longer match. That mismatch creates stale permissions, forgotten endpoints, and unreviewed data exposure points. For security leaders, the governance problem is ownership continuity across the API lifecycle.
Zero trust architecture does not remove the need for API-specific identity governance. Machine-to-machine communication still depends on trustworthy metadata, authenticators, and scoped access decisions. If those inputs are stale or incomplete, zero trust becomes a transport assumption rather than an enforcement model. The practitioner takeaway is to verify machine identity quality before assuming the policy layer is doing real work.
What this signals
Inventory drift will become a recurring programme risk as APIs, tokens, and service endpoints multiply faster than governance teams can reconcile ownership. That means security leaders need unified control points for discovery, access scope, and retirement, not separate reviews that treat each API as a static asset.
The practical signal for IAM and platform teams is that machine identity governance now sits inside application security decisions. If tokens, keys, and certificates are not tied to explicit ownership and lifecycle controls, runtime protections will continue to lag behind the actual exposure surface.
Teams that want to reduce API risk should align behavioural monitoring with identity lifecycle management and the NIST Cybersecurity Framework 2.0. Doing so creates a better link between policy, detection, and recovery when APIs change faster than documentation.
For practitioners
- Implement continuous API discovery Build automated discovery for internal, external, partner, shadow, and zombie APIs, and reconcile the results against service ownership records and retirement workflows.
- Test object-level authorisation continuously Add runtime checks and negative testing for broken object level authorization, including tenant-to-tenant access, object ID manipulation, and privilege reuse across workflows.
- Map machine credentials to API ownership Tie tokens, keys, certificates, and service accounts to named business owners so every API call path has a human accountable for scope, rotation, and retirement.
- Augment gateway controls with behavioural baselines Use behavioural baselines to detect low and slow reconnaissance, unusual object traversal, and repeated auth successes that do not match normal application patterns.
Key takeaways
- API security fails when defenders cannot see the full estate, including shadow and zombie endpoints.
- Legacy perimeter controls miss the business logic and object-level abuse that drive many modern API attacks.
- Practitioners need lifecycle ownership, contextual runtime detection, and machine identity governance to close the gap.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0007 , Discovery; TA0006 , Credential Access; TA0001 , Initial Access | API reconnaissance, credential reuse, and unauthorised access map to the attack pattern in this article. |
| NIST CSF 2.0 | PR.AC-4 | API authorisation and scoped access are central to the visibility and control gap described here. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege is directly challenged by overbroad API access and object-level authorisation failures. |
| CIS Controls v8 | CIS-5 , Account Management | Machine credentials and service ownership need the same lifecycle control as human accounts. |
| NIST Zero Trust (SP 800-207) | The article directly challenges zero trust assumptions in machine-to-machine API traffic. |
Map API abuse paths to discovery and credential-access tactics, then add detection for enumeration and token misuse.
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.
- 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.
- 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 article covers the operational detail this post intentionally leaves for the source:
- A structured checklist for API discovery across internal, partner, and customer-facing services.
- The vendor's explanation of why BOLA evades WAF and gateway controls in practice.
- More detail on shift-left testing limits and when runtime analysis becomes essential.
- The source article's breakdown of accountability across development, application, and security teams.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle practices. It helps security practitioners connect API-style machine access problems to the controls that govern credentials and access scope.
Published by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
