Topic starter
02/08/2026 11:32 am
TL;DR: Broken object level authorization remains a leading API attack path because attackers can alter object IDs in requests and reach data, actions, or account flows they should not control, according to Salt. Static and signature-based tools often miss the flaw because the control failure sits in application business logic, not pattern matching.
Editorial analysis by NHI Mgmt Group, based on content published by Salt: “API1:2023 Broken Object Level Authorization (BOLA)”.
By the numbers:
- BOLA vulnerabilities are present in around 40% of all API attacks, according to Salt.
Key questions
Q: What breaks when function-level authorization is missing in APIs?
A: The application can allow authenticated users to perform actions they were never meant to control.
Q: Why does BOLA create such high risk even when authentication works?
A: Authentication only proves the caller has a valid session.
Q: How do security teams find object-level authorization failures?
A: They need to test every method and route variant against the same record under different users, tenants, and roles.
Practitioner guidance
- Embed object-level authorization in every protected API endpoint Validate the authenticated principal against the specific object being requested or modified, not just against the session or route.
- Recheck entitlement on every sensitive workflow step Apply a fresh authorization decision for each read, write, reset, or transfer action so multi-step flows cannot reuse stale permission context.
- Remove predictable object identifiers where feasible Reduce enumerability by replacing sequential or guessable object references with opaque identifiers, while still enforcing server-side checks.
Bottom line: BOLA is an authorization failure in the application layer, not a failure of login, and it appears when APIs trust client-supplied object IDs.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:47 pm
Object-level authorization is the real control boundary in API security: authentication proves who is calling, but BOLA proves that identity alone is not enough. When business logic relies on client-supplied object IDs, the application is effectively outsourcing authorization to the requester. Practitioners should treat object-level checks as part of the identity decision, not a separate application detail.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: When should teams prioritise continuous authorization over gateway filtering?
A: Prioritise continuous authorization whenever an API endpoint can read, update, reset, or transfer a specific object. Gateway filtering is useful for reduction of noise, but it cannot determine whether the authenticated user should access that object at that moment.
👉 Read our full editorial: Broken object level authorization is still a leading API attack path