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.

• ✗

  Take the application offline immediately

  Why it's wrong here

  Taking the application offline immediately is an overreaction for most XSS findings because reflected XSS typically requires victim interaction (e.g., clicking a malicious link) and does not directly compromise the server or data at rest. Immediate shutdown can cause significant business disruption and is usually reserved for actively exploited critical vulnerabilities such as remote code execution. Proper incident response prioritizes containment—such as WAF rules—before considering downtime, and the decision to take the app offline should be coordinated with stakeholders based on a risk assessment.

• ✓

  Implement a web application firewall (WAF) rule to block XSS payloads

  Why this is correct

  Implementing a web application firewall (WAF) rule (e.g., using the OWASP Core Rule Set) immediately blocks known XSS payloads at the edge, providing a temporary mitigation that reduces exploitability without taking the application offline. The WAF can be tuned to inspect query strings, POST bodies, and headers for attack signatures, allowing the security team to protect users while the development team prepares a permanent patch. This is a standard first-line response for web vulnerabilities, but the WAF rule should be considered a compensating control, not a substitute for secure coding.

• ✗

  Ignore the finding because XSS is low risk

  Why it's wrong here

  Ignoring the finding because XSS is 'low risk' is a common misconception: the severity of XSS depends heavily on context, such as whether it is reflected or stored, whether session cookies are HttpOnly, and the sensitivity of the data accessible via the application. For example, stored XSS can execute in every user's browser, enabling session hijacking, defacement, or malware distribution, which can be rated critical. Even lower-severity reflected XSS can be leveraged in targeted phishing attacks, so it should always be triaged with the standard CVSS scoring rather than dismissed out of hand.

• ✗

  Notify law enforcement immediately

  Why it's wrong here

  Notifying law enforcement immediately is premature because an XSS vulnerability discovery is not necessarily evidence of a cybercrime—no intrusion or criminal activity has been confirmed. Law enforcement involvement might be required after a confirmed data breach or if the attacker is actively exploiting the flaw, but that is a later step in incident response, not an initial reaction. For an internal vulnerability assessment, the correct protocol is to escalate to the security team, validate the finding, and begin remediation before considering external reporting.

• ✓

  Report the vulnerability to the development team for remediation

  Why this is correct

  Reporting the vulnerability to the development team is the essential permanent remediation step, as the root cause lies in the application code that fails to properly validate input or encode output. The report should include the specific endpoint, parameter, payload, and a description of the impact so developers can reproduce the issue and apply the OWASP-recommended defense-in-depth approach, such as context-aware output encoding and a Content Security Policy. Without this step, the application remains vulnerable even if temporary WAF rules are in place, so proper reporting closes the loop for secure development.

Go deeper

Related to this question