PT0-002 Practice Question: A vulnerability scanner reports a reflected XSS…

Answer analysis

Option-by-option breakdown

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

• ✗

  The scanner used a POST request instead of a GET request for the payload

  Why it's wrong here

  The HTTP request method (GET vs POST) is irrelevant to whether a server-side application encodes user-controlled data in its response. Output encoding is determined by the application's templating and rendering logic, which behaves identically for either verb unless the endpoint explicitly branches on method. A reflected XSS finding depends on the payload appearing unencoded in the response body, not on how the scanner delivered the request. Since both methods result in the same server-side processing, this cannot account for a false positive.

• ✗

  The scanner's payload was reflected in a different context not subject to HTML encoding

  Why it's wrong here

  This option describes a scenario that would be a genuine reflected XSS vulnerability, not a false positive. If the payload is reflected in a context that lacks HTML encoding, such as inside a script block or an HTML attribute, the scanner is correct to flag it. Manual testing in this scenario, however, confirmed that every reflection point applies contextually appropriate encoding, so the premise of an unencoded context is factually false. The scanner cannot independently identify which context a reflection occurs in without further probing.

• ✗

  The scanner used a payload with special characters that were truncated by the server

  Why it's wrong here

  Truncation would prevent the full payload from appearing in the HTTP response, so the scanner's verification step—matching its exact payload string in the response—would fail, producing a false negative rather than a false positive. For a false positive, the scanner needs to see a reflected copy of its complete payload, unencoded. Truncation also typically removes special characters that are essential for XSS payload execution, so the reflected snippet would be inert and would not trigger the scanner's signature. Thus this is the opposite of a plausible cause for a false report.

• ✓

  The scanner's payload triggered a server error that echoed back the input without encoding

  Why this is correct

  When a scanner payload triggers an unhandled exception, the application's error handler may render a stack trace or generic error page that echoes back the offending input without applying the output encoding used by normal templates. The scanner observes its payload reflected verbatim in the response and flags it as XSS, but the vulnerability exists only in the error-handling path, which may not be reachable or exploitable under normal conditions. This is a well-known source of false positives because error pages often bypass security headers and encoding filters. Manual testing shows the normal pages encode all output, so this anomalous reflection is the likely explanation for the scanner's report.

Go deeper

Related to this question