Test what you understood — not what you memorized.
QUESTION 01 OF 05
What is the core difference between BOLA (API1) and BFLA (API5)?
Correct — BOLA is horizontal: same type of function, wrong object. BFLA is vertical: wrong function entirely, regardless of the object. BOLA asks “can this user access this specific record?” BFLA asks “can this user call this type of action at all?”
Not quite — the difference is about what’s being checked. BOLA = wrong object (you changed an ID to access someone else’s data). BFLA = wrong function (you called an endpoint your role isn’t allowed to use at all). Both apply to authenticated users. Both affect REST and GraphQL.
QUESTION 02 OF 05
In the Bumble vulnerability, what made it possible for a free-tier user to access premium features?
Correct — the Bumble API checked authentication (is this a valid session?) but not authorization (does this session’s subscription tier permit this function?). A free-tier user had a valid session. The session passed the auth check. But there was no second check asking “is this subscription level allowed to call this premium endpoint?”
Not quite — the paths were findable (by watching app traffic in a proxy), but that’s only how the attacker discovers the endpoints. The root cause was that the API itself had no subscription-tier check. A free user calling the endpoint got the same response as a paying user — because the server never asked “does this user’s tier permit this function?”
QUESTION 03 OF 05
Why does “the button is hidden from regular users” not prevent BFLA?
Correct — the UI and the API are separate systems. The UI decides what to render. The API decides what to accept. Hiding a button from the UI is a UI decision — it has no effect on the API. An attacker uses curl, Burp Suite, a Python script, or any HTTP client to call the API directly, bypassing the UI entirely. The API must enforce its own authorization.
Not quite — UI hiding is purely a display decision. It has absolutely no effect on what the API accepts. Any user can call an API endpoint directly using any HTTP client — no browser required. The API must check whether the request is authorized, independently of whether any UI exposed the action to the user.
QUESTION 04 OF 05
An API has GET /api/posts/{id} available to all users and DELETE /api/posts/{id} restricted to admins. A developer adds an authorization check to GET but forgets DELETE. What attack does this enable?
Correct — this is the HTTP verb manipulation pattern. The authorization check on GET is irrelevant to DELETE. The attacker changes their HTTP method from GET to DELETE. The URL is the same. If the route handler for DELETE has no role check (or inherits the weaker check from the path), the delete executes. This is why authorization must be defined per method + path, not just per path.
Not quite — this is a function-level failure, not an object-level one. The attacker isn’t changing the ID (BOLA) or modifying fields (BOPLA) — they’re changing the HTTP method from GET to DELETE. The authorization check for GET doesn’t protect DELETE. This is HTTP verb manipulation, a common BFLA pattern.
QUESTION 05 OF 05
Why is “deny by default” more secure than “block specific admin endpoints” when protecting API functions?
Correct — this is the classic allowlist vs. blocklist security principle applied to functions. With a blocklist, every new admin endpoint is accessible by default until someone adds it to the block list — which they may forget, especially under deadline pressure. With deny by default, every new endpoint returns 403 until the developer actively permits specific roles. The more dangerous state (accessible) requires deliberate action; the safer state (blocked) is the automatic default.
Not quite — the key is the default state for new endpoints. With a blocklist approach, a new admin endpoint that ships without being added to the blocklist is accessible to everyone. With deny by default, the same endpoint returns 403 automatically until someone permits it. The failure mode matters: deny-by-default fails safe (inaccessible). Blocklists fail open (accessible).