Slide 14 of 28
Part 3 · Attack ScenariosSlide 14
PART 3
Attack Scenarios
Slides 14–17 · OWASP examples in plain English
Slide 14 · Scenario 1
The regular user who became an admin.
OWASP Scenario #1 — a user endpoint and an admin endpoint, same auth, different intent.
📄 OWASP API Security Top 10 · 2023 · API5 · Scenario 1
SETUP
A platform with user and admin APIs sharing the same authentication.

An API has two sets of endpoints: user endpoints (/api/v1/users/) and admin endpoints (/api/v1/admin/). Both require a valid auth token. The admin endpoints are not linked in the regular UI — users never see them. The developer assumes users won’t find them.

Both endpoint groups use the same authentication middleware. Neither group has role checks implemented on specific endpoints — the developer planned to add them later.

The exploit: An attacker logs in as a regular user and inspects the app’s JavaScript bundle. They find the admin paths listed in the routing config. They call GET /api/v1/admin/users/all with their regular user token. The API validates the token (valid), finds no role check, and returns every user’s account data. The attacker then calls PUT /api/v1/admin/users/1041/role with body {"role":"admin"}. They are now an admin.
The danger of “add auth later”

Admin endpoints that are planned but not yet protected are indistinguishable from unprotected endpoints in production. Any admin path that reaches production without role checks is exploitable from the moment it ships. Authorization must be added before launch, not after.

← Back Scenario 2 →