Testing web APIs for broken object level authorisation (BOLA)

Broken object level authorisation, usually shortened to BOLA, is one of the most common API security issues because it sits in the gap between application logic and access control. In simple terms, the API exposes an object, such as an order, invoice, case, tenant record, file, or user profile, and the server fails to verify that the caller is allowed to access that specific object. The result is not a generic authentication failure. The user is authenticated, but the object-level check is missing, incomplete, or inconsistent.

For UK SMEs, this matters because modern applications often rely on APIs for web front ends, mobile apps, partner integrations, and internal admin tools. If object-level access control is weak, a low-privilege user may be able to view or alter data that belongs to another user or tenant. That can create confidentiality, integrity, and contractual risk, especially in SaaS and regulated environments. It is also the kind of issue that can remain hidden for a long time because the application appears to work normally for legitimate users.

If you are already using structured web testing, a tool such as Burp Suite is often the most practical place to observe and compare API requests, responses, and authorisation behaviour. The key is to use it as a validation aid, not as a way to improvise intrusive testing. Keep the scope controlled, the accounts authorised, and the evidence precise.

What broken object level authorisation means in practice

BOLA occurs when the server trusts an object reference without checking whether the current subject is entitled to that object. The object reference may be a numeric identifier, UUID, slug, filename, tenant key, or nested resource path. The important point is that the identifier itself is not the problem. The problem is the missing server-side ownership or entitlement check.

Broken function level authorisation is related, but different. Function level authorisation is about whether a user can invoke a privileged action at all, such as creating an admin account or exporting all records. BOLA is about whether a user can access a specific instance of a resource they should not see. In practice, both can appear in the same application, but they need different test cases and different fixes.

API object references create risk because they are often predictable, reusable, and easy to pass between requests. A front end may fetch a record by ID, then later update it using the same ID in a different endpoint. If the back end only checks that the request is authenticated, and not that the object belongs to the caller, the access control model is incomplete.

Where BOLA typically appears in modern APIs

REST APIs are the most obvious place to look. Endpoints such as GET, PUT, PATCH, and DELETE often take an object identifier in the path or body. Examples include /orders/12345, /users/8f2c…, or /tenants/acme/invoices/9911. If the application uses direct object references, the security question is not whether the ID is hard to guess. It is whether the server validates ownership, tenancy, or role before returning or changing the object.

GraphQL can also be affected, although the shape of the issue is different. Because GraphQL often exposes flexible queries and nested object retrieval, the test focus shifts to resolver-level checks and whether the backend enforces object permissions consistently across query paths. Mobile back ends and partner APIs are also common sources of BOLA because they are frequently optimised for convenience and speed, then reused across different clients without a fresh access control review.

Multi-tenant SaaS patterns deserve particular attention. A tenant boundary is only as strong as the checks that enforce it. If tenant context is derived from a header, token claim, or route parameter, the application must verify that every object lookup is constrained to the authenticated tenant. Weak tenant isolation is one of the most damaging forms of BOLA because it can expose data across customers, not just within a single account.

How to scope BOLA testing safely and ethically

Safe BOLA testing starts with explicit authorisation and a narrow test plan. Define which environments are in scope, which endpoints can be exercised, which accounts are approved, and what data sets are safe to use. For most SMEs, that means using non-production or production-like test tenants with synthetic records, not live customer data. If production testing is required, keep it tightly controlled and agreed in writing with the system owner.

Set up at least two authorised accounts with different roles or tenancy boundaries. For example, use two standard users in separate tenants, or a standard user and a limited support user. The point is to compare access decisions across identities that should not have the same visibility. If the application has admin, support, or delegated access roles, include those only if they are necessary for the test objective.

Agree logging, rate limits, and rollback expectations before testing begins. Good logging helps you prove what happened without exposing unnecessary data. Rate limits reduce the chance of accidental load or alert noise. Rollback matters if the test changes state, for example by updating a record or creating a temporary object. A controlled test is easier to repeat, easier to explain, and less likely to disrupt operations.

For teams that are building broader testing capability, it is sensible to align the work with release controls and regression checks, as described in automating security testing as part of release pipelines. BOLA findings are especially valuable when they are turned into repeatable checks rather than one-off manual observations.

A practical workflow for testing object-level access controls

Start by mapping the API surface. Capture the endpoints, methods, object identifiers, and any role or tenant context that influences access. A proxy such as Burp Suite is useful here because it lets you compare requests side by side and replay them in a controlled way. Look for patterns such as object IDs in URLs, JSON bodies, form fields, headers, and query parameters. Also note any endpoints that return object lists, because list endpoints can leak identifiers that are later reused in detail or update calls.

Next, identify the ownership rule for each object. Ask a simple question for every endpoint: what makes this caller entitled to this object? The answer may be tenant membership, record ownership, explicit sharing, role membership, or a support workflow. If the application does not have a clear entitlement rule, that is a design smell in itself. Good access control is not just a code check, it is a defined business rule.

Then compare responses across users, roles, and tenants. Use the same request shape with different authorised identities and observe whether the server returns the same object, a different object, or a denial. Pay attention to status codes, response bodies, timing differences, and error messages. A 403 Forbidden is not automatically proof of safety if the same object can still be inferred through other endpoints or side effects. Likewise, a 404 Not Found can be misleading if the application hides authorisation failures by design but still leaks data elsewhere.

Where the application supports update or delete operations, validate both read and write paths. It is common to find that a resource is protected on retrieval but not on modification, or vice versa. Also test related endpoints that act on the same object in different ways, such as export, attachment download, history view, audit trail, or status change. BOLA often appears in the less obvious path, not the main CRUD route.

What strong evidence looks like during validation

Strong evidence is specific, reproducible, and minimal. Record the request, the response, the authenticated identity used, the object reference, and the expected versus actual outcome. If possible, include a short sequence showing the same request from two different authorised accounts. That makes the access control failure easier to understand and reduces debate about whether the result was accidental.

Useful evidence usually includes response codes, response size, key fields returned, and any state change that occurred. For example, if a user from tenant A can retrieve tenant B’s invoice metadata, note exactly which fields were exposed. If a low-privilege user can update another user’s address record, capture the before-and-after state in a way that does not expose unnecessary personal data. Keep the evidence focused on the control failure, not on the sensitive content itself.

Be careful not to over-collect. Security testing should not become data harvesting. If a short proof is enough to demonstrate the issue, stop there. In many cases, a single object and a single comparison between two authorised identities is sufficient. That approach is safer for the business and easier for developers to act on.

Common implementation mistakes that lead to BOLA

One common mistake is trusting the client to enforce access control. A front end may hide buttons or filter lists, but that is only a user interface control. If the API accepts the object identifier directly, the server must still enforce the rule. Client-side checks are useful for usability, but they are not security controls.

Predictable identifiers also make weaknesses easier to expose. Sequential IDs, simple tenant codes, and loosely structured slugs can all make testing easier, but the real issue is not predictability alone. Even a UUID does not prevent BOLA if the server fails to check ownership. Obscurity can slow casual probing, but it does not replace access control.

Another common issue is incomplete server-side lookup logic. For example, the application may fetch an object by ID first and then check the user role later, or it may check the role but not the tenant. In multi-step workflows, the entitlement check can be applied to the wrong object, or skipped on one branch of the code path. These are the kinds of implementation mistakes that slip through if testing only covers the happy path.

Weak object lookup logic also appears when applications use shared repositories, caching layers, or service-to-service calls. If one component assumes another has already validated the request, the control can disappear at a boundary. This is why object-level checks should be enforced as close to the data access decision as possible, not left to the user interface or an upstream service.

How to reduce BOLA risk in design and development

The safest pattern is deny by default, then allow only when the caller is explicitly entitled to the object. That entitlement should be checked server-side on every request that reads or mutates a protected object. In practice, this often means scoping queries by both object ID and subject context, rather than fetching by ID and checking later. For example, the data access layer should ask for the object where object_id equals X and tenant_id equals Y, not just object_id equals X.

For multi-tenant applications, make tenant context a first-class control. Do not rely on the client to supply the right tenant value unless the server validates it against the authenticated identity. Where possible, derive tenant context from the token or session and use it consistently across all object lookups. If support staff or delegated users need cross-tenant access, design that as a separate, auditable workflow with clear approval and logging.

It is also worth aligning the design with secure development practices and abuse-case thinking. A threat model should include object-level misuse, not only injection or authentication bypass. If you already use structured secure design reviews, this is a good place to add BOLA scenarios to the checklist. The same approach complements broader application security work, including the controls discussed in implementing OWASP ASVS controls across application tiers.

From an implementation perspective, common patterns include policy enforcement at the service layer, row-level security in the database where appropriate, and centralised authorisation helpers that are hard to bypass. The exact pattern depends on the stack, but the principle is consistent: every object access should be evaluated against the caller’s entitlement at the point of use.

Detection and monitoring for object-level abuse

Even with good design, monitoring still matters. Useful log fields include authenticated user ID, tenant ID, role, session or token identifier, object ID, endpoint, method, source IP, user agent, and decision outcome. If the application supports correlation IDs, include them so that a sequence of requests can be reconstructed across services. Without these fields, investigating BOLA becomes much harder.

Look for repeated access to object IDs that do not belong to the caller, especially when the pattern spans many IDs or many tenants. Other indicators include a high rate of 403 responses, repeated 404s against object endpoints, and access to list endpoints followed by detail requests for objects outside the user’s normal scope. These are not proof of malicious activity on their own, but they are useful signals for investigation.

In a SIEM, you can build simple detections for unusual object access patterns. For example, alert when a standard user requests more than a small threshold of distinct object IDs outside their tenant within a short window, or when a user repeatedly hits the same object endpoint with changing identifiers. If you have a mature detection engineering process, treat BOLA telemetry as a use case for both security monitoring and application abuse analytics.

Monitoring should also support safe triage. If a detection fires, the analyst needs enough context to decide whether the activity was a test, a support action, or a genuine abuse attempt. That means maintaining a test register, tagging approved security testing windows, and keeping a clear separation between operational and test accounts where possible.

How BOLA maps to OWASP and secure development practices

BOLA is directly aligned to OWASP API Security Top 10 API1:2023, which places broken object level authorisation at the top of the list. That is useful context for prioritisation, but the real value comes from turning the category into concrete engineering work. The issue is not just a label. It is a reminder that object-level checks need to be designed, implemented, tested, and monitored as part of normal delivery.

Threat modelling helps here because it forces the team to think about who should access which object and under what conditions. Abuse cases are especially useful for APIs because they describe how a legitimate user might overreach their entitlement. For example, a user may try to access another tenant’s record through a shared endpoint, or a support user may attempt to use a normal customer route to reach privileged data. Those scenarios are straightforward to model and easy to turn into test cases.

Regression testing is the final piece. Once a BOLA issue is fixed, the test should become part of the release pipeline or the application security test pack. That can be a manual check for a small team, or an automated integration test that validates ownership rules across representative endpoints. The important thing is that the same weakness does not reappear in the next sprint.

A short remediation checklist for technical teams

First, fix the affected endpoint by enforcing server-side object-level checks at the data access or service layer. Do not rely on the front end, and do not assume a role check elsewhere covers the object in question. If the application has multiple code paths to the same object, review them all.

Second, retest using at least two authorised identities and the same object references that exposed the issue. Confirm that the original path is blocked and that related endpoints behave consistently. If the fix changes response codes or error handling, verify that the behaviour is intentional and does not create a new information leak.

Third, add regression coverage. That may include unit tests for policy logic, integration tests for API endpoints, and negative tests for cross-tenant or cross-user access. If you use CI/CD, make the check part of the normal pipeline so it is not dependent on memory or manual discipline. For teams that want to formalise this further, it can sit alongside other release-stage checks such as those described in automating security testing as part of release pipelines.

Finally, update logging and monitoring so that future attempts are visible. A fix is stronger when it is paired with detection, because it gives you both prevention and evidence if the control is challenged again.

For UK SMEs that want a pragmatic review of API access control testing, architecture, and regression coverage, a consultant can help you turn these checks into a repeatable process that fits your delivery model. Speak to a consultant if you want support shaping that approach.

Frequently asked questions

What is broken object level authorisation?

Broken object level authorisation is an API access control flaw where the server allows a user to access or change a specific object, such as a record or file, without verifying that the user is entitled to that object.

How is BOLA different from broken function level authorisation?

BOLA is about access to a specific object instance, while broken function level authorisation is about whether a user can invoke a privileged action at all. They can occur together, but they need different test cases and fixes.

How do you test for BOLA without giving attack instructions?

Use authorised test accounts, compare requests and responses across users or tenants, and focus on whether the server enforces ownership or tenancy checks consistently. Keep the scope controlled, use synthetic data where possible, and record only the minimum evidence needed to prove the control failure.