JavaScript XSS Prevention: Complete Guide

Cross-Site Scripting (XSS) is an attack that injects malicious scripts into web pages viewed by other users. An attacker finds a way to insert JavaScript into your page. When another user visits that page, the attacker's script runs in their browser, in your application's context.

The script can steal cookies, capture keystrokes, redirect the user to a phishing site, or make requests to your API as the victim. XSS has been in the OWASP Top 10 web security risks for over two decades.

How XSS Works

The simplest example: a search page that echoes the user's query back into the page using innerHTML:

javascript

// Vulnerable code
const query = new URLSearchParams(location.search).get("q");
document.getElementById("results").innerHTML = `Results for: ${query}`;

An attacker sends a link with a crafted query parameter:

text

https://example.com/search?q=<img src=x onerror="alert('XSS')">

The page renders the attacker's img tag. The browser tries to load src="x", which fails. The onerror handler fires. The attacker's JavaScript executes.

This is reflected XSS: the malicious payload comes from the request and is reflected into the response. The attacker tricks a victim into clicking the link, and the script runs in the victim's browser.

The vulnerable line is the innerHTML assignment. Any time you set innerHTML with untrusted strings, you open the door to injection. The rest of this article shows how to keep that door shut.

Rule 1: Escape HTML Output

The fundamental defense is output encoding. Before inserting any untrusted string into HTML, convert special characters to their entity equivalents:

javascript

function escapeHtml(str) {
  const entityMap = {
    "&": "&",
    "<": "&lt;",
    ">": "&gt;",
    '"': "&quot;",
    "'": "&#x27;"
  };
  return str.replace(/[&<>"']/g, char => entityMap[char]);
}

Now the search page is safe:

javascript

const query = new URLSearchParams(location.search).get("q");
document.getElementById("results").innerHTML =
  `Results for: ${escapeHtml(query)}`;

When the attacker submits <img src=x onerror="alert('XSS')">, the browser renders it as text:

text

Results for: <img src=x onerror="alert('XSS')">

The user sees the angle brackets. The browser does not interpret them as HTML. This is the most important habit in XSS prevention: every string that comes from outside your code must be escaped before it touches the DOM.

Rule 2: Use Safe DOM APIs

innerHTML is the most dangerous DOM API because it parses strings as HTML. Safer alternatives exist for every use case:

Example: building a list from untrusted data the safe way:

javascript

// Unsafe
function renderUsersUnsafe(users) {
  const ul = document.getElementById("user-list");
  ul.innerHTML = users.map(u => `<li>${u.name}</li>`).join("");
}
 
// Safe
function renderUsersSafe(users) {
  const ul = document.getElementById("user-list");
  ul.textContent = ""; // Clear existing content
 
  users.forEach(u => {
    const li = document.createElement("li");
    li.textContent = u.name; // textContent escapes automatically
    ul.appendChild(li);
  });
}

The safe version creates elements programmatically. Each textContent assignment is automatically safe. No string interpolation touches the DOM as HTML.

Rule 3: Content Security Policy

Content Security Policy (CSP) is an HTTP header that tells the browser which sources of JavaScript are allowed. It is your last line of defense:

http

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

This policy says: scripts can only come from the same origin ('self'), and inline scripts (like onerror="...") are blocked. Even if an attacker manages to inject a script tag, the browser refuses to execute it.

A stricter policy for a modern app:

http

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-{random}';
  style-src 'self' 'unsafe-inline';
  img-src 'self' https: data:;
  connect-src 'self' https://api.example.com;
  frame-ancestors 'none';

Key directives:

Start with Content-Security-Policy-Report-Only to collect violation reports without breaking anything. Then switch to enforcing mode.

Rule 4: Sanitize HTML When Unavoidable

Sometimes you must render user-provided HTML: a rich text editor, a comment with formatting, or an email preview. Use a sanitizer library that parses the HTML and strips dangerous tags and attributes:

javascript

import DOMPurify from "dompurify";
 
const userProvidedHtml = '<p>Nice <b>post</b>!</p><script>alert("xss")</script>';
 
const safeHtml = DOMPurify.sanitize(userProvidedHtml);
// Result: '<p>Nice <b>post</b>!</p>'
 
document.getElementById("comment-body").innerHTML = safeHtml;

DOMPurify removes <script> tags, onerror attributes, javascript: URLs, and everything else that could execute code. It allows safe formatting tags like <b>, <i>, <p>, and <a>.

Never write your own sanitizer. The attack surface is too large. Use a well-maintained library.

DOM-Based XSS

DOM-based XSS happens entirely in the browser. The payload never reaches the server. Common sinks for DOM-based XSS:

javascript

// Unsafe DOM sinks
element.innerHTML = userInput;           // HTML injection
element.outerHTML = userInput;           // HTML injection
document.write(userInput);               // HTML injection
eval(userInput);                         // Code execution
new Function(userInput);                 // Code execution
setTimeout(userInput, 1000);             // Code execution (if string)
location.href = userInput;               // Redirect to javascript: URL

Any data from location, document.referrer, document.cookie, window.name, or postMessage is potentially attacker-controlled. Treat it as untrusted.

javascript

// Unsafe: reading from location and writing to innerHTML
const hash = location.hash.slice(1);
document.getElementById("output").innerHTML = hash;
 
// Safe: reading from location and writing to textContent
const hash = location.hash.slice(1);
document.getElementById("output").textContent = hash;

Safe Rendering Checklist

Before inserting any dynamic content into the DOM, ask these questions:

1. Does this data come from outside my code? User input, URL parameters, API responses, cookies, localStorage, postMessage -- all untrusted.
2. Am I using a safe API? textContent, createElement, setAttribute -- safe. innerHTML, outerHTML, document.write -- unsafe without sanitization.
3. Am I escaping properly? HTML entities for HTML context. encodeURIComponent() for URL context. Never concatenate strings into executable contexts.
4. Do I have CSP enabled? A CSP header with script-src 'self' blocks injected scripts even if you miss an escape.

See safe DOM rendering patterns for a deeper dive into each rendering context.