BOLA testing: evidence for object-level API authorization

Sources checked: 29 October 2026. This article contains FailSafe's analysis and proposed validation workflow; linked sources support the reported facts.

An API BOLA assessment should establish whether a permitted user can access another owner's object, using synthetic accounts and an explicit ownership policy. A successful login alone cannot answer that question.

OWASP identifies object-level authorization as a separate enforcement problem from login. OWASP API1:2023 provides the underlying reference. The assessment design below is an original defensive example, not a report of a customer incident.

Define the ownership model

Begin with the product rule: a workspace member can read records assigned to their workspace, and only selected roles can modify them. Record exceptions such as shared documents or delegated support access. Without this statement, a tester may mistake an intended collaboration feature for a vulnerability. Inventory read, edit, download, archive, and export operations separately. A page that blocks navigation can still delegate a sensitive operation to another service. Include mobile and background-job entry points when they act on the same objects.

Use a controlled two-owner scenario

Create two synthetic workspaces with distinct test owners and one harmless document in each. Give the assessor accounts for both so expected access can be demonstrated without guessing identifiers or touching real users. Confirm that each account can retrieve its own document before checking whether the other account is refused. Use the application's approved testing interface and a documented request budget. Stop after the minimum evidence needed to establish the boundary; no production data collection is necessary.

Capture the authorization decision

The useful evidence is a before-and-after comparison tied to an identity, object owner, action, environment, and timestamp. Preserve a sanitized request summary, the response outcome, and a server-side decision or audit record when available. Distinguish an empty response from an explicit denial, and confirm whether a rejected write still changed state asynchronously. If a downloadable file sits behind a second service, follow the authorized test artifact through that delivery path. Redact tokens and personal information before adding evidence to a ticket.

Retest the rule across representations

After a fix, repeat the original case and a permitted control case. Then check the same ownership rule through another representation, such as an export or attachment, if it is in scope. Group results by permission decision rather than by URL count. Ten routes may share one enforcement point, while one route may invoke several. Record untested roles and excluded services so readers can understand what the result establishes. A clean sample does not prove every object in the product is isolated.

A useful assessment artifact

Keep a small ownership ledger for the fixture: test identity, assigned workspace, synthetic document, and expected action. That ledger makes the report independently understandable and lets the application owner recreate the same boundary after a migration.

Plan an assessment

Discuss the authorized scope and required evidence with FailSafe SWARM. For a business evaluating an initial engagement, review the first-pentest offer and confirm scope before purchase.