VenedyPer the OWASP page (rating table): API Specific. Exploitability Easy; Prevalence Widespread; Detectability Easy; Technical Impact Moderate; Business Impact Business Specific. Threat agents/attack vectors are marked as API Specific.
How the attack works
Object level authorization is an access control that, per OWASP, is usually implemented at the code level and ensures that a user only accesses the objects they have permissions for. Every API endpoint that receives an object ID and performs an action on it should implement object-level authorization checks that validate that the logged-in user is allowed to perform the requested action on the requested object.
Per OWASP, the problem is extremely common in API-based applications, because the server component usually doesn't fully track the client's state and instead relies on parameters like object IDs sent by the client to decide which objects are accessible. Object IDs (sequential integers, UUIDs, or arbitrary strings) are easy to identify and manipulate in the request target (path or query parameter), in headers, or in the request payload.
Per OWASP, it is by design that the user has access to the vulnerable endpoint/function itself, the violation happens at the object level through manipulation of the ID. (If an attacker instead gains access to an endpoint/function they shouldn't be able to call at all, that's Broken Function Level Authorization (BFLA), not BOLA.)
Merely comparing the user ID of the current session, e.g. extracted from the JWT token, with the vulnerable ID parameter is, per OWASP, not a sufficient solution and covers only a small fraction of cases.
Authenticated, yes, but object-level permission is never checked.
Example
OWASP scenario 1 (e-commerce platform): an e-commerce platform for online shops offers an overview page with revenue charts for the hosted shops.
- The attacker inspects the browser requests and identifies the API endpoints that serve as the data source for the charts, including the pattern:
GET /shops/{shopName}/revenue_data.json - Via a different API endpoint, the attacker obtains the list of all hosted shop names.
- With a simple script, they substitute
{shopName}in the URL one after another with the names from the list. - The attacker thereby gains access to the sales data of thousands of e-commerce shops.
Note: the OWASP page doesn't explicitly state in scenario 1 that the missing check is whether the user owns the shop, this is the implicit vulnerability. The page lists two further scenarios: remotely controlled vehicles via VIN, and deleting other users' documents via a GraphQL mutation.
Impact
Per OWASP, unauthorized access to other users' objects can lead to data disclosure to unauthorized parties, data loss, or data manipulation. Under certain circumstances, unauthorized object access can also lead to full account takeover.
Per OWASP, flaws in this mechanism typically lead to unauthorized disclosure, modification, or destruction of all data. Per OWASP, the business impact is business specific, it depends on what data and functions are reachable through the affected objects (e.g. revenue data, vehicle control, documents).
How to protect against it
- Implement a proper authorization mechanism that relies on user policies and the user hierarchy.
- Use the authorization mechanism in every function that uses client input to access a record in the database, checking whether the logged-in user is allowed to perform the requested action on the record.
- Prefer using random and unpredictable values (GUIDs) as record IDs.
- Write tests that evaluate the vulnerability of the authorization mechanism; don't ship changes that make these tests fail.
Frequently Asked Questions
What is BOLA?
Broken Object Level Authorization (API1:2023) is the most common API risk. An attacker manipulates the ID of an object in the path, query, or body and accesses someone else's data, because the server doesn't check whether the user is allowed to see that exact object.
How do you prevent BOLA?
With an object-level authorization check on every access, following the default-deny principle, enforced server-side based on the authenticated user, plus tests that actively play through cross-tenant access and block the deploy if they succeed.
What's the difference between BOLA and BFLA?
BOLA concerns access to individual objects, i.e. someone else's data. BFLA concerns access to functions or actions, such as an admin function. BOLA is the object level, BFLA is the function level.