BOLA testing for your API
Broken Object Level Authorization (BOLA) is the API version of IDOR and the number-one risk on the OWASP API Security Top 10: an endpoint returns or edits an object without checking the caller actually owns it. Sintropyc tests it with real API calls across users and roles, and proves every crossing.
Why BOLA is OWASP API #1
APIs expose objects directly and at scale — one endpoint can serve millions of records keyed by ID. If the authorization check on that key is missing or wrong, a normal authenticated user can walk the entire dataset. It's the most common and most damaging API flaw precisely because it's invisible to the owner and trivial to automate once found.
Where BOLA hides
- REST paths —
GET /api/v1/accounts/{id}/invoicesthat never checks{id}is yours - GraphQL — node lookups by global ID with no per-object owner check
- Bulk and filter endpoints —
?org_id=that trusts the client - Write and delete routes, not just reads — often the higher-impact half
How Sintropyc tests it
Sintropyc is an autonomous AI penetration testing agent. It signs in as real users across different roles, drives your product the way a customer would, and proves every finding with a working exploit — never a scanner guess. Each finding is checked by a human before it reaches you, comes with the exact fix, and is attacked again after you ship it to confirm it held.
Sintropyc reads your API surface (OpenAPI/GraphQL schema when available, or by observing traffic), then calls each object endpoint as one user against another user's identifiers — including writes and deletes — and reports only what it can actually reach, with the request and the returned object as proof.
What you get
- Every object endpoint tested for cross-user access
- Proven reads, writes and deletes across accounts and roles
- OWASP API Top 10 mapping for each finding
- The fix (owner check at the object layer) and a retest
Common questions
How is this different from a DAST scanner?
A scanner throws payloads at inputs; BOLA isn't an input bug, it's a missing authorization decision. Proving it needs multiple real identities and the business context of who owns what — which Sintropyc has and a scanner doesn't.
Do you test function-level authz too?
Yes — see API authorization testing, which covers object-level (BOLA), function-level and property-level (mass assignment) failures together.
Can it run against a staging API?
Yes, and that's usually the safest choice. We can mirror your stack so results match production without touching it.