Cross-Site Scripting (XSS) Explained

1What Is Cross-Site Scripting?

Cross-site scripting, or XSS, is a vulnerability that lets an attacker inject malicious JavaScript into a web page so it runs in other users' browsers. Because the script executes in the victim's session, it can do anything that user could do on the site.

It occurs when an application takes untrusted input — a comment, a URL parameter, a profile field — and places it into a page without encoding or sanitizing it. The browser cannot tell the injected script from the site's own code, so it runs it. XSS is one of the most common web vulnerabilities and sits on the OWASP Top 10.

2How XSS Works

The core problem mirrors SQL injection: untrusted data is treated as code. If a site echoes a comment straight into the page, an attacker can submit a script instead of text.

• Attacker submits a comment containing: <script>steal(document.cookie)</script>
• The site stores it and renders it verbatim into the page HTML.
• Every visitor who views the comment runs the attacker's script.
• The script executes with the victim's cookies and session, in their browser.

3The Three Types of XSS

XSS is classified by where the malicious script comes from and how it reaches the victim.

• Stored XSS: the payload is saved on the server (in a comment or profile) and served to every viewer. The most dangerous.
• Reflected XSS: the payload is in a request, like a URL parameter, and reflected straight back in the response. Usually delivered via a malicious link.
• DOM-based XSS: the vulnerability is entirely in client-side JavaScript that writes untrusted data into the page without ever involving the server.

4The Primary Fix: Output Encoding

The main defense against XSS is context-aware output encoding: whenever you insert untrusted data into a page, encode it so special characters become harmless text rather than markup. A less-than sign becomes an entity and can no longer open a script tag.

• Encode for the context — HTML body, HTML attribute, JavaScript, and URL each need different encoding.
• Modern frameworks like React, Angular, and Vue auto-encode interpolated values by default.
• Use templating that escapes by default rather than raw string building.
• For rich HTML input, sanitize with a vetted library such as DOMPurify instead of trusting it.

5Defense in Depth

Encoding stops injection at the source; additional layers limit damage if something slips through.

• Content Security Policy (CSP): a header that restricts which scripts may run, blocking inline or unknown-origin code.
• HttpOnly cookies: keep session cookies out of JavaScript's reach so a script cannot read them.
• Avoid dangerous DOM sinks: prefer textContent over innerHTML for untrusted data.
• Input validation: reject clearly malformed input as an extra, not primary, layer.

6Common Mistakes to Avoid

XSS persists because of a few recurring development habits.

• Inserting user input into the DOM with innerHTML instead of textContent.
• Using dangerouslySetInnerHTML or v-html on untrusted content without sanitizing.
• Encoding for the wrong context, such as HTML-encoding data placed inside a script block.
• Relying only on input filtering and skipping output encoding entirely.

7Best Practices

A few consistent practices keep applications free of cross-site scripting.

• Encode all untrusted output for its exact context — HTML, attribute, JavaScript, or URL.
• Prefer frameworks that escape by default and avoid raw innerHTML with user data.
• Sanitize any rich HTML input with a maintained library such as DOMPurify.
• Deploy a strict Content Security Policy to block inline and unknown-origin scripts.
• Set session cookies HttpOnly so injected scripts cannot read them.

8Key Takeaways

The essentials of preventing XSS come down to a few durable ideas.

• XSS runs attacker JavaScript in victims' browsers by injecting it into a page.
• It happens when untrusted input is rendered without encoding or sanitizing.
• The three types are stored, reflected, and DOM-based, differing in the script's origin.
• Context-aware output encoding is the primary fix; frameworks do much of it for you.
• Add a Content Security Policy and HttpOnly cookies as defense in depth.

9Frequently Asked Questions

Q: What is the difference between stored and reflected XSS? A: Stored XSS saves the malicious script on the server so it is served to every visitor of the affected page. Reflected XSS carries the script in a request, such as a URL parameter, and is echoed straight back, so it typically requires tricking a victim into clicking a crafted link.

Q: How do I prevent XSS? A: Use context-aware output encoding whenever you put untrusted data into a page, rely on frameworks that escape by default, sanitize any rich HTML with a vetted library, and add a Content Security Policy plus HttpOnly cookies as extra layers of defense.

Q: Does React prevent XSS automatically? A: React escapes values embedded in JSX by default, which prevents most XSS. Protection breaks when you use dangerouslySetInnerHTML with untrusted content, so any raw HTML you inject must be sanitized first with a tool like DOMPurify.

Q: What is a Content Security Policy? A: A CSP is an HTTP response header that tells the browser which sources of scripts and other resources are allowed to load and run. A strict policy can block inline scripts and unknown origins, sharply limiting what an injected XSS payload is able to do.