Because authentication proves identity, not permission to each object. An attacker or curious insider can be fully authenticated and still access another user’s record if the API does not bind the identity to object ownership or scope. Strong authentication reduces account misuse, but it does not replace per-object authorization logic.
Why object-level authorization fails even when sign-in is strong
Strong authentication answers a different question from object-level authorization. It tells the system who the caller is, but it does not by itself decide which record, file, tenant row, or transaction that caller may touch. That gap is where broken object-level authorization appears: the application accepts a valid session or token, then fails to verify that the requested object belongs to that identity or is covered by an explicit scope.
The failure is usually in the request path, not the login flow. A user can pass MFA, possess a trusted session, and still change an object identifier in the URL, body, or API call to reach data outside their entitlement. In well-designed systems, the access decision is bound to the object at the moment of retrieval or update, not inferred from the fact that the user is authenticated.
Authentication strength still matters because it reduces account takeover and lowers the chance that an outsider can act as a valid user. But it does not prevent abuse by a legitimate user, a compromised but authenticated session, or an internal actor with ordinary access. That is why broken object-level authorization is often an application design flaw rather than an identity assurance flaw. For API-specific guidance, see OWASP API Security Top 10 and the Authorisation Models Guide.
What the application must check on every object request
The core control is a server-side authorization decision that evaluates the specific object, not just the caller. That usually means confirming object ownership, tenant membership, role entitlement, attribute match, relationship path, or an explicit policy outcome before the object is returned or modified. If the application trusts client-supplied object IDs without that check, authentication becomes a gate to the front door, not a guardrail around each asset.
Effective designs avoid relying on obscurity, sequential IDs, or UI constraints. A hidden button or a hard-to-guess record number is not access control. The check has to be enforced where the data is read or changed, because that is the point at which the system knows exactly which object is in scope. This is the practical distinction between logging in and being authorised to act on a specific resource.
That principle also applies when access is indirect, such as through search results, export jobs, background APIs, or “view as” functions. If the object is reachable through any path, the same authorization rule must apply consistently. Otherwise, one code path becomes the bypass that exposes records despite strong authentication elsewhere. NIST SP 800-63 Digital Identity Guidelines reinforce the fact that strong authentication improves assurance, but it does not replace authorization design.
How attackers and insiders exploit the gap
BOLA is attractive because it often requires no exploit beyond a valid account or session. An attacker can enumerate object identifiers, replay a request with a different target, or abuse a feature that assumes the caller only ever touches their own data. Curious insiders can do the same thing accidentally or deliberately, which is why this issue shows up in both external breach scenarios and internal misuse.
The exposure is greatest when access is coarse at the login layer but fine at the data layer. A system may have excellent MFA, SSO, and device checks, yet still expose another customer’s invoice, case file, API object, or profile if the backend never rechecks entitlement. In other words, the compromise condition is not weak authentication, it is a missing authorization boundary at the object.
That is also why API tests and authorization reviews must include direct object access attempts, not just happy-path sign-in validation. Broken object-level authorization is often invisible to authentication metrics because users appear legitimate all the way through the session. A strong login can therefore coexist with a serious confidentiality or integrity failure.
Risk and Threat Considerations
BOLA creates a direct exposure path from one authenticated identity to another user’s data or actions. The risk is amplified in multi-tenant systems, customer-facing APIs, and administrative tools where object references are easy to guess, reuse, or tamper with. Because the caller is already authenticated, traditional login-focused controls can miss the abuse until records have been viewed or changed.
Failure mechanism: The backend authorizes the session but fails to bind that session to the specific object being requested, so a modified object identifier or weak ownership check exposes unauthorized records.
Impact: Unauthorized disclosure, tampering, and tenant crossover can occur even when MFA and other strong authentication controls are working as intended, which means the breach path sits inside the application trust model rather than at sign-in.
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 addresses the attack and risk surface, while NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | Directly addresses object-level access checks on API resources. |
| Recommendation — Enforce per-object authorization checks on every API request before returning or changing data. | ||
| NIST SP 800-63 | IA-5 — Authenticator Management | Strong authentication is relevant, but the issue remains authorization beyond sign-in. |
| Recommendation — Use strong authenticators, then pair them with separate authorization checks for each protected object. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The answer hinges on limiting what an authenticated subject can access. |
| IA-2 — Identification and Authentication (Organizational Users) | Authentication strength matters here, but it does not resolve object authorization. | |
| Recommendation — Restrict each subject to the minimum object access needed for the task. Authenticate users strongly, then verify object permissions independently. | ||
Practitioner Guidance
What to verify: Test every sensitive endpoint for direct object reference tampering, including read, update, delete, export, and admin workflows. Verify that the server enforces object-level checks independently of the client, UI, or gateway.
Common mistake: Treating “authenticated” as synonymous with “authorised.” If the access decision is not evaluated against the object itself, the control is incomplete no matter how strong the login process is.
Practitioner takeaway: Strong authentication reduces who can get into the system, but object-level authorization decides what that caller can actually do once inside. Build and test both layers separately, because one does not compensate for the other.
Related resources from NHI Mgmt Group
- What breaks when Broken Object Level Authorization is missed?
- How should security teams prevent broken object-level authorization in APIs?
- What is the difference between broken object level authorization and broken object property level authorization?
- Why do SAST and DAST still miss broken object-level authorisation?