SY0-701 Threats, Vulnerabilities, and Mitigations 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.

• ✗

  Cross-site scripting

  Why it's wrong here

  Cross-site scripting (XSS) is an injection attack that executes malicious scripts in a user's browser by exploiting improper input sanitization, typically within the same page or session. While XSS can steal session tokens or perform actions on behalf of the user, it does not explain how simply altering an invoice ID in a URL grants direct access to another user's invoice. The core issue here is the application's failure to enforce object-level authorization, not script execution. XSS would require the attacker to inject code, whereas this scenario involves an authenticated user changing a parameter to view unauthorized data.

• ✓

  Broken access control

  Why this is correct

  Broken access control occurs when the application fails to properly verify whether an authenticated user is allowed to access a specific object or resource. Changing the invoice ID reveals that authorization is missing or weak.

• ✗

  SQL injection

  Why it's wrong here

  SQL injection occurs when an application fails to properly sanitize user input within SQL queries, allowing an attacker to manipulate database commands, extract data, or bypass authentication. However, changing an invoice ID in a URL to view another user's invoice does not constitute SQL injection, as the user is not crafting SQL syntax or observing database errors. The vulnerability is that the server accepts the ID without verifying ownership, which is a flaw in access control logic, not in query construction. SQL injection would typically yield unauthorized data through crafted input, but here the request is a legitimate, albeit unauthorized, direct object reference.

• ✗

  Cross-site request forgery

  Why it's wrong here

  Cross-site request forgery (CSRF) tricks a victim's browser into sending an unintended, authenticated request to a server, exploiting the user's session without their knowledge. In this scenario, the agent is directly and intentionally modifying the invoice ID in their own session, not being forced to make an unwanted request. CSRF involves a third-party website forging requests, whereas the described behavior is a direct user action that the application improperly allows. The root cause is missing authorization checks on the object ID, not a lack of CSRF tokens or the manipulation of a victim's browser.