BOLA/BFLA Playground
A fake employee-directory API. Read a record that isn't yours, then call an admin-only action with no admin role at all.
The top two entries in the OWASP API Security Top 10, in one lab. BOLA is reading a record that is not yours; BFLA is calling a function your role should not reach. Both come from the same omission — the authorisation check that never got written.
How to use it
- Read your own employee record.
- Change the identifier and read someone else's.
- Call an administrative action without an admin role.
What to take away
APIs make this worse than web UIs
A UI hides the admin button. An API documents the endpoint, and the client-side role check that hid it never existed on the server.
Object level and function level are separate checks
You need both: may this user touch this record, and may this user perform this action at all? Passing one says nothing about the other.
Frequently asked questions
Why is BOLA number one on the API Top 10?
Because it is both the most common API flaw and among the most damaging — it usually exposes every record of a given type, not just one.
How do I test for it?
Create two accounts. Do everything as one, then replay each request with the other's session and see what still succeeds.
Where this fits in the course
This security lab pairs with Path 21 — API Security — see all 26 learning paths.
It runs entirely in your browser: nothing is uploaded, no account is needed, and it is free.
Related
- IDOR Playground — A fake "my invoices" page. Change one number in the URL and see whose data you were never supposed to see.
- Mass Assignment Toy — A "update my profile" endpoint that binds whatever JSON you send straight to your account. Find the field that shouldn't be writable.
- GraphQL Introspection Abuse — A single /graphql endpoint. Use introspection to map the full schema, then query a field the UI never shows you.
- Rate-Limit Bypass Simulator — A login endpoint that blocks you after 3 bad guesses — but trusts a header you control to decide who "you" are.