BOLA: The Architecture That Kills the #1 API Bug

Q: What is Broken Object Level Authorization (BOLA), and how is it different from IDOR?

Broken Object Level Authorization is a flaw where an API endpoint accepts a client-supplied object identifier — an integer, a UUID, a slug — and returns or modifies that object without checking whether the authenticated caller is actually permitted to access that specific object. The request authenticates correctly; the failure is that object-level authorization is never performed, so changing the identifier reaches another user's or tenant's data. IDOR, Insecure Direct Object Reference, is the older name for the same defect. OWASP consolidated it under BOLA in the API Security Top 10 because the root cause is authorization, not the reference being "direct": whether the identifier is exposed directly or indirectly, the problem is the absent permission check. OWASP ranks it API1:2023 — first in the list — and rates it Exploitability Easy, Prevalence Widespread, Detectability Easy, calling it extremely common because servers rely on parameters sent by the client to decide which objects to access rather than tracking authorization server-side.

Q: Why do vulnerability scanners and WAFs miss BOLA?

Because BOLA is the absence of a check rather than the presence of a malformed request, and both scanners and WAFs are built to catch the latter. A dynamic application security scanner authenticates as one identity and exercises endpoints; every object it requests genuinely belongs to that identity, so nothing looks wrong and the endpoint returns a clean HTTP 200. The vulnerability only becomes visible when a second identity requests the first identity's object and the server hands it over — a two-identity comparison that scanners do not perform automatically because they do not know which objects should belong to whom. A Web Application Firewall is worse suited still: it inspects request syntax for injection and known-bad patterns and has no model of your data ownership, so an authorization failure that produces a perfectly well-formed request is completely invisible to it. This is why BOLA persists as the number-one API risk despite mature tooling: the defect lives in application-specific authorization logic that generic scanning cannot reason about. The reliable detection is a generated per-endpoint test where user A requests user B's object and asserts denial.

Q: Do unguessable IDs (UUIDs) fix BOLA?

No. Replacing sequential integers with random UUIDs makes an object identifier harder to guess, which raises the effort required to discover a valid identifier, but it does nothing to authorize access once an identifier is known. That distinction matters because identifiers leak constantly through channels outside your control: server and proxy logs, HTTP referrer headers, browser history, shared links, CSV and PDF exports, error messages, analytics tools, and the responses of other endpoints. An attacker who obtains a valid UUID from any of these can use it exactly as they would a guessable integer, because the server still performs no ownership check. Treating unpredictable identifiers as a security control is a common and dangerous mistake: it converts a visible, testable authorization gap into a hidden one that feels safe. Unguessable IDs are a reasonable defence-in-depth measure against enumeration, and OWASP does recommend GUIDs, but they are obfuscation layered on top of authorization, never a substitute for it. The only durable fix is to check, on every access, that the caller has a relationship to the object that permits the action.

Q: What architecture actually prevents BOLA?

A centralised authorization decision that every object access is forced through, keyed on the triple of subject, action and object, and denying by default. Concretely, that means a Policy Decision Point — a single component that answers "can this subject perform this action on this object?" — invoked from a Policy Enforcement Point placed at the data-access boundary of the service that owns the object, so no query for a specific object runs before the decision returns allow. The alternative that fails is scattering per-handler ownership checks across every endpoint, because that depends on every developer remembering to write the check correctly on every new route forever, and a single omission exposes everything behind it. Three placement rules make the central design hold: the check runs at the object boundary rather than at the API gateway, because ownership facts live next to the data; the subject is always taken from the verified token while the object reference comes from the request, never the reverse; and the authorization predicate is pushed into the query so unauthorized rows are never selected, rather than fetched and then filtered. For anything beyond single-owner data, relationship-based access control expresses the permissions that roles cannot.

Q: What is ReBAC, and when should I use it instead of roles?

Relationship-based access control, ReBAC, models permissions as relationships between subjects and objects — for example, "user Anne is a viewer of document readme" or "team Platform is an editor of folder Infra" — and answers authorization queries by evaluating those relationships, including inherited ones such as "editors of a folder can edit the documents inside it." You should reach for it the moment your data has structure that role checks cannot express: sharing, teams, nested folders, organisational hierarchies, delegation, and per-object grants. Role-based access control answers "what kind of user is this?" which works for coarse function-level gates but collapses when the real question is "can this user edit this particular object because of how it was shared." The canonical design is Google's Zanzibar, which stores permissions as relationship tuples and, per its published paper, scales to trillions of access control lists and millions of authorization requests per second while maintaining 95th-percentile latency under 10 milliseconds and over 99.999% availability across three years. Open-source engines such as OpenFGA and SpiceDB implement the same tuple-and-check model, so a centralised, fine-grained authorization layer is a solved, affordable pattern rather than a performance risk.

Q: Why are GraphQL APIs especially prone to BOLA?

Because a single GraphQL query resolves a graph of nested objects through independent resolver functions, and each resolver that loads an object by identifier is its own object-access decision. In a REST API an object fetch corresponds roughly to one route, so there is one obvious place to put the authorization check. In GraphQL, a query might request a user, then their orders, then each order's line items, then the supplier behind each item, with a different resolver running for each level. Guarding only the top-level query — checking that the caller may read the root user — and assuming the nested resolvers inherit that authorization is exactly the failure mode OWASP describes, where a mutation checks that you are logged in but not that the target object is yours. Every resolver that resolves a node from an identifier must itself be a Policy Enforcement Point, or it is a hole through which the graph can be traversed into objects the caller was never authorized to see. The practical guidance is to enforce object-level authorization inside resolvers at the data-loading layer, not at the query entry point, and to treat batching and nested expansion as additional object-access surfaces rather than conveniences that inherit a parent's permission.

Q: Do internal, service-to-service APIs need object-level authorization too?

Yes, and skipping them there is one of the most common sources of large breaches. Teams frequently treat internal APIs as trusted because they sit behind the gateway on a private network, and drop object-level checks entirely, reasoning that only their own services call them. That assumption fails the moment anything reaches those services that should not: a compromised container, an over-scoped agent or automation credential, a server-side request forgery that pivots an external request into an internal one, or simply another internal service with a bug. Once object checks are absent, any such caller can read or modify any object by identifier, because the only thing that was ever protecting the data was network position — and network position is not authorization. The correct posture, consistent with zero trust, is that the same object-boundary check runs regardless of whether the caller is a browser, another microservice, or a model making a tool call: the enforcement point authenticates the calling workload, establishes the effective subject on whose behalf the call is made, and evaluates can(subject, action, object) against the object being accessed. Internal traffic gets the identical deny-by-default treatment as external traffic.

Q: How do I test for BOLA in CI so regressions cannot ship?

The reliable technique is a generated two-identity test per object-accessing endpoint. For every endpoint that accepts an object identifier — path parameters, query parameters, request-body identifiers, and GraphQL node arguments — create a test in which a resource is created or owned by user B, then requested, updated or deleted by an authenticated user A who has no relationship to it, and assert that the response is a 403 or 404 and that no data leaks. Run this suite on every pull request so a new endpoint without an authorization check fails the build rather than reaching production. This works precisely where scanners fail, because the test encodes the missing knowledge scanners lack: which objects belong to which identity, and therefore which cross-identity accesses must be denied. To keep coverage honest, drive the endpoint inventory from the route table or API schema rather than a hand-maintained list, so newly added endpoints are surfaced as untested and cannot be silently forgotten. Complement it by pushing ownership predicates into queries — so list endpoints are checked for count and timing leakage, not just single-object reads — and by making a passing two-identity test plus a Policy Decision Point call a merge requirement for any handler that loads an object by identifier.