PT0-002 Attacks and Exploits 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.

• ✗

  Stored XSS

  Why it's wrong here

  Stored XSS is incorrect because the payload would be permanently saved on the server (e.g., in a database, comment field, or profile) and executed whenever any user loads that stored content. In the scenario, the tester observes the injected input immediately echoed in the current HTTP response, which indicates a temporary, request-bound reflection rather than a persistent server-side persistence. Stored XSS also typically affects multiple users over time, whereas a reflected attack only triggers when the crafted link is clicked.

• ✗

  Blind XSS

  Why it's wrong here

  Blind XSS is incorrect because the payload fires in a location the attacker cannot directly see, such as an admin panel, support ticket system, or log viewer, rather than being immediately reflected back to the attacker in the same HTTP response. Here, the tester directly sees the injected code echo in the response, so the output location is not hidden or deferred. Blind XSS usually requires an external callback (e.g., an HTTP request to an attacker-controlled server) to confirm execution, which is not described in this case.

• ✓

  Reflected XSS

  Why this is correct

  Reflected XSS is correct because the injected script is included in a request (commonly a URL parameter) and the server immediately echoes it back in the response without proper sanitization, causing the browser to execute it. The attacker can craft a malicious link containing the payload and trick the victim into clicking it; when the victim's browser sends the request, the reflected payload executes in the victim's session. This matches the scenario where the tester exploits the web application and sees the payload reflected directly in the response, making a crafted link the natural delivery vector.

• ✗

  DOM-based XSS

  Why it's wrong here

  DOM-based XSS is incorrect because the vulnerability would be triggered purely on the client side, where JavaScript reads data from a source like location.search or document.referrer and passes it to a sink such as innerHTML, without the server ever reflecting the payload in the response body. In this case, the tester sees the input reflected in the server's HTTP response, proving that the server-side code is directly echoing the unsanitized value. DOM-based XSS would show the payload only in the browser's DOM after client-side script execution, not in the raw server response.

Go deeper

Related to this question