API5:2023Broken Function Level Authorization
Slide 17 of 28
Part 3 · Attack ScenariosSlide 17
Slide 17 · The Pattern
The same missing question, every time.
Across every scenario: authentication ran. Authorization didn’t.
The Missing Question

Every BFLA attack succeeded because after checking “is this a valid token?” the API never asked: “does this token’s role entitle it to call this specific function?”

Not “can they access this object?” — API1 covers that. Not “can they write these fields?” — API3 covers that. Specifically: can this role call this action?

The pattern in each scenario
Bumble — free user called premium endpoint: does this subscription permit this function?
GitLab — unauthenticated caller got all users: does anonymous access permit user enumeration?
Admin URL discovery — regular user called /admin/users/all: does user role permit admin functions?
Verb manipulation — user called DELETE instead of GET: does this role permit DELETE on this resource?
Seller self-approval — user called /approve on their own account: does user role permit approvals?
The fix pattern
Define required role for every endpoint — not just authenticated/unauthenticated
Enforce role check on method + path combination, not just path
Deny by default: if no role is explicitly permitted, return 403
Test non-admin tokens against every admin path
Never rely on obscurity (hidden URLs, unlisted paths)
← Back How do we fix it? →
📄 View sources