Trusted Types is a browser feature that makes dangerous DOM functions, such as innerHTML, accept only values produced by a policy you wrote. A plain string causes a TypeError. That turns a quiet DOM XSS hole into a visible error you can find and fix. MDN lists it as Baseline 2026, newly available.
The problem it targets
DOM XSS happens when script takes attacker influenced data and hands it to a sink that parses it as HTML or runs it as code. Sinks are scattered across large codebases and third party libraries, so audits miss some.
Trusted Types moves the check into the browser. MDN describes the API as ensuring input passes through a transformation function, usually a sanitizer, before it reaches an API that could execute it.
How policies work
You define a policy with trustedTypes.createPolicy(). Each policy offers methods for the three kinds of sink and returns a typed object: TrustedHTML, TrustedScript or TrustedScriptURL.
const policy = trustedTypes.createPolicy("sanitize", {
createHTML: (input) => DOMPurify.sanitize(input),
});
el.innerHTML = policy.createHTML(userInput);
The API supplies no sanitizer of its own. The rules are yours, which is also why policies must be small and reviewed. Few policies means a small amount of code to audit.
Turning enforcement on
Two Content Security Policy directives control it:
require-trusted-types-for 'script'makes the browser throw a TypeError when a string reaches an injection sink.trusted-typeslists the policy names that may be created. Creating a policy with an unlisted name throws an error.
Content-Security-Policy: require-trusted-types-for 'script'; trusted-types sanitize
OWASP lists Trusted Types as a control that can eliminate whole classes of DOM XSS, while still saying a CSP should not be your primary defence.
Rolling it out without breaking the site
MDN's page describes a default policy named default. It receives any string passed to a sink while enforcement is on, and its return value is used. If it returns null or undefined, a TypeError is thrown. MDN recommends using it only while migrating legacy code.
A practical order:
- Find sink usage with a code search and replace what you can with
textContentor node creation. - Create one sanitizing policy for the places that need markup.
- Use a temporary default policy that logs every hit so you can find the remaining callers.
- Enable enforcement, remove the default policy, and keep the policy list short.
Check report options in your browser documentation before enabling it for all users, since the MDN page does not cover report-only mode.
Older browsers
MDN notes the API may not work in older browsers. It also shows a tiny fallback that returns the policy options object, so sanitization still runs even though the sink receives a plain string.
Quick check
Does Trusted Types replace output encoding?
No. It guards DOM sinks in the browser. Server side output encoding and sanitization are still needed.
Does it write the sanitizer for me?
No. You supply the transformation, usually with a maintained sanitizer library.
Sources
Last reviewed: 19 October 2026.
