XSS definition
Cross-site scripting (XSS) is a web vulnerability that lets attackers inject malicious scripts into pages viewed by other users. When a victim's browser runs the script, the attacker can steal session tokens, capture keystrokes, change page content or perform actions as the user. Output encoding and a Content Security Policy are the main defenses.
How does cross-site scripting work?
XSS happens when an application includes untrusted data in a web page without properly encoding it for the context where it appears. Suppose a product review form accepts text and the site displays reviews as raw HTML. An attacker submits a review containing a script tag. Every visitor who views the product page now runs the attacker's JavaScript inside the trusted site, with access to whatever that page can access.
Because the script runs in the site's origin, it can read data on the page, call the site's APIs as the logged-in user, or send information to an attacker's server. Session cookies marked HttpOnly cannot be read by scripts, but attackers can still perform actions as the user.
Types of XSS
XSS is usually classified by where the malicious input is stored and how it reaches the victim's browser. The distinction matters for testing, because each type is found in different parts of an application, and for impact, because stored XSS can affect every visitor to a page without any further action from the attacker.
- Stored XSS: the payload is saved, for example in a comment or profile, and served to every viewer.
- Reflected XSS: the payload comes from the current request, such as a search parameter in a crafted link.
- DOM-based XSS: client-side JavaScript writes untrusted data into the page, often from the URL fragment.
How to prevent XSS
The core defense is context-aware output encoding: data placed in HTML, attributes, JavaScript or URLs must be encoded for that specific context. Modern frameworks such as React, Angular and Vue escape values in templates by default, which removes most XSS risk, but escape hatches like dangerouslySetInnerHTML, innerHTML and v-html bypass this protection and must be used only with sanitized content.
When users must submit rich HTML, such as formatted comments, sanitize it with a well-maintained library like DOMPurify using an allow-list of safe tags. Add a strict Content Security Policy that blocks inline scripts and limits script sources, so an injection that slips through cannot easily execute. Set cookies as HttpOnly, Secure and SameSite to reduce what a successful attack can steal.
Finding XSS vulnerabilities
Security testers probe every input that is reflected or stored, including form fields, URL parameters, headers, file names and JSON fields rendered by frontends. Tools such as Burp Suite and ZAP automate parts of this, while manual review catches DOM-based issues in client-side code. Static analysis can flag dangerous sinks like innerHTML. Regular testing matters because new features, third-party widgets and rich text editors frequently reintroduce XSS into applications that were previously clean.
Why XSS is still common
Despite framework protections, XSS persists through legacy pages, markdown and rich text features, admin panels, email templates and integrations that render third-party content. It falls under the injection category of the OWASP Top 10. Nexzem's application security testing checks both server-rendered and single-page applications for XSS and helps teams adopt CSP without breaking existing functionality.