AuthZ Lab — IDOR / BOLA
Broken Object Level Authorization sits at the top of the OWASP API Security Top 10. The bug pattern, in almost every case I have reviewed, is the same: the endpoint authenticates the caller, then trusts the object ID in the URL without checking who owns it. This lab is built around feeling that bug rather than reading about it.
AND owner_id = ? on the query. The bug is its absence.Three things in this lab
Simulator
Switch between Alice, Bob, and an admin. Try to read order IDs that belong to other users. The naive endpoint hands them over; the hardened endpoint returns the same 404 it returns for IDs that don't exist. Watch the difference live.
Open simulator →Patterns
Eight detection rules (BOLA01–BOLA08) covering the patterns I look for in code reviews and Burp traces: missing owner scope, 403-vs-404 leakage, sequential IDs, mass-assignment on update, client-supplied admin flags, GraphQL resolver gaps.
See patterns →Where this fits
BOLA is the AuthZ failure that survives a perfect AuthN deployment. Even with passkeys (Identity Lab) and a strict CSP (CSP Playground), a single brokenWHERE clause leaks customer data.
Why this lab matters
AuthZ bugs are different from AuthN bugs in one crucial way: the user is correctly authenticated when the breach happens. Every log line says "valid session, valid token, 200 OK". The request looks legitimate to every monitoring tool you have. The only signal is at the data layer — and most teams don't instrument that layer for ownership-mismatch alerts.
On a recent API review, the same pattern came up on the third endpoint I tested: a numeric order ID in the path, a valid bearer token, a clean 200 response, and someone else's invoice in the body. Run the simulator first; the patterns page reads better once you have felt the bug rather than just read about it.