312-50 Question 342
Single answer▪ Attack Web ServicesDuring an authorized assessment, you are testing a RESTful web service used by a mobile application. The API endpoint /api/v1/user/3817/profile returns the profile for user ID 3817 after the user authenticates with a valid bearer token. While reviewing traffic in Burp Suite, you notice that changing the request to /api/v1/user/3818/profile returns another user's profile while your token remains unchanged. The server still responds with HTTP 200 OK, and there is no evidence of SQL errors or session hijacking. Which vulnerability is MOST likely present?
- A
Broken Object Level Authorization (BOLA) / Insecure Direct Object Reference (IDOR)
- B
SQL injection in the profile lookup query
- C
Cross-Site Request Forgery (CSRF) against the API endpoint
- D
XML External Entity (XXE) processing in the request parser
Show answer and explanation
Correct answer: A
Explanation
The best answer is Broken Object Level Authorization (BOLA), historically often called IDOR in web application testing. The key indicator is that an authenticated request for one object succeeds, and simply changing the object identifier exposes another user's data without any additional privilege. This is a common and high-impact web service/API weakness because the application validates that the user is logged in but fails to enforce authorization on the specific resource being requested.
This aligns with OWASP API Security guidance, where BOLA is consistently identified as a top API risk. In practical testing, ethical hackers commonly detect it by capturing legitimate API requests and modifying identifiers in URL paths, query parameters, JSON bodies, or headers to determine whether server-side access control is enforced. Proper remediation includes server-side authorization checks on every object access, avoiding reliance on client-supplied identifiers alone, and implementing least-privilege access controls.
The other options are plausible distractors because they are also common web service issues, but they do not match the evidence. SQL injection would require query manipulation, CSRF centers on forged browser-originating requests, and XXE depends on insecure XML parsing. None of those explain why a simple numeric ID change returns another user's profile with the same valid token.
- A. Correct.
Correct. The authenticated user can access another user's record simply by changing the object identifier in the request path. That is a classic object authorization failure. In modern API security terminology, this is Broken Object Level Authorization (BOLA), and in traditional web application terminology it is commonly described as IDOR. The issue is not authentication, because the token is valid; the failure is that the server does not verify whether the authenticated principal is authorized to access object 3818.
- B. Incorrect.
Incorrect. SQL injection involves influencing a backend query by injecting SQL syntax into input that is not safely handled. In this scenario, the evidence points to predictable object identifiers being accepted without proper authorization checks. The response is valid application data for a different user, not an indication that the tester manipulated a query or triggered database behavior through crafted payloads.
- C. Incorrect.
Incorrect. CSRF relies on forcing a victim's browser to send an authenticated request to a target application. Here, the tester is directly modifying an API request in Burp Suite while using their own valid bearer token. The problem is unauthorized access to another object's data, not a forged browser request initiated from another site. Also, many bearer-token APIs used by mobile apps are not primarily exposed to browser-based CSRF in the same way cookie-authenticated web apps are.
- D. Incorrect.
Incorrect. XXE requires XML parsing with insecure external entity handling. The scenario describes a RESTful API with path parameter manipulation and no indication that XML input is being processed. The observed behavior is an authorization flaw tied to object access, not XML parser abuse.