Notifications
Clear all
Topic starter
02/08/2026 11:32 am
TL;DR: Broken object level authorization lets attackers change object IDs in API requests and access, modify, or exfiltrate data they should not reach, with the article noting it appears in around 40% of API attacks and can even enable account takeover. The control gap is not detection alone but continuous object-level authorisation tied to session context and business logic.
NHIMG editorial — based on content published by Salt: broken object level authorization in APIs
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.
Questions worth separating out
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.
Q: Why do BOLA vulnerabilities matter even when authentication is strong?
A: Authentication only proves who or what is calling the API.
Q: What do teams get wrong about API gateways and WAFs stopping BOLA?
A: They assume perimeter tools can understand application meaning.
Practitioner guidance
- 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.
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.
👉 Read Salt's analysis of broken object level authorisation in APIs →
BOLA in APIs: what IAM and AppSec teams need to fix now?
Explore further
02/08/2026 12:47 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Broken object level authorization is still a leading API attack path
