312-50 Question 344
Single answer▪ Attack Web ServicesDuring an authorized assessment, you are testing a RESTful web service at https://api.example.com/v1/users/{id}. The API uses a bearer token for authentication. When requesting /v1/users/1001 with a valid token for your own low-privileged account, the server returns your profile. You then change only the path parameter to /v1/users/1002 and the API returns another user's full profile with HTTP 200, even though your token and role remain unchanged. Which vulnerability is MOST clearly demonstrated by this behavior?
- A
SQL injection in the users endpoint
- B
Insecure Direct Object Reference (IDOR) caused by missing object-level authorization
- C
Cross-Site Request Forgery (CSRF) because the bearer token was reused
- D
Server-Side Request Forgery (SSRF) because the API fetched another user's record
Show answer and explanation
Correct answer: B
Explanation
The most accurate answer is Insecure Direct Object Reference (IDOR), which in modern API security terminology aligns closely with Broken Object Level Authorization (BOLA). The critical observation is that authentication is present, but authorization is not being enforced at the object level. The authenticated user should be validated against the requested resource, for example by confirming that the subject in the bearer token is allowed to access user 1002 before returning that profile. This type of flaw is especially common in web services and APIs where object identifiers appear in paths, query parameters, or JSON bodies. OWASP API Security Top 10 identifies Broken Object Level Authorization as a leading API risk, and the OWASP Top 10 places broken access control among the most critical web application issues. Proper remediation includes enforcing server-side authorization checks for every object access, avoiding reliance on client-supplied identifiers alone, implementing least privilege, and logging and monitoring access-denied events.
- A. Incorrect.
Incorrect. The scenario does not show evidence of SQL injection such as unsanitized input altering a query structure, database error messages, or successful payload-based manipulation. Simply changing a numeric object identifier and receiving another user's data is more indicative of broken access control than injection. A candidate might choose this because user IDs are often used in database queries, but the key issue here is authorization failure, not query manipulation.
- B. Correct.
Correct. This is a classic Insecure Direct Object Reference (IDOR), more broadly categorized today under broken access control or broken object-level authorization. The API accepts a direct reference to an internal object identifier in the path and returns another user's resource without verifying whether the authenticated subject is allowed to access that specific object. In APIs, this is commonly described as Broken Object Level Authorization (BOLA). The decisive clue is that only the object ID changed while the same low-privileged token still succeeded.
- C. Incorrect.
Incorrect. CSRF involves causing a victim's browser to send an authenticated request to a target application without the victim's intent, typically relying on automatically included credentials such as cookies. In this scenario, the tester is directly calling an API with a bearer token and observing improper access to another user's data. The problem is not forged browser requests but insufficient authorization checks on object access.
- D. Incorrect.
Incorrect. SSRF occurs when a server is induced to make requests to internal or external systems chosen by an attacker. Here, the API is returning data from its own application resources based on a user ID in the path. There is no indication that the server was instructed to fetch a remote URL or internal network resource. This option is plausible only because the server is retrieving data, but that alone does not make it SSRF.