Cybersecurity glossary
What are Trusted Types?
Learn what Trusted Types are, how they stop DOM XSS by restricting dangerous sinks to typed values, how to enforce them with CSP, and how to introduce policies safely.
Definition
Trusted Types is a browser security mechanism that restricts assignment of raw strings to dangerous DOM sinks—such as innerHTML, eval-like APIs, and script URLs—requiring values created through developer-defined policies that return TrustedHTML, TrustedScript, or TrustedScriptURL objects.
Why Trusted Types matter
Many DOM XSS bugs are one line: element.innerHTML = location.hash. Developers intend to render text; browsers interpret markup. Trusted Types change the default so raw strings are not accepted by those dangerous sinks unless a policy explicitly produces a trusted object.
Instead of hunting every sink forever, you move safety checks into a small number of policy factories that security review can focus on.
How Trusted Types work
Enable via CSP
Send require-trusted-types-for and trusted-types directives to lock down sinks and allow policy names.
Create named policies
Application code calls trustedTypes.createPolicy with sanitization or URL validation callbacks.
Policies return typed values
Callbacks produce TrustedHTML, TrustedScript, or TrustedScriptURL objects.
Sinks accept only trusted values
Assignments of plain strings to guarded sinks throw instead of executing attacker markup.
Report and enforce
Use Report-Only to find violations, fix libraries, then enforce.
Trusted type objects
TrustedHTML
For HTML interpretation sinks such as innerHTML and similar APIs.
TrustedScript
For sinks that evaluate JavaScript code strings.
TrustedScriptURL
For sinks that load script from a URL, such as script.src.
Policies
The only place raw untrusted data should become one of those types.
Enforcement vs weak policies
| Approach | Outcome |
|---|---|
| Enforcement + sanitizing policy | Strong DOM XSS reduction at reviewed chokepoints |
| Report-Only discovery | Safe inventory of string-to-sink usages |
| Pass-through createHTML(input) => input | Bypasses the security goal; avoid |
| Default policy catch-all | Convenient but high risk if it trusts too much |
Adoption checklist
- Inventory innerHTML, outerHTML, document.write, eval, new Function, and script URL assignments.
- Enable Trusted Types in Report-Only and collect violations.
- Introduce a small set of named policies with real sanitization/validation.
- Prefer safe DOM APIs (textContent, createElement) to avoid policies entirely.
- Upgrade or wrap third-party libraries that still assign raw strings.
- Lock trusted-types to explicit policy names; avoid open-ended defaults when possible.
- Enforce require-trusted-types-for once violation noise is actionable and fixed.
- Keep CSP script-src hardening; Trusted Types do not replace script allowlisting.
The practical takeaway
Trusted Types force dangerous DOM sinks to accept only policy-created trusted values instead of arbitrary strings. That concentrates DOM XSS defenses into reviewable policies.
Enforce them with CSP, sanitize inside policies—not with pass-through stubs—and combine with encoding and strict CSP for layered browser XSS resistance.
Related security terms
Frequently asked questions
What are Trusted Types in simple terms?
They make dangerous DOM APIs reject ordinary strings. Your app must pass values created by an approved policy that sanitizes or otherwise vouches for the data.
How do you turn Trusted Types on?
Use CSP directives such as require-trusted-types-for 'script' and trusted-types policy-name allowlists, then create policies with trustedTypes.createPolicy.
Do Trusted Types replace CSP nonces?
No. They address DOM sink safety. Nonces/hashes address which scripts may execute. Together they form strong layered XSS defense.
What breaks when enabling Trusted Types?
Libraries that assign raw strings to innerHTML, document.write, or script URLs fail until wrapped with policies or updated to safe APIs.
Can I start in report-only mode?
Yes. Use Content-Security-Policy-Report-Only with Trusted Types directives to discover violations before enforcing.
Are Trusted Types supported everywhere?
Support is strong in Chromium-based browsers and evolving elsewhere. Use progressive enforcement and feature detection.
Does a policy that returns unsanitized input help?
No. A pass-through policy defeats the control. Policies must sanitize HTML or otherwise guarantee safety for the sink.
References
Explore authoritative guidance and frameworks related to trusted types.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.