dhacker lab · Orders API console
BOLA vs BFLA: object-level and function-level authorization
127.0.0.1 only · fake data
Acting as
API

Orders API console

Pick who you are and which API you talk to (top bar), then click an endpoint or type your own request. Every call sends Authorization: Bearer <the fake token of the selected user>. Both APIs check that you are logged in; the question is what happens after that.

Endpoints

Amber = documented as admin-only. The same endpoints exist on both APIs.

Request

Mission 1 · Broken object level authorization

You are alice, a normal customer, on the vulnerable API. You are allowed to use /orders/{id}; the bug is that it never asks whose order that id is. Find out how far that goes.

1. Your own orders

2. Open one order by id

Start with 1001, then change the number.

3. Walk the ids

One request per id from 1001 to 1008, as the selected user. The verdict column compares the order's owner with who you are.

4. Change someone else's order (write)

Switch to bob, then cancel order 1002, which belongs to alice. Switch back to alice and open 1002.

Mission 2 · Broken function level authorization

As alice (role user) call the functions that exist for administrators. Nothing here is about someone else's object: the question is whether your role may call the function at all.

Admin functions

POST /admin/orders//refund

Mission 3 · Fix and replay

The same 14 requests, replayed against an API. "Policy says" is what the fixed API must answer. Anything else is a violation. The run resets the data first.

Server log

One JSON line per request, as the server prints it (docker compose logs api). The ruler column applies the two simplest detection rules on this page: a non-admin getting 2xx on /admin/*, and an actor getting 2xx on an object owned by someone else.

Code

The dispatcher and the order handlers of each API, read from the running server. Compare what runs between "the request arrived" and "the handler runs".

vulnerable.py

fixed.py