Auth Replay (BOLA / BFLA Tester)
BOLA/BFLA/auth bypass via cross-role replay. Part of AuditCore's automated security audit pipeline — runs on every scan in the Enterprise tier and above, with findings normalized into a single severity-rated table.
What is Auth Replay (BOLA / BFLA Tester)?
BOLA (Broken Object Level Authorization) is OWASP API Security #1 for a reason: it's the single most common, most damaging, hardest-to-detect-with-automation API vulnerability. The Auth Replay scanner is AuditCore's answer to BOLA — it's what makes us different from every scanner that just hits your app with payloads and hopes for SQL errors.
Here's how it works: during the authenticated crawl phase, we walk your app as multiple users (different roles if available, or two same-role users for tenant-isolation testing). Every authenticated HTTP request is recorded — what URL, what auth header, what body, what response. In the auth-test phase, we replay each request with the OTHER user's auth header. If User A's request to `GET /api/orders/123` returns the same data when sent with User B's token (where User B has no business seeing order 123), that's BOLA — confirmed, with proof.
This catches what no payload-based scanner can: business-logic authorization flaws. ZAP doesn't know that `/api/orders/123` should be scoped to its owner — it just sees a GET request returning JSON. Nuclei has no template for 'this user shouldn't see that resource'. Even commercial scanners (Detectify, Acunetix) don't do cross-role replay. AuditCore does, because we built it from the ground up to test multi-user authorization, not just input validation.
BFLA (Broken Function Level Authorization, OWASP API #5) is the same idea applied to function-level access: can a regular user call admin-only endpoints? We replay admin-discovered endpoints with non-admin sessions and check whether the response indicates success (200 + meaningful content) vs proper denial (401/403). Combined, BOLA + BFLA testing covers the bulk of authorization-related findings in OWASP API Top 10.
What it tests
- BOLA: object-level access control (User A accessing User B's resources)
- BFLA: function-level access control (regular users hitting admin endpoints)
- Tenant isolation in multi-tenant SaaS apps
- JWT scope/claim enforcement (does the API actually check the role claim?)
- GraphQL field-level authorization (can mutators be called by viewer-role users?)
- Direct object reference patterns (`/users/{id}`, `/files/{uuid}`, `/orders/{number}`)
- Indirect references via user-controlled IDs (POST body containing user_id)
- Privilege escalation via PATCH requests (changing `role: 'user'` to `role: 'admin'`)
- Session token reuse across roles
- API key vs session token authorization mismatches
Where it runs in the AuditCore pipeline
Phase 3/5 · Authentication Tests
Replay captured traffic across roles to find broken object-level / function-level authorization, and audit JWT, OAuth, session, cookie and SSL/TLS posture.
Source: scanners/auth_testing/auth_replay.py
Sample findings
BOLA in GET /api/v1/orders/{id} — User B can read User A's orders
Critical. We crawled as User A (saw their order #1234), then replayed `GET /api/v1/orders/1234` with User B's token. Response: HTTP 200 with User A's full order details (items, addresses, payment last-4). User B should have received 403 or 404. Mitigation: in your order controller, after authentication, verify `order.user_id === current_user.id` before returning. This check is missing in 60%+ of API codebases AuditCore audits.
BFLA in POST /api/admin/users — non-admin can create users
Critical. `/api/admin/users` is intended for admin role only. We replayed it with a regular-user JWT and got HTTP 200 with a created user response. The endpoint authenticates the request but never checks role. Mitigation: add explicit role check (`@require_role('admin')`) on every admin endpoint; ideally, scope admin routes to a separate router with role middleware applied at router-level.
Privilege escalation via PATCH /api/users/me
Critical. The endpoint accepts an arbitrary JSON body and updates the current user. Sending `{ "role": "admin" }` updated the user's role to admin without any check. Mitigation: explicitly allow-list patchable fields (whitelist `name, email, avatar_url`) and reject any others. Never serialize the entire request body into a model update.
GraphQL: viewer role can call admin mutations
Critical. The schema exposes `mutation { deleteUser(id: "…") }` but the resolver doesn't check the caller's role. Any authenticated user can delete any other user. Mitigation: add resolver-level guards (`@requiresRole('admin')`) or use a schema directive that enforces role on declared mutations.
Other authentication tests scanners
FAQ
Why do almost no other scanners do cross-role replay testing?
It's hard. To test BOLA, you need at least two valid sessions to replay against each other — most scanners only support a single authenticated session. You also need to crawl deeply enough to encounter object-references (URLs with IDs, JWT-scoped GraphQL queries). AuditCore is designed around this from day one: our crawler supports multiple roles, our recording proxy captures every request with auth context, and our auth-test phase systematically replays.
Do I need to provide multiple test accounts?
Ideally yes. The most thorough BOLA/BFLA testing uses at minimum two users in different roles (admin + member). For tenant isolation, two users in different orgs. Without multiple accounts, we can still test BFLA by attempting unauthenticated calls to authenticated endpoints, but BOLA testing is limited. Account setup is in the scan configuration step.
What if my app uses a non-standard auth scheme (custom JWT, session cookies + CSRF)?
We handle JWT, session cookies, OAuth2 access tokens, and API keys out of the box. For custom auth (e.g. mTLS client certs, signed-request schemes like AWS SigV4), contact us — Enterprise can configure custom auth handlers.
Will the scanner accidentally delete my data while testing?
We're careful with destructive HTTP methods (DELETE, PUT, PATCH). For DELETE specifically: we test BFLA by attempting the request, but if it returns 200 (vulnerable), we don't repeat it — one finding is enough. We never call DELETE on object-reference URLs we discovered through crawling. Test against staging if you're worried.
How does this compare to manual API pentesting?
Automated BOLA testing catches the obvious cases (most apps have at least one) at every scan. Manual pentesting catches business-logic-specific cases that require understanding the domain (e.g. 'a user with role X should be able to read resources of users in their downstream chain but not upstream' — only a human can encode that). Use AuditCore as the continuous baseline; manual pentests for domain-aware deep-dives.
Does this catch IDOR (Insecure Direct Object Reference)?
Yes — BOLA and IDOR are essentially the same vulnerability with different names from different OWASP projects (OWASP API Top 10 calls it BOLA; OWASP Top 10 calls it IDOR). The Auth Replay scanner detects both.