OWASP API security risks expose gaps in access and inventory

At a glance

What this is: This is a Salt analysis of the OWASP API Security Top 10 and the main API risk patterns it captures in modern applications.

Why it matters: It matters because API abuse often sits at the intersection of application security, access control, and identity governance, especially where tokens, authentication, and third-party consumption are involved.

By the numbers:

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

👉 Read Salt's analysis of the OWASP API Security Top 10 and API attack patterns

Context

APIs have become a primary business interface, which makes authorization failures and weak inventory control security issues, not just development defects. The article’s primary identity angle is access governance: API tokens, service-to-service authentication, and third-party consumption all create policy enforcement problems that conventional perimeter controls do not solve well.

OWASP’s API Security Top 10 is useful because it turns a sprawling attack surface into a governance checklist for engineering and security teams. The article also reflects a broader shift in attack behaviour: adversaries are targeting business logic, automation paths, and control gaps that sit between application security and identity management.

Key questions

Q: How should security teams implement function-level authorization in APIs?

A: Security teams should enforce authorization on the server side for every sensitive function, not just at the UI or gateway layer. That means mapping roles to specific actions, validating the caller’s entitlement at execution time, and testing whether a valid session can still reach restricted methods, parameters, or hidden endpoints.

Q: Why do API keys and tokens need non-human identity governance?

A: Because they behave like access-bearing identities, not static configuration values. If they are long-lived, over-scoped, or shared across workloads, they can be reused by attackers exactly as legitimate systems use them. Governance should therefore cover ownership, scope, rotation, monitoring, and retirement.

Q: What breaks when organisations do not maintain a complete API inventory?

A: Unknown and stale endpoints stay reachable, which means security controls, logging, and retirement processes miss part of the attack surface. Teams lose sight of which versions still accept credentials, which test interfaces remain exposed, and which business flows have never been formally reviewed.

Q: How do teams reduce abuse without slowing legitimate API traffic?

A: Use rate limits, quotas, and throttling differently for authentication, read, and write operations. Then combine those controls with logging and alerting so you can distinguish normal bursts from brute force or scraping. The goal is not just to block volume, but to make abuse visible and containable.

Technical breakdown

Broken object level authorization and API access control

Broken object level authorization, or BOLA, occurs when an API exposes objects such as customer records, orders, or accounts without verifying whether the caller is entitled to that specific object. Authentication may still succeed, which is why BOLA often slips past simple login-focused controls. The failure is not at identity proofing, but at authorization enforcement at the object layer. In identity terms, this is a policy binding problem: the system knows who the caller is, but not what that caller should be allowed to reach. This makes BOLA one of the most common ways APIs leak data even when authentication appears intact.

Practical implication: enforce object-level authorization checks on every request path, not just at session entry.

Broken authentication, tokens, and API client trust

Broken authentication in APIs typically involves stolen tokens, weak credential handling, or acceptance of forged or replayed credentials. APIs often trust machine-to-machine callers more than they should, especially when tokens are long-lived or reused across services and environments. In practice, this becomes an NHI governance issue because API keys and bearer tokens function as non-human identities with access rights that can outlive their intended purpose. When those credentials are not tightly scoped, rotated, and monitored, the API layer becomes a convenient entry point for credential stuffing, replay, and impersonation.

Practical implication: bind API credentials to narrow scopes, short lifetimes, and continuous validation.

Improper inventory management and unknown API exposure

Improper inventory management means security teams do not have a complete, current view of which APIs exist, which versions are active, and which endpoints are still reachable. That creates blind spots for decommissioned services, forgotten test interfaces, and older versions that remain exposed after application change. The security failure is governance before it is technical control: if teams cannot enumerate the API estate, they cannot set meaningful policy, logging, or retirement rules. This is where API security overlaps with broader attack surface management and identity oversight, because forgotten APIs often still accept valid credentials.

Practical implication: maintain a live API inventory and retire unknown or unused endpoints on a defined schedule.

Threat narrative

Attacker objective: The attacker’s objective is to turn trusted API access into unauthorized data access, manipulation, or business process abuse.

1. Entry begins when attackers target exposed APIs through stolen tokens, credential stuffing, or direct requests against undocumented endpoints.
2. Escalation occurs when authorization checks are weak, allowing access to objects, functions, or business flows outside the caller’s intended scope.
3. Impact follows through data exposure, unauthorized transactions, or automated abuse of sensitive API-driven processes.

NHI Mgmt Group analysis

BOLA is an authorization failure, not an authentication failure. The industry often over-focuses on login strength, while the real weakness sits in object-level policy enforcement. APIs can authenticate a caller correctly and still leak records if the service does not verify per-object entitlement. For identity teams, this is a reminder that access control has to extend into the application layer, not stop at the token boundary.

API credentials behave like non-human identities and should be governed that way. Bearer tokens, API keys, and service credentials are not just secrets, they are access-bearing identities with lifecycle risk. If they are long-lived, over-scoped, or reused across environments, the attacker does not need to break the app, only inherit the trust attached to the credential. That makes NHI governance a direct control requirement, not an adjacent concern.

Improper inventory management creates invisible security debt. Unknown APIs, stale versions, and forgotten endpoints expand attack surface faster than most teams can review it. This is not only a discovery issue but a policy enforcement issue, because teams cannot secure what they cannot enumerate. The named concept here is API shadow inventory: endpoints that remain live and reachable after the organisation has lost operational awareness of them. Practitioners should treat inventory completeness as a prerequisite for any meaningful API security programme.

Unrestricted business flows show that attackers increasingly target process abuse rather than code defects. When an API exposes an automation path for orders, refunds, account changes, or content requests, attackers can amplify legitimate use into abuse at scale. That shifts the security question from whether an endpoint is reachable to whether the underlying business action is safe under automation. Practitioners should align API controls with business impact, not just technical exposure.

Low-and-slow API attacks demand governance that survives beyond point detections. The article’s threat model fits modern adversaries who avoid noisy exploitation and instead probe for weak object checks, stale endpoints, and excessive trust in clients. That means the control set must combine identity, inventory, rate limiting, and logging. Security teams should assume that an attacker who can blend into normal API traffic will eventually find the weakest policy boundary.

What this signals

API shadow inventory is becoming a governance problem as much as a discovery problem. When teams cannot see every live endpoint and version, they cannot reliably control access, logging, or retirement. That gap is especially relevant where APIs are backed by service identities or bearer tokens, because hidden endpoints still honour valid credentials and can quietly extend blast radius.

For identity programmes, API security is increasingly part of workload identity governance, not a separate application concern. The practical signal is simple: if API authentication succeeds without strong object-level checks and short-lived credential controls, the identity layer is being trusted beyond its safe boundary. Teams should align API telemetry with entitlement review, secrets lifecycle, and workload ownership.

For practitioners

• Enforce object-level authorization everywhere Require every API request to re-check object entitlement against caller context, role, and policy rather than trusting session success alone. Focus on high-value records and multi-tenant access paths first.
• Treat API credentials as managed identities Inventory API keys, bearer tokens, and service credentials as non-human identities with owners, scopes, rotation rules, and expiry dates. Remove broad sharing and eliminate credentials that cannot be traced to a specific workload.
• Build a live API inventory Continuously discover endpoints, map versions, and flag unmanaged or deprecated APIs that still accept traffic or credentials. Tie inventory findings to retirement workflows and risk acceptance decisions.
• Apply business-flow controls to automated abuse paths Rate-limit sensitive API actions, add anomaly detection for repeated business events, and require compensating controls where automation can cause financial or operational harm.
• Correlate API logs with identity telemetry Link API authentication events, token usage, and workload identity signals so teams can spot token replay, impossible usage patterns, and cross-environment credential reuse.

Key takeaways

• API risk is driven by authorization gaps, credential abuse, and incomplete inventory, not just exposed endpoints.
• The evidence points to widespread incident exposure and persistent developer control gaps around secrets and API governance.
• Practitioners need to manage API credentials as non-human identities and treat inventory completeness as a control requirement.

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 Function Level Authorization: A failure where an API allows a caller to invoke a function reserved for a more privileged role. The problem appears when the API checks whether a user is logged in but not whether they are allowed to perform that action. It is a privilege boundary failure at the application control layer.
• API consumer inventory: A complete register of the applications, partners, service accounts, and automation clients that use an API. It is the starting point for access review because you cannot govern lifecycle, entitlement scope, or offboarding if you cannot name every consumer identity.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

What's in the full article

Salt's full article covers the OWASP API Security Top 10 detail this post intentionally leaves for the source:

• Walkthrough of all ten OWASP API risks, including how each category changes implementation priorities.
• Salt's framing of discovery, posture governance, and runtime threat protection for API environments.
• Practical examples of how BOLA, BFLA, SSRF, and unsafe consumption show up in real application stacks.
• The source article's own summary of why API security needs both development and security ownership.

👉 Salt's full article expands on each OWASP API risk and the control gaps it exposes

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners connect identity controls to the operational realities of service accounts, tokens, and machine access.