OWASP API security risks expose gaps in access and inventory

At a glance

What this is: Salt maps the OWASP API Security Top 10 to the practical governance gaps that let API abuse persist, with broken object level authorization, broken authentication, and inventory blind spots emerging as the central risks.

Why it matters: IAM, application security, and API teams need to treat API inventory, authentication, and authorization as a single governance problem because weak control at any one layer expands business-logic abuse and exposure.

By the numbers:

• 95% of organizations experienced some form of API security incident, according to Salt.
• Broken object level authorization is represented in about 40% of all API attacks, according to Salt.

Context

APIs now sit at the centre of modern application delivery, which makes API access control, authentication, and inventory management operational security problems rather than abstract design concerns. When attack patterns target business logic and undocumented interfaces, the issue is governance drift: teams lose control over what exists, who can reach it, and what actions are exposed.

This article is best read as an application-security and identity-governance analysis of where API controls fail in practice. The identity bridge is real: broken authentication, unauthorized object access, and unsafe client consumption all depend on credential handling, entitlement scope, and lifecycle visibility across API-connected systems.

Key questions

Q: Where does API security fail when teams lose control of access and inventory?

A: API security fails when authentication, authorization, and inventory are treated as separate problems. If teams cannot see every live endpoint and cannot verify object-level permissions on each request, attackers can use valid tokens or exposed workflows to reach data and functions that were never meant to be broadly reachable.

Q: Why do APIs with weak object-level authorization create such a large risk?

A: Because the attack is usually just a parameter change, not a noisy exploit. If the handler does not verify ownership or permission for each object, an attacker can access another user’s data while the request still looks legitimate. That makes the flaw hard to spot in traffic and easy to miss unless code review and static analysis catch it first.

Q: What are the signs that API inventory management is failing in practice?

A: Common signs include endpoints that are reachable in production but missing from the inventory, documented APIs that no longer receive traffic, and versioned or deprecated APIs that remain accessible. Another warning is declining control coverage, where active APIs lack current logging, policy enforcement, or clear ownership. These symptoms show the inventory no longer reflects runtime reality.

Q: What should teams do when API abuse targets business logic instead of technical flaws?

A: Treat the workflow itself as the control point. Add usage thresholds, abuse detection, and entitlement checks around sensitive API flows so legitimate authentication does not become a free pass for automation, mass data access, or repeated state changes.

Technical breakdown

Broken object level authorization and the object boundary

Broken object level authorization happens when an API checks that a caller is authenticated but does not properly verify whether that caller is allowed to access the specific object requested. The result is insecure object references, where changing an identifier can expose records that should remain hidden. In practice, this is an authorization failure, not an authentication failure. It often survives normal testing because the endpoint appears to work correctly for valid users while quietly trusting object identifiers as if they were entitlement checks.

Practical implication: enforce object-level authorization checks on every request path that exposes customer, account, or workflow data.

Broken authentication, token abuse, and client trust

Broken authentication in API environments usually shows up as weak token handling, credential stuffing, or brute force against login and session flows. Once an attacker obtains a valid token or bypasses the authentication layer, downstream API controls often assume the caller is trustworthy and continue to expose sensitive functions. That is why API authentication is not just about the login step. It is about token integrity, replay resistance, expiry, and whether client-side integrations can be abused to impersonate legitimate use at scale.

Practical implication: harden token issuance, verification, expiry, and revocation controls around every API that accepts bearer credentials.

Improper inventory management and shadow API exposure

Improper inventory management means the organisation cannot reliably see all API versions, endpoints, and integrations that are still active. Older endpoints often stay reachable after new ones are deployed, which creates hidden attack surface and fragments policy enforcement. Without an accurate inventory, security teams cannot tell which interfaces are deprecated, which are externally exposed, or which ones still carry privileged business functions. This is a governance failure as much as a discovery failure because the control problem starts before runtime enforcement.

Practical implication: maintain a live inventory of APIs and retire undocumented or stale versions before they become unmanaged entry points.

Threat narrative

Attacker objective: The attacker aims to use legitimate-looking API interactions to access data, manipulate functions, and expand reach across business workflows without detection.

1. Entry begins when an attacker reaches an exposed API or a third-party client path and probes for weak authorization, authentication, or misconfigured endpoints.
2. Credential access or trust abuse follows when stolen tokens, brute force, or unsafe client handling lets the attacker act as a legitimate caller.
3. Escalation occurs as the attacker enumerates objects, manipulates business flows, or abuses undocumented API versions to reach data and functions beyond intended scope.
4. Impact is unauthorized access, sensitive data exposure, or business logic abuse at scale across connected applications.

Breaches seen in the wild

• 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.
• McHire default password flaw 2025: A forgotten test admin account with the password 123456 and an API flaw exposed McDonald's McHire applicant records to researchers.

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 governance debt is now an identity problem as much as an application problem: once an API estate loses reliable inventory and entitlement visibility, access control becomes partial and reactive. The article shows that broken authentication, BOLA, and unsafe consumption all rely on assumptions about who or what is calling the API. That means API security teams, IAM teams, and platform teams have to treat inventory, token scope, and authorization as one control plane.

Shadow API inventory is the named concept practitioners should track: undocumented or stale APIs create blind spots that attackers can use long after formal rollout cycles move on. The security failure is not only that an endpoint exists, but that the organisation no longer knows whether it should exist, who uses it, or what privileges it carries. Practitioners should treat inventory freshness as a security control, not an asset-management side task.

Business logic abuse is the practical edge of API risk: attackers increasingly win by using valid functions in invalid ways, not by forcing technical crashes. That changes the governance question from 'is the endpoint protected' to 'can the workflow be abused at scale without triggering controls'. For IAM and API leaders, the important conclusion is that authentication alone does not govern usage intent.

Low-and-slow API abuse weakens control assumptions that depend on noisy failures: if abuse is spread across time, rate limits, logging thresholds, and manual review queues may miss it until data has already moved. The article reinforces that detection has to understand objects, roles, and business flows, not just traffic volume. Teams should align API monitoring with authorization semantics, not only anomaly counts.

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: API Key Management Guide

What this signals

Shadow API inventory is now a governance failure, not just a discovery gap. When teams cannot confidently identify which interfaces are live, deprecated, or externally reachable, they cannot enforce consistent authorization or offboard old attack paths. That makes live inventory management a prerequisite for API security programmes, especially where access is spread across internal apps, partners, and automation.

API abuse is increasingly about valid workflows used at invalid speed or scale. That means API monitoring has to look at business intent, object scope, and client trust, not only request volume or error rates.

Teams that already manage machine credentials, token scope, and delegated access are better positioned to reduce API misuse because the same lifecycle controls apply to API callers and integration clients.

For practitioners

• Tighten object-level authorization checks Validate every request against the specific object and business action being accessed, not just the authenticated session or token.
• Harden API authentication flows Review token issuance, expiry, revocation, and replay resistance for the APIs that handle customer and internal workflow access.
• Build a live API inventory Track active, deprecated, and externally exposed APIs so undocumented versions can be retired before they become shadow attack paths.
• Constrain high-risk business flows Apply usage limits, step-up checks, and abuse monitoring to API functions that can move money, data, or privileged state at scale.

Key takeaways

• The article shows that API risk is not limited to vulnerable endpoints. It is also a governance problem involving authorization, authentication, and the ability to see every live API.
• Salt cites a 95% API incident rate and OWASP identifies broken object level authorization as responsible for about 40% of API attacks, which shows how common these failures remain.
• Practitioners should treat API inventory freshness, object-level authorization, and token governance as linked controls, not separate tasks.

Key terms

• 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.
• Broken Authentication: Broken authentication is a failure in how a system proves that a caller is who or what it claims to be. For APIs, that often means weak token handling, replayable credentials, or poor validation of delegated access, which allows unauthorised callers to act as trusted integrations.
• API Inventory Management: API Inventory Management is the practice of discovering, cataloging, and maintaining all application programming interfaces used across an organization. It records ownership, purpose, authentication method, data exposure, dependencies, and lifecycle status, so security and engineering teams can reduce shadow APIs, control access, and retire unused interfaces before they become risk.
• Sensitive Business Flow: A sensitive business flow is an application process where misuse can directly affect money, access, records, or trust. Examples include checkout, password reset, account creation, approvals, and privilege changes. These flows need stricter testing because small logic gaps can create major security and fraud exposure.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, and secrets management for practitioners who need to connect access control to identity lifecycle oversight.For identity, security, and platform teams, it provides a common governance lens for machine and human access across modern environments.