Here’s the bug in one request. You’re logged in as a customer, and your browser calls GET /api/orders/12345 to show your latest order. Out of curiosity, you change the number to 12346. The API returns someone else’s order: their name, address, and what they bought.
Nothing was hacked. No password was guessed. The API checked that you were logged in, and it never checked whether that order was yours.
This is Broken Object Level Authorization, or BOLA, and it’s one of the most common and most damaging API vulnerabilities. This page explains how it happens and how to prevent it in REST APIs.
Sunvak Boreal helps organizations find and fix BOLA through REST API security testing, authorization testing, and manual penetration testing.
What Is BOLA in a REST API?
BOLA happens when an API accepts an object identifier (a user ID, account ID, order ID, document ID) without checking whether the person asking is allowed to access that specific object.
Take a profile endpoint:
GET /api/users/1001
If the API only confirms that the requester is logged in, an attacker can change the ID to 1002, and if the API hands back that user’s data, the endpoint is vulnerable.
The root of it is that authentication and authorization are two different questions. Authentication asks, “Who are you?” Authorization asks, “Are you allowed to see this particular thing?” A secure API has to answer both, on every request.
Why BOLA Is Such a Serious Risk
Because it lets one user reach another user’s data, the damage depends on what your API holds. That could be customer profiles, personal information, financial records, orders, invoices, documents, support tickets, healthcare records, account details, internal business data, or another tenant’s records entirely. In some applications, BOLA also lets an attacker modify or delete objects, not just read them.
How to Secure REST APIs Against BOLA
1. Check authorization on every object request
Don’t stop at “is this user logged in?” The check should be “is this user logged in AND allowed to access this object?” And it has to happen on the server, every time.
2. Treat object IDs from the client as untrusted
Users can change anything they send: user IDs, account IDs, order IDs, document IDs, invoice IDs, UUIDs, even the resource path. Changing an identifier should never quietly grant access to something else.
3. Check ownership
When a resource belongs to a user, verify that before returning or changing it. For GET /api/orders/12345, the backend needs to confirm that the authenticated user is actually allowed to see order 12345. Don’t rely on the frontend to hide what they shouldn’t see.
4. Use role-based access control, enforced by the backend
Different users need different permissions, and the API should define them clearly. For example:
| Role | Customer Data | Orders | Admin Functions |
| Customer | Own records | Own orders | No |
| Support User | Assigned records | Assigned orders | Limited |
| Manager | Authorized business records | Business scope | Limited |
| Administrator | Based on defined administrative permissions | Based on permissions | Yes |
5. Go beyond function-level checks
An API can correctly limit GET /api/orders/{id} to logged-in users and still never check whether that order belongs to the person asking. Endpoint-level protection isn’t the same as object-level protection.
6. Protect writes as well as reads
BOLA isn’t only about viewing data. Check authorization before users can update or delete records, upload files, change account information, modify transactions, approve requests, change ownership, or update permissions. Someone who can’t view another user’s object usually shouldn’t be able to edit or delete it either, though the exact model depends on your business rules.
7. Watch nested resources
Take GET /users/1001/orders/5001. The API should confirm both that the requester can access user 1001 and that order 5001 really falls within that scope. Checking only one of the two IDs leaves a gap.
8. Don’t lean on the frontend
Hiding a button or a link isn’t security. Attackers don’t use your interface. They send requests directly. Every decision has to be enforced by the backend.
9. Centralize authorization where you can
If every endpoint implements its own checks, some will get them wrong. A shared authorization layer makes decisions more consistent, as long as it understands ownership, roles, tenant boundaries, and your business-specific rules.
10. Test horizontally and vertically
Horizontal testing asks whether one user can reach another user’s resources. Vertical testing asks whether a lower-privileged user can reach things meant for a higher role. You need both.
Where BOLA Tends to Hide
Look closely at sequential and predictable IDs, UUID-based resources, user, account, order, document, file, invoice, and tenant IDs, nested resources, graph-based resources, and read, update, delete, and bulk operations.
A common misconception: using UUIDs instead of sequential numbers makes IDs harder to guess, which helps, but it doesn’t replace authorization. IDs leak through emails, shared links, logs, and other API responses. If someone gets hold of a valid one, the API still has to say no.
How Sunvak Boreal Tests REST APIs for BOLA
Scanners struggle with BOLA because they don’t know who owns what. So we test by hand.
- API discovery. We identify endpoints, resources, parameters, HTTP methods, and object references.
- Authentication review. We look at how users authenticate and how tokens are handled.
- User and role mapping. We map test accounts to their intended permissions and boundaries.
- Object identification. We find the IDs, UUIDs, resource references, and nested objects the API uses.
- Horizontal testing. Can one authorized user reach another user’s objects?
- Vertical testing. Can a lower-privileged user reach objects or functions meant for higher roles?
- Read and write testing. Where the scope allows, we check GET, POST, PUT, PATCH, and DELETE for object-level controls.
- Multi-tenant testing. For SaaS platforms, we check that users can’t cross tenant boundaries.
- Business logic testing. We look at whether workflows let users manipulate object references or access controls in unexpected ways.
- Reporting. Each confirmed BOLA issue is documented with the affected endpoint, impact, evidence, and remediation guidance.
A Worked Example
Suppose Account Owner A is logged in and calls GET /api/accounts/4521. The server should ask four things. Is this user authenticated? Do they have permission to access account 4521? Does that account belong to their authorized scope? Is this operation allowed for them?
If the API returns the account simply because the user is logged in, there’s an object-level authorization problem. The decision has to be made on the server before the resource goes out.
BOLA vs. Related Terms
BOLA vs. authentication. Authentication verifies identity. BOLA is an authorization failure. An API can have excellent login security and still be vulnerable.
BOLA vs. IDOR. They’re closely related. IDOR (Insecure Direct Object Reference) is the older term for exposing an internal object reference without enforcing access control. BOLA is the term commonly used in API security. The core problem is the same: the app didn’t verify that the requester may access that specific resource.
BOLA vs. Broken Function Level Authorization. BOLA is about access to a specific object. Broken function-level authorization is about access to a function. Opening another customer’s invoice suggests BOLA. Calling an admin-only endpoint as a regular user suggests broken function-level authorization. An API can suffer from both.
Who Should Test for BOLA?
Any organization running APIs that expose object-based resources, including SaaS applications, e-commerce platforms, banking and fintech apps, healthcare platforms, insurance applications, mobile apps, customer portals, enterprise APIs, multi-tenant platforms, partner APIs, and internal business APIs.
When to Test
Consider BOLA testing before you launch a new API or ship major API changes, after authorization or authentication redesigns, when you add user roles or introduce multi-tenancy, after major application changes or security incidents, before compliance assessments, and during regular penetration tests and VAPT engagements.
Preventing BOLA for Good
A solid prevention approach combines server-side authorization checks, ownership validation, role-based access control, least privilege, tenant isolation, secure API design, centralized and consistent authorization logic, manual and automated testing, logging and monitoring, regular penetration testing, and post-remediation verification. It also helps to document which users, roles, and services are meant to access each resource, so “who should see this?” has a written answer.
Why Sunvak Boreal?
We test REST APIs by hand, focused on how your application really behaves and where its authorization boundaries sit. That includes BOLA and authorization testing, authentication testing, API access control testing, business logic testing, privilege escalation testing, multi-tenant testing, vulnerability validation, and retesting after you fix things.
We look for the practical weaknesses that automated API scanning usually can’t see.
Final Thoughts
Protecting an API with a login isn’t enough. Every request has to be judged against two things: who the user is, and which specific object they’re asking for. Ownership, roles, tenant boundaries, and allowed operations all need to be enforced on the server.
Regular API security testing helps you catch these gaps before someone else does. If you’d like us to take a look at yours, Sunvak Boreal is happy to help.
[Test Your REST APIs for BOLA Vulnerabilities]
Frequently Asked Questions
What is BOLA in REST APIs?
Broken Object Level Authorization happens when an API fails to verify whether a user is allowed to access a specific object or resource.
How can BOLA be prevented?
Enforce object-level authorization on the server, validate ownership, apply least privilege, separate tenant data, and test your access controls regularly.
Does using UUIDs prevent BOLA?
No. UUIDs make identifiers harder to guess, but they don’t replace authorization checks. Someone who obtains a valid identifier can still try to use it.
Is BOLA only a read vulnerability?
No. It can affect read, update, delete, and other operations if the API doesn’t verify authorization for the requested object.
Is authentication enough to prevent BOLA?
No. Authentication establishes who the user is. Authorization determines what they’re allowed to access.
How is BOLA tested?
Testers typically use several authorized test accounts and try to access objects belonging to other users, roles, or tenants, checking whether the API enforces authorization each time.
Can automated scanners detect BOLA?
They can flag some potential authorization weaknesses, but many BOLA issues need manual testing, because the tester has to understand user roles, object ownership, and application behavior.
Is BOLA relevant to multi-tenant applications?
Yes. Multi-tenant applications need strong isolation between customers, and incorrect object-level authorization can expose one tenant’s data to another.