XSS Prevention in Chrome Extensions

Cross-site scripting in Chrome extensions is more dangerous than XSS in regular web applications. A web app's XSS is confined to that app's origin and permissions. An extension's XSS inherits the extension's permissions — which often include access to all URLs, storage of sensitive data, tab manipulation, and the ability to inject scripts into any page the user visits.

This guide covers every XSS vector specific to Chrome extensions, with concrete vulnerable-versus-safe code examples, sanitization strategies, and a prevention checklist you can use to audit your own extension.

Extension-Specific XSS Attack Vectors#

Regular web XSS focuses on reflected, stored, and DOM-based vectors. Extensions add several unique attack surfaces that web developers are not accustomed to thinking about.

Vulnerable vs. Safe Code#

The difference between vulnerable and safe extension code often comes down to a single function call. Let us walk through the most common patterns.

Sanitization Strategies#

There are three tiers of protection against XSS in extensions, and you should use all three.

Tier 1: Avoid innerHTML entirely. Use textContent for text, createElement for structure, and classList / setAttribute for styling. This eliminates the most common XSS vector with zero overhead.

Tier 2: When you need HTML rendering, use DOMPurify. It is the gold standard for HTML sanitization. Configure it with the most restrictive allowlist that serves your use case.

import DOMPurify from 'dompurify';
 
// Strictest config: only allow basic formatting
const STRICT_CONFIG = {
  ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'p', 'br', 'ul', 'ol', 'li'],
  ALLOWED_ATTR: [],
  ALLOW_DATA_ATTR: false,
};
 
// Moderate config: allow links but sanitize href
const MODERATE_CONFIG = {
  ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'p', 'br', 'a', 'ul', 'ol', 'li', 'code'],
  ALLOWED_ATTR: ['href', 'title'],
  ALLOW_DATA_ATTR: false,
  ADD_HOOKS: true,
};
 
// Hook to ensure only safe URLs in href attributes
DOMPurify.addHook('afterSanitizeAttributes', (node) => {
  if (node.hasAttribute('href')) {
    const href = node.getAttribute('href') || '';
    if (!href.startsWith('https://') && !href.startsWith('http://')) {
      node.removeAttribute('href');
    }
  }
});

Tier 3: Content Security Policy. Manifest V3 enforces a strict CSP by default, but you can tighten it further. The default CSP for MV3 extensions is:

{
  "content_security_policy": {
    "extension_pages": "script-src 'self'; object-src 'self'"
  }
}

This blocks inline scripts and eval(). Do not loosen it. If your code needs unsafe-eval or unsafe-inline, that is a design problem you should fix rather than a CSP restriction you should weaken.

Sanitization Library Comparison#

If you need HTML rendering (and therefore sanitization), these are the established options.

Trusted Types deserve special attention. They are a browser-native API that prevents DOM XSS at the platform level. When you enable Trusted Types, the browser rejects any attempt to assign a raw string to innerHTML, document.write, or other dangerous sinks. You must create a "policy" that explicitly sanitizes values before assignment.

// Enable Trusted Types via CSP header or meta tag in your HTML
// <meta http-equiv="Content-Security-Policy" content="trusted-types myPolicy">
 
if (window.trustedTypes) {
  const policy = trustedTypes.createPolicy('myPolicy', {
    createHTML: (input: string) => {
      return DOMPurify.sanitize(input, {
        ALLOWED_TAGS: ['b', 'i', 'p', 'br'],
        ALLOWED_ATTR: [],
      });
    },
  });
 
  // Now innerHTML requires a TrustedHTML value
  const container = document.getElementById('content')!;
  container.innerHTML = policy.createHTML(userInput); // Sanitized automatically
  // container.innerHTML = userInput; // This throws a TypeError!
}

Common Vulnerability Patterns in Real Extensions#

These are patterns found in real extensions during security audits. Each one is exploitable.

Pattern 1: URL parameter injection in options page. Many extensions pass data to their options page via URL fragments: options.html#setting=theme. If the options page reads location.hash and injects it into the DOM, an attacker can craft a link that executes arbitrary JavaScript when the user opens it.

Pattern 2: postMessage from web-accessible resources. If your extension has a web-accessible page that listens for window.postMessage, any website can send messages to it. Without origin validation, this is a direct XSS vector.

// DANGEROUS: No origin check on postMessage
window.addEventListener('message', (event) => {
  document.getElementById('display').innerHTML = event.data.content;
});
 
// SAFE: Validate origin and sanitize
window.addEventListener('message', (event) => {
  if (event.origin !== 'https://trusted-domain.com') return;
  const sanitized = DOMPurify.sanitize(event.data.content);
  document.getElementById('display').innerHTML = sanitized;
});

Pattern 3: Rendering fetched API data. Extensions that fetch data from external APIs and render it in the popup often trust the API response implicitly. If the API is compromised or returns user-generated content, unsanitized rendering creates XSS.

Test Your Security Knowledge#

XSS Prevention Audit Checklist#

Use this checklist to audit your extension for XSS vulnerabilities. Go through every file in your extension and check each item.

Extension security is not glamorous work. Nobody notices when your XSS prevention is working correctly. But one vulnerability in an extension with elevated permissions can compromise every website your users visit. The cost of prevention — using textContent, adding DOMPurify, validating messages — is tiny compared to the cost of a breach. Invest the time upfront, audit regularly, and treat every piece of dynamic data as hostile until proven otherwise.