
BOLA Prevention Checklist for API Engineers
Broken Object-Level Authorization is the #1 API risk on OWASP. This checklist gives engineers concrete patterns and anti-patterns to ship safer APIs.
How do you prevent broken object level authorization (BOLA)?
BOLA is prevented by anchoring every object lookup to the authenticated caller's ownership rather than trusting an identifier supplied in the request — enforcing the check in the data layer, using unguessable references, and testing every endpoint with a second account. Macksofy validates these controls in API penetration tests.
BOLA — Broken Object-Level Authorization — sits at the top of the OWASP API Security Top 10 because it keeps shipping. This one-pager gives API engineers concrete patterns and anti-patterns drawn from real findings across BFSI, fintech and SaaS pentests.
Anchor every authorization decision to ownership
- Resolve the actor's tenant / customer-id from the session — never from the URL or body.
- Resolve the resource's owner from the database — never trust a client claim.
- Compare the two before doing anything else with the resource.
- Reject with 404 (not 403) to avoid leaking existence of resources.
Anti-patterns to fail in code review
- Authorization implemented inside templates / view layer — must be in the resolver / controller.
- Authorization dependent on a client-supplied 'customerId' or 'tenantId' field.
- Authorization checked once at login and assumed for the session.
- Bulk endpoints (`/customers/batch`) without per-element ownership checks.
- Admin endpoints living on the same router as user endpoints — easy to leak.
GraphQL-specific tripwires
- Authorization on root query/mutation only — must be on every resolver that fetches a tenant-bound object.
- Permissive schema directives (@auth on parent type only) — directives must apply to fields, not types.
- Subscription endpoints frequently miss ownership checks entirely.
Testing tips for engineers
- Two-account integration test: account A asks for resource owned by account B → expect 404.
- Sequential-ID enumeration test: try id+1, id-1, id*2 — expect 404 on every other tenant's ID.
- GraphQL fragment test: bypass per-field auth by aliasing fields under `__typename` queries.
- Bulk-endpoint test: include one cross-tenant ID in a batch — expect rejection of the whole batch or per-item filter.
Most of our 'critical' BOLA findings are critical because they chain with a JWT validation flaw. Treat your JWT validation layer as part of your BOLA defence, not separate from it.
Macksofy offers full-service engagements that map directly to this resource. Common starting points:
