IDOR and BOLA: test access to another user’s data

Understand IDOR and BOLA

IDOR describes unsafe direct object references; BOLA describes broken object-level authorization in an API. A readable ID is not itself the vulnerability. The issue is a server returning or modifying an object without enforcing the caller’s ownership, organization and role rules.

Prepare two independent contexts

Create A in organization X and B in organization Y, with separate sessions and synthetic documents. Record document paths and unique private markers. First prove that A can read A and B can read B. Otherwise, a forbidden cross-user request could simply reflect invalid sessions or unavailable fixtures.

Primary sources: Primary reference 1 · Primary reference 2

Continue: Prepare an automated API security assessment

Test reads step by step

Request B’s known document using A’s session, then reverse the direction. Inspect private content as well as status. Our controlled fixture returns the other owner’s marker in its vulnerable mode; the fixed mode returns 403 while both owners retain access. The actual BOLA rule confirms the vulnerable observation with repeated reads.

Check alternate paths to the same object

A protected detail endpoint does not prove that exports, previews and downloads enforce the same permissions. Repeat the known-object test on relevant supported paths. Include guest and anonymous contexts where they have defined permissions. Do not interpret a public resource as private without an explicit expectation.

python3 access-fixture.py
curl -H "X-Fixture-User: a" "http://127.0.0.1:8769/documents/doc-b?mode=vulnerable"
curl -H "X-Fixture-User: a" "http://127.0.0.1:8769/documents/doc-b?mode=fixed"

Primary sources: Primary reference 1 · Primary reference 2

Continue: Supabase security: check RLS and access to data

Test changes and protected fields

Changing a role, owner or tenant can be more consequential than a read. Define an approved staging mutation, the expected forbidden fields and a way to verify restoration. Do not infer update safety from read controls, and do not perform write checks on production customer objects.

Enforce permissions on the server

Derive identity from a verified session, load trusted object ownership and apply the application’s organization and role rules before returning data or writing changes. A hidden button or client-side condition cannot replace this check. Keep authorization consistent across the main endpoint and secondary access paths.

Primary sources: Primary reference 1 · Primary reference 2

Continue: JWT security: validate tokens and access lifecycle

Prove the fix

The original cross-owner attempt must stop exposing private content, but each owner must still access its own object. A redirect to login, timeout or WAF block is not sufficient proof. Keep the same fixture contract, environment and deployment identifier so the retest compares the intended behavior.

Automate the regression check

Save supported access scenarios in Scantelio and rerun them after releases. Use a targeted retest for a known finding and a broader release check for the rest of the approved coverage. Review the report when roles, organizations, object paths or fixture markers change.

Continue: Add security checks to CI/CD and GitHub Actions

Reproducible examples and downloads

Tested with: guides-1 · Python 3.13.0 · PyJWT 2.15.1

All example data is synthetic. Downloads contain no active keys or customer records. Run examples only in your own isolated test environment.

• access-matrix.csv — example / template
• access-fixture.py — example / template

Example verification record: versions, actions and observations

Questions and answers

Editorial team and sources

Scantelio editorial team: methodology and limitations. Example verified: 2026-11-02.

• Reference 1 · api-security.owasp.org
• Reference 2 · cheatsheetseries.owasp.org