Broken object level authorization is still a leading API attack path

At a glance

What this is: This is an analysis of broken object level authorization in APIs, showing how ID manipulation can bypass object checks and expose data or accounts.

Why it matters: It matters because API access control failures can undermine human IAM, delegated access, and any NHI-backed service flow that trusts object IDs more than verified authorisation state.

By the numbers:

• BOLA vulnerabilities are present in around 40% of all API attacks and are listed as the number one threat to API security in the OWASP API Security Top 10.

👉 Read Salt's analysis of broken object level authorisation in APIs

Context

Broken object level authorization, or BOLA, is a failure in application access control where the server trusts an object identifier supplied by the client instead of verifying whether the authenticated user can act on that object. In practice, that means APIs can return, change, or delete records simply because the caller can guess or alter an ID. For identity and application security teams, the key issue is that authentication can succeed while authorisation silently fails at the object layer.

This pattern is especially relevant to IAM and NHI governance because service accounts, tokens, and API-driven workflows often rely on object references passed through requests, queues, and integrations. If the backend logic does not continuously check the caller’s authority against the requested object, the system creates an access path that bypasses intended identity controls. That makes BOLA a governance problem as much as a coding flaw.

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 BOLA vulnerabilities matter even when authentication is strong?

A: Authentication only proves who or what is calling the API. BOLA appears when the application fails to verify whether that caller may act on the specific object referenced in the request. Strong login controls do not prevent a user or token from re-targeting another record if the backend trusts the wrong identifier.

Q: What do teams get wrong about API gateways and WAFs stopping BOLA?

A: They assume perimeter tools can understand application meaning. In reality, these controls often see only request patterns, not whether a cookie value, body field, or query parameter should match the authenticated identity. BOLA requires contextual authorisation, not just signature matching.

Q: How should teams respond when BOLA affects password resets or transfers?

A: Treat those paths as privileged identity workflows. Add step-up verification, stricter object binding, and transaction monitoring before the reset or transfer completes, because object substitution in these flows can lead directly to account takeover or unauthorised movement of funds.

Technical breakdown

Why object IDs become an authorisation bypass

BOLA happens when the application uses a client-supplied identifier, such as userId or accountId, to select a record and only partially validates who is asking. The flaw is not the identifier itself, but the absence of a server-side binding between the authenticated principal and the object being requested. If sequential IDs, predictable tokens, or poor lookup logic are present, attackers can enumerate objects at scale. The result is not always obvious compromise. It is often quiet read access to records the caller should never see, followed by selective modification or deletion.

Practical implication: every endpoint that accepts an object identifier needs server-side object ownership checks, not just session authentication.

Why WAFs and API gateways miss BOLA

Traditional perimeter tools are built to recognise known attack signatures or obvious anomalies, not to understand whether two values in the same transaction should match. A WAF can see a request, but it usually cannot infer that the userId in a cookie must correspond to the userId in a query string or body field. That is why BOLA often passes through pattern-based controls. Detecting it requires contextual baselining of API behaviour, correlation across requests, and knowledge of application business logic rather than generic payload inspection.

Practical implication: supplement perimeter filtering with API runtime analysis that compares identity context, request fields, and object access patterns.

How BOLA can turn into account takeover

BOLA is not limited to data exposure. In workflows such as password reset, profile changes, or mobile app operations, object manipulation can redirect control to an account the attacker does not own. The article’s examples show that once an attacker can reference another user’s object, they may be able to harvest tokens, alter account attributes, or complete a reset flow against the wrong identity. In identity terms, the object becomes the control point, and the failure is a missing trust check at the point of action.

Practical implication: treat password reset, profile update, and token-handling endpoints as high-risk identity flows and test them for object substitution.

Threat narrative

Attacker objective: The attacker aims to access or alter records belonging to another user and, where possible, extend that access into account takeover or financial fraud.

1. Entry occurs when the attacker reaches an API endpoint that accepts a user-controlled object identifier and uses it to fetch or modify a record.
2. Credential or object abuse follows when the attacker changes the identifier in the request and the server fails to verify that the authenticated user is authorised for that object.
3. Impact occurs when the attacker reads, modifies, deletes, or transfers data, and in some cases escalates to account takeover or fraudulent transaction execution.

NHI Mgmt Group analysis

BOLA is an object-level trust failure, not just a coding mistake. The core issue is that the application trusts the wrong thing, namely the client-supplied object reference, rather than the authenticated identity’s authority over that object. That makes the flaw systemic across APIs, mobile backends, and service-to-service flows. For practitioners, the lesson is that authorisation must be evaluated against each requested object, every time.

Object reference drift: is the governance gap that lets authenticated sessions cross into unauthorised data. This article shows how easy it is for identity state and object state to diverge when the backend does not bind them together. In IAM terms, authentication is present but object authorisation is not continuously enforced. That means teams need to treat object lookup paths as control points, not harmless data fields.

API security needs identity context, not just traffic inspection. WAFs, gateways, and signature-based tools are weak against logic flaws because they do not know what a request should mean inside the application. Continuous authorisation checks, request correlation, and behaviour baselining are therefore the relevant control pattern. For identity programmes, this is where application security and access governance meet.

BOLA becomes more dangerous when APIs front privileged workflows. The article’s examples show that object manipulation can reach beyond data disclosure into resets, transfers, and token harvesting. That makes BOLA a privilege and fraud problem as well as an AppSec issue. Practitioners should treat any API that can move money, reset credentials, or change entitlements as a privileged path requiring stricter verification.

Least privilege alone is not enough if object boundaries are weak. Even well-scoped access can fail when an application allows a caller to re-target the object of a permitted action. That is why object-level controls must sit beside role checks, session controls, and step-up verification where the action is sensitive. For teams, the practical conclusion is to test authorisation at the object layer, not only at login.

What this signals

Object-level authorisation is becoming a hidden control plane issue. As APIs proliferate, teams can no longer assume that login success or token validity equals object trust. The practical shift is toward runtime validation of who can act on what, which is a governance problem that sits between IAM, application security, and fraud monitoring.

BOLA creates a verification trust gap that conventional edge controls do not close. The more business logic moves into APIs, the more the application itself must enforce identity-to-object binding. For practitioners, that means measuring whether sensitive endpoints still accept mutable object references and whether those paths are covered by continuous checks, not only pre-deployment testing.

For NHI-heavy environments, the same pattern applies to service identities and delegated flows. When machine accounts call APIs on behalf of users or other systems, weak object binding can let one workload act on another workload’s records. That is why object-level controls should be reviewed alongside secrets handling and entitlement scope, not treated as a separate AppSec issue.

For practitioners

• Add object-level authorisation checks to every ID-bearing endpoint Verify, on the server side, that the authenticated principal is allowed to access the specific object referenced in the request before any read, update, delete, or transfer action runs.
• Test for ID substitution across high-risk flows Focus penetration testing and abuse-case testing on profile changes, password resets, account transfers, entitlement changes, and any endpoint where a userId, accountId, or similar field can be altered.
• Instrument runtime baselines for API object access Build monitoring that correlates identity context, request parameters, and expected object relationships so anomalous cross-object access can be flagged at runtime.
• Harden sensitive identity and financial workflows Require additional verification before reset, transfer, or account-mutation actions, especially where APIs expose sequential identifiers or where rate limits are weak.

Key takeaways

• BOLA is an authorisation failure at the object layer, where the server trusts a client-supplied identifier more than the authenticated identity.
• The article cites BOLA in around 40% of API attacks, showing that this is a common abuse pattern rather than a niche flaw.
• The right control is continuous object-level verification paired with runtime context, especially on resets, transfers, and other privileged API actions.

Key terms

• Broken Object Level Authorization: A control failure where an application lets a caller access or change an object without proving that the caller is allowed to act on that specific record. The flaw sits in the authorisation logic, not the login layer, and often appears when APIs trust user-supplied IDs too much.
• 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.
• API Context Baseline: A behavioural reference point showing what normal API use looks like across identities, parameters, and object relationships. Security teams use it to spot requests that are syntactically valid but semantically wrong, such as a caller reaching an object outside its normal authority.

What's in the full article

Salt's full article covers the operational detail this post intentionally leaves for the source:

• The request and response patterns used to expose BOLA in real API traffic.
• The article's own examples of userId manipulation across read and transfer flows.
• Why static and dynamic testing miss these logic flaws in practice.
• The platform-side context model Salt describes for detecting abnormal object access.

👉 Salt's full article covers BOLA examples, attack mechanics, and detection limits in more operational detail.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners building durable identity controls across human, machine, and delegated access.