Test what you understood — not what you memorized.
QUESTION 01 OF 05
You're logged into a shopping app. Your order is at /api/orders/5021. You change the URL to /api/orders/5020 and see a different customer's order. What type of vulnerability is this?
Correct — you were authenticated (logged in), but the API didn't check whether order 5020 was yours. That's an authorization failure — specifically BOLA.
Not quite — you didn't use anyone else's session, manipulate a query, or misconfigure anything. You just changed a number. The API never checked if that number's data belonged to you. That's BOLA.
QUESTION 02 OF 05
What is the core difference between authentication and authorization?
Correct — authentication is identity ("who are you?"). Authorization is permission ("what are you allowed to do?"). BOLA is always an authorization failure — the API knew who you were, it just didn't check what you were allowed to access.
Not quite — authentication and authorization are two different checks. Authentication = "who are you?" Authorization = "what are you allowed to access?" BOLA happens when the second check is skipped.
QUESTION 03 OF 05
The Peloton breach exposed 4 million users' private data. What made it especially easy to exploit?
Correct — no token, no session, no login required. Just a URL with a user ID. Change the ID, get the data. No hacking skill needed whatsoever.
Not quite — the Peloton breach required no credentials, no exploits, and no injection. The API endpoint was wide open — unauthenticated. Anyone who knew the URL pattern could access any account.
QUESTION 04 OF 05
When an API denies access to an object a user doesn't own, which HTTP status code should it return — and why?
Correct — a 403 confirms "this thing exists but you can't have it." A 404 reveals nothing. If an attacker is enumerating IDs, 404s give them no information about which IDs are valid. Don't help them narrow it down.
Not quite — a 403 tells the attacker "this record exists, you just can't see it." That confirms the ID is valid — useful intel for enumeration. A 404 is safer: it reveals nothing about whether the object exists.
QUESTION 05 OF 05
T-Mobile's 2023 breach exposed 37 million customer records over 6 weeks undetected. Which mitigation would have been most likely to catch it early?
Correct — the attacker queried the API millions of times over six weeks. That volume and pattern is anomalous. A monitoring system watching for unusual API access patterns would have flagged this on day one — or hour one.
Not quite — UUIDs and HTTPS wouldn't have helped here (the API already accepted authorized queries). Re-auth doesn't stop mass enumeration either. The breach ran for 6 weeks because nobody was watching the query patterns. Monitoring (MIT 07) is what catches this.