Lesson 3.5: Broken access control and IDOR
Authentication asks who you are; authorization asks what you may do. Broken access control, number one in the OWASP Top 10, is when the second question is skipped. Its most common form, the insecure direct object reference (IDOR): change a number in a URL and see someone else's data. Also missing function-level checks (admin pages) and why hiding links isn't a defence. In the lab your order API shows any customer's order to anyone logged in. You prove it with Elif's account, find someone who downloaded 25 orders in the log, fix the database query so it checks the owner, and prove both sides of the fix.
18 min
You will learn to
- Tell authentication from authorization
- Explain IDOR and function-level access control
- Spot enumeration of IDs in a log
- Fix an IDOR by checking ownership on the server
- Test a fix in both directions: blocked for others, still working for the owner
Key terms
- Authentication
- Proving who you are: password, MFA, passkey.
- Authorization
- Deciding what an authenticated user may do or see.
- IDOR
- Insecure Direct Object Reference: the application uses an ID from the request to fetch an object without checking the user may access it.
- Function-level access control
- Checking that the user's role may use a function at all, for example an admin page or a delete action.
- Enumeration
- Trying IDs, names or values one after another to find which exist.
- Deny by default
- Refusing access unless a rule explicitly allows it.
← IPv6: the next generation of addresses · All lessons · MITRE ATT&CK: a shared language for attacker behaviour →