Bob signs in to the lab API with his own valid account, requests GET /invoices/inv_100, and receives Alice’s invoice. The attacker did not steal a token, bypass login, or guess a password. Bob changed an object identifier in a route that the server accepted without checking whether inv_100 belongs to Bob. The defender’s question is therefore narrower and more useful than whether login works. For every request, does the API prove that the authenticated principal may perform this operation on this object?
Our running artifact is a small REST API with POST /login, GET /invoices/{invoiceId}, PUT /invoices/{invoiceId}, and GET /admin/audit. Alice owns inv_100, Bob owns inv_200, and an administrator may read audit records. A threat model identifies what an attacker already controls, which boundary the request crosses, what the attacker wants, and which server decision must stop the request. Here, Bob controls his authenticated request and the invoiceId; he wants Alice’s invoice; authorization must reject access before data leaves the store.
Authentication establishes that the request came from Bob. Authorization must still decide whether Bob may read inv_100. Treating those decisions as one check creates the failure, because a valid identity says nothing about ownership or administrative privilege. Our goal throughout the course is to harden this same API and prove each boundary holds under test. The following map locates the boundaries Bob crosses.
This diagram shows why a request can pass authentication yet fail at authorization or data access. The object identifier becomes dangerous only when the API uses it to fetch a record without binding that record to the authenticated principal.
The missing ownership check is API1:2023 Broken Object Level Authorization, or BOLA, in the OWASP API Security Top 10 2023. Any endpoint that takes a client-controlled object ID needs an authorization decision for that object. GET /invoices/inv_100 and PUT /invoices/inv_100 are separate operations, so each needs its own decision even when both name the same invoice.
The other early risks cluster around the same request path. API2:2023 Broken Authentication concerns whether the API correctly identifies Bob. API3:2023 Broken Object Property Level Authorization concerns whether a permitted invoice response exposes or accepts fields Bob must not access, such as an internal approvalLimit. API4:2023 Unrestricted Resource Consumption concerns Bob sending costly requests often enough to exhaust capacity or trigger paid downstream work. API5:2023 Broken Function Level Authorization concerns Bob reaching GET /admin/audit despite lacking administrative permission.
Each category changes a different part of the request, but all test whether the server enforces a boundary rather than trusting client input, a token alone, or an endpoint name. The table weighs the attacker change, the protected outcome, and the evidence defenders need.