Published 2026-11-06 · By Jeffrey Monica
Start with an explicit authorization policy
Broken Object Level Authorization (BOLA), often called IDOR, arises when a valid identity can request an object for which it lacks permission. An authenticated session is not the same as authority over the requested document, tenant or action. Define the invariant in terms of principal, tenant, resource, operation and current membership.
Build a synthetic fixture with Tenant A and B, ordinary members, a tenant admin and owned documents. Derive the caller from a verified identity token, never a user-provided tenant header or body field.
Validation checklist
- Same-tenant owner access should succeed where policy allows.
- Cross-tenant admin and member access should be denied.
- Expired or downgraded roles must be denied.
Test every object path, including list and bulk operations
For each permitted read, write and delete, construct a denied request changing only one attribute: tenant, owner, role or object ID. Include nested IDs and foreign keys in request bodies. Depending on your contract, unauthorized access can return 403 or a privacy-preserving 404, but failure must not reveal confidential details.
List, count, search, bulk, export and signed-download routes also need negative cases. Successful status responses are not sufficient: inspect returned objects and ensure an unauthorized write did not change state.
Validation checklist
- Exercise path, query and body-based references.
- Assert no side effects for rejected writes.
- Check batch endpoints for partial cross-tenant results.
Follow the authorization boundary through workers and caches
A route can check permission correctly yet queue a bare object ID that a privileged background job later processes without a tenant check. Carry independently verifiable scoped context through the job or re-evaluate access when it executes. Verify what happens after role revocation and while retries are pending.
Partition caches by relevant identity/permission context; a cached 200 from one tenant must never satisfy another. Idempotency and replay protection must not let a second caller retrieve a first caller's successful result.
Validation checklist
- Test async exports after membership revocation.
- Test caches and repeated idempotency keys across principals.
- Check log and audit fields do not leak secrets or records.
Turn fixes into sustained regression evidence
Use two known tenants and stable synthetic resource IDs in CI. A change to policy enforcement must pass positive access tests and all relevant negative paths; avoid treating a large number of happy-path HTTP tests as authorization evidence.
The Demonic Binary API authorization lab demonstrates these concepts with synthetic data and an intentionally weak handler, not a real customer system. Client testing always needs permission, a customer-specific policy matrix and approval to test.
Validation checklist
- Name the responsible policy owner and affected endpoint.
- Document the reason for 403 versus 404 choices.
- Retest deployed boundaries independently of CI fixtures.
Primary references
Engineering practices and threat-model choices, not product certification, a guarantee against compromise or a customer penetration-test result.