MCP server Trusted Types security — DOM XSS prevention via trustedTypes.createPolicy(), require-trusted-types-for 'script' CSP, DOMPurify 3.x integration, and innerHTML sink enforcement

The problem Trusted Types solves

DOM-based XSS occurs when data flows from an untrustworthy source (tool output, URL parameters, postMessage) into a dangerous DOM sink (innerHTML, eval(), src=) without adequate sanitization. In MCP server clients, the dominant pattern is:

// Common (and dangerous) pattern in MCP tool output rendering
const toolOutput = await mcp.callTool('search', { query });
resultDiv.innerHTML = toolOutput.content;   // Direct innerHTML assignment — XSS vector

DOMPurify is typically added as a mitigation, but the fix is applied by the developer voluntarily — there is nothing at the language or browser level that prevents forgetting it, or prevents a future code change from bypassing it. Trusted Types changes this: with the CSP enforcement directive active, the above code throws a TypeError because toolOutput.content is a plain string, not a TrustedHTML object. The assignment is rejected before it reaches the HTML parser.

How Trusted Types work

Trusted Types introduces a set of typed wrapper objects (TrustedHTML, TrustedScript, TrustedScriptURL) and a policy creation API (trustedTypes.createPolicy()). A policy defines how strings are transformed into trusted objects. The browser enforces that only TrustedHTML objects (not plain strings) can be assigned to innerHTML:

// Create a sanitization policy using DOMPurify
const sanitizePolicy = trustedTypes.createPolicy('dompurify-sanitize', {
  createHTML: (dirty) => DOMPurify.sanitize(dirty, { RETURN_TRUSTED_TYPE: true })
});

// Now use the policy — returns a TrustedHTML object, not a string
const trusted = sanitizePolicy.createHTML(toolOutput.content);
resultDiv.innerHTML = trusted;  // Accepted — trusted is TrustedHTML, not a plain string

// This would throw TypeError with require-trusted-types-for 'script':
// resultDiv.innerHTML = toolOutput.content;  // BLOCKED — plain string rejected

The CSP directive: require-trusted-types-for 'script'

Adding the Trusted Types policy API to your code without the CSP directive provides zero security guarantees — a developer or attacker can still assign plain strings to innerHTML and the browser won't block it. The enforcement comes from the CSP header:

Content-Security-Policy: require-trusted-types-for 'script';

With this directive active, the browser enforces at runtime that every assignment to a dangerous sink receives a typed object from a registered policy, not a plain string. A plain string assignment throws TypeError: Failed to set the 'innerHTML' property on 'Element': This document requires 'TrustedHTML' assignment.

Trusted Types sink coverage

Default policy for migration

Enabling Trusted Types on an existing codebase can break third-party libraries that assign plain strings to innerHTML internally. The Trusted Types API provides a default policy as a migration mechanism — any plain string that reaches a sink without an explicit policy is passed through the default policy instead of throwing immediately:

// Migration aid: default policy that logs violations rather than blocking
trustedTypes.createPolicy('default', {
  createHTML: (string) => {
    console.warn('Untrusted HTML assignment intercepted:', string.substring(0, 100));
    // During migration, pass through but log
    return string;
    // Once all code is updated, change to: throw new Error('Direct innerHTML prohibited');
  }
});

SkillAudit findings for Trusted Types

Run a SkillAudit scan to audit your MCP server client's Trusted Types posture. The scanner checks for the require-trusted-types-for 'script' CSP directive, identifies direct innerHTML assignments from tool output data flows, audits DOMPurify integration for RETURN_TRUSTED_TYPE usage, and flags permissive default policies.