A real BOLA or IDOR finding proves that one controlled actor can perform an unauthorized action on an object owned by another actor or tenant. A suspicious response difference is only a lead. Deterministic evidence needs object ownership, valid attacker identity, the exact request substitution, the protected data or state change, and a comparison with expected policy.

This proof must separate authorization failure from caching, error handling, shared data, public objects and inconsistent test setup. The same discipline makes the finding reproducible for engineering and retestable after remediation.

Create two controlled identities and distinct objects

Use Actor A and Actor B with known roles, tenants and ownership. Create Object A under Actor A and Object B under Actor B. Record identifiers and a non-sensitive marker unique to each object. For tenant isolation, repeat the setup across Tenant A and Tenant B.

  • Authentication material belongs to the stated actor.
  • Ownership is established through a trusted view or creation evidence.
  • Objects are not intentionally shared or public.
  • Roles and tenant memberships match the policy being tested.
  • Test data can be safely read or changed for validation.

Establish the authorized control request

Actor B accesses Object B through the normal client or API. Capture the successful request, response and relevant object state. This confirms the endpoint, object and workflow are valid before changing identity relationships.

Change only the authorization relationship

  1. Keep Actor A’s valid session or token.
  2. Replace Object A’s identifier with Object B’s identifier.
  3. Preserve other required request fields and state.
  4. Send the request and record the complete outcome.
  5. Verify returned data or server-side state through an independent view.

Changing many variables at once weakens attribution. A clean control pair makes it clear that object ownership, not malformed syntax or a different workflow, caused the difference.

Prove confidentiality impact

For an unauthorized read, show protected fields unique to Object B that Actor A could not know legitimately. Compare the response with Actor B’s authorized view. Avoid claiming exposure from response size or status alone.

  • Sensitive attributes returned in the body.
  • Download or signed URL grants access to another owner’s file.
  • Search, list or export includes unauthorized records.
  • Metadata reveals protected relationship or business state.

Prove integrity impact

For an update, delete, approval or transfer, verify the state change from Actor B’s authorized session or a trusted administrative view. A 200 response may hide a no-op, and a 403 response may arrive after a queued action was accepted.

  • Before-and-after values or object lifecycle state.
  • Audit event and acting principal.
  • Notification, queue job or downstream side effect.
  • Persistence after refresh and across relevant services.

Check indirect object references

Objects may be addressed by opaque IDs, nested routes, filenames, tokens, aliases, GraphQL node IDs or business keys. Test the reference used by the server, not only the most visible URL segment. Confirm whether child resources inherit authorization from the parent.

Rule out misleading response differences

  • Object is public, shared or accessible through legitimate collaboration.
  • Response is a generic shell without protected content.
  • Cached content belongs to the attacker’s own prior request.
  • The operation returned success but made no server-side change.
  • The test token actually contains both tenant memberships.
  • Environment seed data does not match documented ownership.

Inspect token claims, authoritative ownership and post-request state. When needed, use server logs with the application team while preserving tester independence.

Test breadth after proving one path

Once the root cause is established, check related actions and routes: list, search, create-child, update, delete, share, export, bulk and alternate API versions. Test same-tenant peers and cross-tenant actors separately. Sample shared enforcement carefully.

Document attacker preconditions

  • How the attacker obtains an account and required role.
  • How the target identifier can be learned, guessed or discovered.
  • Whether exploitation requires user interaction or timing.
  • Rate limits, monitoring or other controls that constrain scale.
  • Whether the action is repeatable across objects or tenants.

Identifier entropy does not replace authorization. It may affect practical exploitability and scale, which should be documented separately.

Write a reproducible evidence package

  1. Affected build, endpoint and operation.
  2. Actor A and Actor B roles and tenant aliases.
  3. Trusted proof that Actor B owns the target object.
  4. Authorized control request and response.
  5. Unauthorized request using Actor A’s identity.
  6. Protected data or verified state change.
  7. Expected policy, impact, preconditions and tested limits.

Redact reusable credentials while preserving identity labels and identifiers needed for reproduction. Link screenshots to protocol evidence rather than using them alone.

State severity with context

Severity depends on data sensitivity, action consequence, attacker access, identifier discovery, population, tenant crossing, repeatability and compensating controls. Keep the finding valid even if context changes the priority.

BOLA is a core API authorization risk discussed by the OWASP API Security project. The category is a starting point; deterministic ownership and outcome evidence proves the specific finding.

Define the retest

Repeat the original control pair on the fixed build, try other peer and tenant combinations, test sibling operations and confirm Actor B still has legitimate access. Verify that denial occurs before any async or downstream side effect.

The practical decision

Accept a BOLA or IDOR finding when controlled ownership, attacker identity, request substitution and protected outcome create a deterministic chain of evidence. Treat status, length or timing differences as hypotheses until data access or state change is proven and alternate explanations are ruled out.

Use WIMD for evidence-led API authorization testing with controlled identities, ownership proof, reproducible requests and impact verification.