CS0-003 Vulnerability Management Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Broken Object Level Authorization

  Why this is correct

  Broken Object Level Authorization (BOLA) is the most direct and correct answer because it occurs when an API fails to enforce per-object permissions, allowing an attacker to access, modify, or delete another user's data simply by substituting an object ID in an API request. For example, changing 'GET /api/user/123' to 'GET /api/user/456' can expose another user's private information if the server does not verify that the authenticated principal owns the requested object. This flaw is specifically catalogued as API1:2019 in the OWASP API Top 10 and is a primary focus of API penetration testing.

• ✓

  Excessive Data Exposure

  Why this is correct

  Excessive Data Exposure (API3:2019) is another correct option because it describes APIs that return entire database objects or more fields than the client actually needs, leaving the client-side application to filter the sensitive data. Attackers can then intercept the full responses or simply call the API endpoint directly to harvest extra attributes such as hashed passwords, credit card numbers, or internal business logic. This is distinct from BOLA in that it is an information-disclosure flaw caused by over-fetching, not a missing authorization check on the object itself.

• ✗

  SQL Injection

  Why it's wrong here

  SQL Injection is not the best answer because while it can affect APIs through unsanitized parameters, it is a generic attack technique that applies to any data-driven application and is not unique to API design. The OWASP API Top 10 does not list SQL Injection as a standalone API-specific concern; rather, it falls under broader injection categories that affect web applications equally. In the context of API vulnerability testing, you would specifically look for object-level IDOR issues like BOLA before considering ubiquitous web flaws like SQLi.

• ✗

  Cross-Site Scripting (XSS)

  Why it's wrong here

  Cross-Site Scripting (XSS) is incorrect because it is a client-side vulnerability that requires a user's browser to interpret malicious script, whereas an API is a server-side interface that typically returns raw JSON or XML data. Since APIs do not render HTML and execute JavaScript on the server, XSS is not a direct API vulnerability, and it would only become relevant if the API-powered application reflects content without sanitization. Therefore, placing XSS on an API vulnerability test list would be a misunderstanding of the API attack surface.

• ✓

  Broken Authentication

  Why this is correct

  Broken Authentication (API2:2019) is a correct answer because it encompasses flaws such as weak token generation, improper session validation, and the lack of rate limiting on login endpoints, all of which are directly relevant to API security testing. APIs commonly expose authentication mechanisms and if these are broken, an attacker can compromise user accounts or misuse tokens to gain unauthorized access. It is considered one of the most critical API-specific vulnerabilities, with incidence rates around 20% in OWASP's research.

Go deeper

Related to this question