Cross-Site Scripting (XSS)
Untrusted input is reflected into a page without correct output encoding, letting an attacker run JavaScript in a victim’s browser session.
Overview
When user-controlled data reaches HTML, attribute, JavaScript, or URL contexts without context-aware encoding, the browser parses attacker markup as code. Reflected XSS echoes input from the request, stored XSS persists it server-side, and DOM XSS occurs entirely client-side via sinks like innerHTML or document.write.
How it works
When user-controlled data reaches HTML, attribute, JavaScript, or URL contexts without context-aware encoding, the browser parses attacker markup as code. Reflected XSS echoes input from the request, stored XSS persists it server-side, and DOM XSS occurs entirely client-side via sinks like innerHTML or document.write.
Example
Impact
Session hijacking, account takeover, credential theft, CSRF-token exfiltration, and full client-side compromise of the application for any victim who views the payload.
Detection
Inject context-probing markers across query, body, JSON, headers and path, then confirm reflection in an executable context. Rendering candidates in a real browser to verify actual script execution, rather than just checking for reflection, is what separates a confirmed finding from a false positive.
Prevention
- Context-aware output encoding (HTML, attribute, JS, URL) at the point of output.
- Prefer framework auto-escaping (React/Vue/Angular) and treat dangerouslySetInnerHTML as a red flag.
- Avoid dangerous DOM sinks; use textContent and safe APIs instead of innerHTML.
- Deploy a strict Content-Security-Policy with nonces/hashes as defense-in-depth.