Cybersecurity Exercise #3
Exercise · Vulnerability Description (IDOR / Broken Access Control)
AppSec · English- Name the vulnerability (what is it?).
- Explain the risk/impact in 1–2 sentences.
- Explain the root cause in simple terms.
- Write a fix recommendation (developer-friendly).
Recommended fix:
- The API must enforce object-level authorization.
- The server should verify invoice.owner_user_id == session.user_id for every request.
- The system should return 403 Forbidden (not 200) when access is not allowed.
- Logs should capture denied access attempts for investigation.
- Consider using non-guessable identifiers if appropriate, but do not rely on that alone.📖 Vocabulary definitions
- IDOR — Insecure Direct Object Reference; accessing someone else’s data by referencing an object you shouldn’t access.
- object-level authorization — verifying a user is allowed to access a specific resource (invoice #10493).
- resource — a protected item like an invoice, profile, or order.
- ownership — the resource belongs to a user or account.
- access control — rules that determine who can do what.
- impact — the damage or risk created by the issue.
- 403 Forbidden — server response when access is not allowed.
🧩 Collocations natural pairings
- broken access control
- enforce authorization checks
- validate ownership
- expose sensitive information
- return 403 Forbidden
- prevent unauthorized access
- log access attempts
🗣️ Idioms, Phrases & Modal Lines spoken English
- at a glance — “At a glance, the endpoint looks normal, but it’s missing authorization.”
- opens the door to — “This opens the door to data leaks.”
- the root cause is — “The root cause is missing object-level authorization.”
- we should / we must — “We must check ownership on every request.”
- tighten up — “We should tighten up access control for invoice endpoints.”
🎤 Model Answer (two audiences) example
Developer version:
“This is an IDOR / broken access control issue. The API only checks that the user is authenticated,
but it does not enforce object-level authorization. As a result, a logged-in user can access invoices that
belong to other users by requesting a different invoice ID. We must verify ownership
(invoice.owner_user_id == session.user_id) on every request and return 403 when unauthorized.”
Manager version:
“This is a permission problem. A customer who is logged in can sometimes see other customers’ invoices.
That could expose names, addresses, and billing details. We should fix it by making the system verify
that each invoice belongs to the logged-in customer before showing it.”
Fix recommendation:
“Engineering must add ownership checks on invoice endpoints, add tests to prevent regression,
and log denied access attempts for investigation. We should also review similar endpoints for the same pattern.”