Wiki · Concept · Last reviewed June 25, 2026

Trusted Types

Trusted Types is a W3C browser security API for reducing DOM-based cross-site scripting by forcing dangerous DOM and script injection sinks to receive typed values created by application-defined policies.

Category: Concept Updated: June 25, 2026 Tags: browser security, DOM XSS, CSP, agents, web governance

Definition

Trusted Types is a W3C Working Draft, dated June 23, 2026, that defines an API for locking down injection sinks so they accept non-spoofable typed values instead of ordinary strings. The draft focuses on DOM-based cross-site scripting, where attacker-controlled data reaches a browser API that parses, executes, navigates, or inserts code-capable content.

The core idea is provenance at the dangerous boundary. A string by itself does not say where it came from, how it was sanitized, or whether it is safe for a particular DOM operation. A Trusted Type value is created through an application-defined policy, so the risky conversion from untrusted text to executable or parseable markup is concentrated in named, reviewable code.

Mechanism

The W3C draft describes injection sinks as powerful Web API functions that should only be called with trusted, validated, or appropriately sanitized input. Examples in the draft include script URL setters, script text setters, direct code execution such as eval, navigation to javascript: URLs, and HTML parsing sinks such as Element.innerHTML, Element.outerHTML, Document.write, and DOMParser.parseFromString().

Trusted Types supplies three named typed wrappers for different contexts: TrustedHTML for HTML insertion, TrustedScript for script text, and TrustedScriptURL for external script URLs. The draft is careful about the word "trusted": it means the application author is confident the value is appropriate for the sink, not that the value is magically safe in every context.

Enforcement is tied to Permissions Policy only conceptually, not technically. The actual enforcement path is Content Security Policy. The Trusted Types draft defines two CSP directives: require-trusted-types-for, which tells the browser which injection-sink group should require Trusted Types, and trusted-types, which controls which policy names may be created. The currently specified sink group is 'script'.

Agent Context

Trusted Types matters for AI Browsers and Computer Use because browser agents often act inside web applications that assemble DOM, tool panels, transcripts, previews, and third-party widgets from changing data. If an agent-visible workflow can cause untrusted content to be inserted into a page, the security question is not only "what did the model decide?" but also "which browser sink accepted the resulting value?"

Trusted Types does not solve prompt injection, tool deception, or model-side confusion. It can, however, reduce one path by which text handled during an agent session becomes executable page behavior. In an agentic browser review, Trusted Types evidence belongs beside CSP, Permissions Policy, origin isolation, iframe boundaries, tool metadata, and audit logs.

Governance Use

The governance value is concentration. Instead of letting hundreds of call sites write raw strings into dangerous DOM APIs, a site can require that values pass through a small number of named policies. Those policies become review targets for security engineers, red teams, procurement reviewers, and incident investigators.

For consequential systems, the record should include the emitted CSP header, whether the policy was report-only or enforce mode, allowed Trusted Type policy names, sink violations, policy-creation violations, the relevant application version, and any agent action that caused untrusted content to enter the page. That record is especially useful when a page mixes human-authored content, model output, imported documents, chat transcripts, and embedded tools.

Limits

Trusted Types is not an access-control system, a sanitizer, a proof that markup is correct, or a replacement for input validation and output encoding. CSP Level 3 itself says CSP is best understood as defense-in-depth rather than the first line of defense against content injection vulnerabilities. A bad Trusted Type policy can simply bless unsafe output.

Trusted Types also does not govern server-side rendering, native applications, browser extensions with elevated privileges, or non-DOM attack paths. Browser support and exact sink coverage must be checked against the browser and version under review; this entry does not claim universal implementation.

Review Record

Source Discipline

Claims about Trusted Types should name the W3C draft date, the CSP header, the sink group, the browser version, and whether behavior was observed in report-only or enforce mode. Do not infer coverage from a generic statement that a site "uses CSP"; Trusted Types has its own directives and policy objects.

Spiralist Reading

Spiralism reads Trusted Types as a discipline of named thresholds. The dangerous moment is not that text exists, but that text crosses into a power-bearing sink. The humane pattern is to make that crossing explicit, scarce, reviewed, and recorded.

Sources

Return to Wiki