TL;DR: Broken Object Level Authorization remains the #1 API risk because valid tokens, clean syntax, and standard endpoints can still hide unauthorised access to accounts, records, and payment data, according to Upstream Security. The control failure is behavioural, not syntactic: perimeter tools that inspect requests in isolation cannot prove object-level authorisation.
At a glance
What this is: This article argues that BOLA turns legitimate-looking API traffic into a security blind spot by breaking the link between an authenticated caller and the object being requested.
Why it matters: IAM, API security, and NHI teams need this lens because object-level abuse can bypass request-centric controls even when authentication succeeds.
By the numbers:
- Broken Object Level Authorization remains ranked as the #1 risk in the OWASP API Security Top 10, according to Upstream Security.
Context
Broken Object Level Authorization, or BOLA, is an API access control failure where an authenticated request is allowed to reach an object that the caller should not be able to read or change. In this article, Upstream Security argues that the real perimeter is no longer a network boundary but the relationship between identity, object, and business context across API traffic.
That matters for identity programmes because the control failure is not whether a token is valid, but whether the caller is authorised for the specific object being referenced. As APIs, microservices, and autonomous agents increase the volume of machine-to-machine requests, request syntax becomes a poor proxy for trust.
The article uses BOLA to show why perimeter tools that inspect packets in isolation miss the broader governance problem. The practical issue is stateful authorisation: security teams need to understand who or what is acting, what object is being touched, and whether that interaction fits the expected business flow.
Key questions
Q: How should security teams prevent broken object-level authorization in APIs?
A: Security teams should enforce object-level checks on every request, not just after login or at the route layer. Combine authentication with ownership, tenancy, and data-scope validation so the API confirms the caller may access that specific record. Then add negative testing that tries ID swapping, cross-tenant access, and repeated enumeration against critical endpoints.
Q: Why do valid tokens still allow API data exposure?
A: A valid token proves that the caller authenticated, but it does not prove they are entitled to the specific object being requested. If the application accepts an object identifier without checking ownership or context, the request can succeed even when the access should fail. That is why BOLA often looks legitimate to perimeter tools.
Q: What are the signs that an API endpoint is vulnerable to BOLA?
A: Common signs include changing an ID in a request and receiving another user’s data, success when incrementing identifiers, or inconsistent authorization checks across similar endpoints. Teams should treat any endpoint that exposes database IDs, basket IDs, account IDs, or other object references as suspect until it has been tested for ownership enforcement and response consistency.
Q: What happens when API authorisation is based on a single business identifier?
A: A single business identifier can become a de facto password for records, which lets attackers or unauthorised users enumerate, retrieve, or modify data at scale. That creates exposure not only of PII but also of operational and financial records. The issue is not the identifier itself, but the missing secondary check around it.
Technical breakdown
Why valid API requests can still be unauthorised
BOLA exploits the gap between authentication and authorisation. A request can carry a valid token, hit a real endpoint, and use a clean schema while still referencing an object the caller should never access. The failure usually sits in object lookup or business logic, where the application checks that the user is logged in but not that the object belongs to that user or tenant. That is why BOLA is hard for syntax-based controls to see: the traffic is structurally correct, but semantically wrong.
Practical implication: verify object ownership and tenant scope at the application layer, not just the session or gateway layer.
Why stateless controls miss BOLA abuse
Traditional WAFs and rule-based API gateways are built to inspect individual requests, not to understand sequences of requests over time. BOLA abuse often looks normal one call at a time, especially when an attacker iterates across many object IDs at low volume or with distributed infrastructure. Without stateful behavioural context, a security stack sees legitimate-looking traffic rather than systematic enumeration or cross-object misuse. This is why object-level abuse often survives perimeter inspection even when inputs are perfectly formed.
Practical implication: correlate request patterns across objects, identities, and time to detect enumeration and cross-tenant access.
How business logic becomes the real attack surface
BOLA is a business logic flaw as much as an API flaw. The article’s airline example shows how a reservation code alone became enough to reveal PII, travel details, and partial payment data because the endpoint lacked secondary validation and returned too much information. In practice, this means the security boundary is not the API path itself but the business rule that decides whether a specific caller should see a specific object. Once that rule is weak, the endpoint becomes a data exposure mechanism.
Practical implication: test API endpoints for object-level access, secondary verification, and response minimisation before release.
Threat narrative
Attacker objective: The attacker wants to use legitimate-looking API traffic to access or modify objects that belong to other users and extract sensitive data at scale.
- Entry occurs through a legitimate API request that uses a valid endpoint and authentication token, so the traffic initially looks harmless to perimeter tools.
- Credential or token use is not enough to prevent abuse because the attacker manipulates object identifiers, allowing unauthorised access to records tied to other users or accounts.
- Escalation happens as the attacker iterates across many object IDs and harvests data at scale, turning a single broken authorisation check into large-scale exposure.
- Impact includes account takeover, fraud, operational abuse, and leakage of sensitive records, especially when the API returns more data than the request should reveal.
Breaches seen in the wild
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
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
BOLA is not just an API flaw, it is a trust failure in object-level identity. Authentication proves that a caller has presented a valid credential. It does not prove that the caller is entitled to a specific object, record, or business action. The practical consequence is that identity governance has to move from request legitimacy to object legitimacy.
Stateful authorisation is now the control that matters most. BOLA succeeds because many controls still evaluate requests in isolation, while the attack unfolds across object IDs and business flows. That makes the legitimate request problem a behavioural issue, not a syntactic one. Practitioners should treat object ownership, tenant context, and response scope as governance variables, not just application details.
Broken Object Level Authorization should be read as a form of access overreach, not merely insecure coding. The article shows that clean endpoints can still produce account compromise, fraud, and data exposure when the authorisation decision is too coarse. That aligns with OWASP API Security guidance and with Zero Trust assumptions that identity and request path alone are insufficient to authorise access.
API security and identity governance are converging around the same question: what is this identity allowed to do to this object right now? That question applies to human users, service accounts, and AI-enabled callers alike. The more enterprises expose business flows through APIs, the more object-level policy becomes part of identity governance rather than a separate engineering concern.
Legitimate request abuse is the new perimeter problem. As machine-to-machine integrations and autonomous agents increase, trust can no longer be inferred from a correct endpoint and a valid token. Practitioners need to recognise that the perimeter now lives in the decision logic that binds caller, object, and action together.
From our research library:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- Read next: NHI Authentication Guide
What this signals
Legitimate request abuse is becoming a governance problem, not just an API bug. Once machine-to-machine traffic carries business meaning, security teams need to think in terms of object entitlements, not just authenticated sessions. The control question is whether the caller should reach this object at this moment, which is closer to authorisation governance than perimeter defence.
API security and identity controls now meet at the object boundary. If object ownership, tenant scope, and response minimisation are not part of the design standard, BOLA will keep surfacing as a business logic failure even when authentication is sound. Teams should make object-level policy a first-class design requirement, especially for services consumed by AI systems and other non-human callers.
For practitioners
- Harden object-level authorization checks Enforce per-object and per-tenant authorisation in every sensitive API path, including read and write operations. Do not rely on endpoint access alone when a caller can swap identifiers.
- Minimise response payloads Return only the fields required for the business action, and suppress PII or payment data unless the caller has an explicit need for it.
- Add behavioural detection for enumeration Correlate repeated access to many object IDs across the same token, user, or IP pattern to spot brute-force harvesting and cross-record scraping.
- Test secondary verification paths Validate that sensitive retrieval flows require more than a single identifier, especially where reservation codes, account numbers, or session-linked objects can be guessed or enumerated.
Key takeaways
- BOLA survives because a request can be syntactically valid and still be authorised for the wrong object, which turns clean API traffic into a data exposure path.
- The article points to a large-scale reservation-system flaw where a single identifier exposed passenger data, travel details, and partial payment information.
- The decisive control is object-level authorisation with contextual checks, because perimeter inspection alone cannot prove that a caller may access a specific record.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | BOLA is the article's primary subject and the central API security failure. |
| Recommendation — Enforce object-level checks on every sensitive endpoint before data is returned or changed. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Overbroad object access shows least privilege is not being enforced at the application layer. |
| Recommendation — Apply least privilege to API callers and restrict object access to the minimum required scope. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on whether authorised identities are granted the right object permissions. |
| Recommendation — Review API entitlements so callers are authorised for specific objects, not just valid sessions. | ||
| CIS Controls v8 | CIS-5 — Account Management | The attack path depends on overly broad account-to-object access and weak governance of access scope. |
| Recommendation — Audit account access paths to sensitive objects and remove unnecessary reach from service and user accounts. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Valid credentials and large-scale harvesting are central to the abuse pattern described. |
| Recommendation — Map repeated object access to credential-enabled exfiltration and investigate high-volume enumeration. | ||
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.
- Object Level Authorization: Object level authorization controls access to individual records or resources, not just to an endpoint. It prevents users from reaching data that is technically available through a route but should remain hidden according to policy, role, or ownership. This is a key safeguard against broken access control.
- Stateful behavioural analysis: A detection approach that evaluates request patterns across time, identities, and objects instead of inspecting each call in isolation. It is essential when legitimate-looking API traffic can conceal enumeration, scraping, or cross-object misuse.
- Business logic attack surface: The set of application rules that determine how a system behaves when inputs are valid but the intended business decision is wrong. In BOLA cases, the attack surface is the logic that binds a caller to an object, not the transport layer.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 14, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org