312-50 Question 350
Single answer▪ Web App SecurityDuring an authorized web application assessment, you test a customer portal that displays account details at the URL https://portal.example.com/account?id=1054. After authenticating as a normal user, you change the id value in the browser to 1055 and the application returns another customer's profile data without any authorization check. The application uses HTTPS and a valid session cookie, but there is no indication that the server verifies whether the requested record belongs to the logged-in user. Which vulnerability does this most clearly demonstrate?
- A
Insecure Direct Object Reference (IDOR) / Broken Access Control
- B
Cross-Site Request Forgery (CSRF)
- C
Session fixation
- D
SQL injection
Show answer and explanation
Correct answer: A
Explanation
The best answer is Insecure Direct Object Reference (IDOR) / Broken Access Control. In real-world web app testing, this issue appears when an application exposes predictable object identifiers such as account numbers, invoice IDs, file names, or user IDs and relies on the client to request only authorized resources. If the server does not enforce object-level authorization, an authenticated user may access other users’ records by changing a parameter value. OWASP classifies this under Broken Access Control and recommends denying access by default, performing server-side authorization checks for every object request, and using indirect references or opaque identifiers only as defense-in-depth rather than as a substitute for access control. Relevant guidance can be found in the OWASP Top 10 (Broken Access Control) and the OWASP Authorization Cheat Sheet.
- A. Correct.
Correct. This is a classic example of Insecure Direct Object Reference (IDOR), which falls under broken access control. The application exposes a direct reference to an internal object (
id=1055) and fails to enforce server-side authorization to confirm that the authenticated user is allowed to access that specific record. Simply being logged in is not sufficient; the server must validate object-level access on every request. - B. Incorrect.
Incorrect. CSRF involves tricking an authenticated user’s browser into sending unwanted requests to an application where the user is already authenticated. In this scenario, the tester is manually modifying a parameter and directly observing unauthorized access to another user's data. The issue is missing authorization, not forged cross-site requests.
- C. Incorrect.
Incorrect. Session fixation occurs when an attacker sets or predicts a victim’s session identifier and then reuses that session after the victim authenticates. Nothing in the scenario indicates that the session ID was fixed, reused, or attacker-controlled. The problem exists even with a valid session because authorization checks on the requested object are missing.
- D. Incorrect.
Incorrect. SQL injection would involve manipulating input so the backend database query is altered, often using characters such as quotes, comments, or operators. Here, simply changing one numeric identifier to another returns unauthorized data, which points to an access control flaw rather than evidence of database query manipulation.