A pentest report lands: there is a stored XSS vulnerability in a comment field in your production application. How do you triage and respond?
Expected Points
- ✓Assess immediate blast radius: can unauthenticated users view profiles? Has the bio field been abused (check logs for suspicious content)? Escalate severity if any admin accounts have been targeted.3
- ✓Apply a compensating control if a full fix takes time: temporarily strip/escape the bio field on render (CSP `script-src 'none'` as emergency measure, or disable bio display), and sanitize/wipe existing malicious payloads.3
- ✓Check whether the `HttpOnly` cookie flag is set — if it is, `document.cookie` theft is already blocked and the attack is less severe. If not, this increases urgency.2
- ✓Fix root cause: output-encode (contextual HTML escaping) all user-supplied content on render, and use a sanitization library (DOMPurify) for fields that genuinely need rich HTML.3
- ✓Deploy a strong CSP (`script-src 'nonce-...'`, no `unsafe-inline`) as defense-in-depth so future XSS can't execute injected scripts.2
- ✓Audit all other free-text / rich-text fields in the app for the same pattern — this is likely not the only instance.2
- ✓Document the finding in the pentest tracker, track remediation, and schedule a verification test to close the finding.1
Stored XSS in production is high severity because every user who views the affected page runs the attacker's code. Triage combines exploitability (what can the payload do?), exposure (who sees the page?), and urgency of the fix or compensating control.