# Trusted Types

## Editor’s Draft, 1 January 1970

This version:
  https://w3c.github.io/webappsec-trusted-types/dist/spec/
Feedback:
  public-webappsec@w3.org with subject line “`[trusted-types] … message topic …`” (archives)
Editors:
  Krzysztof Kotowicz (Google LLC)
  Mike West (Google LLC)

Copyright © 1970 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.

## Abstract

An API that allows applications to lock down powerful APIs to only accept non-spoofable, typed values in place of strings to prevent vulnerabilities caused by using these APIs with attacker-controlled inputs.

## Status of this document

This is a public copy of the editors’ draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don’t cite this document other than as work in progress.

Changes to this document may be tracked at https://github.com/w3c/webappsec.

The (archived) public mailing list public-webappsec@w3.org (see instructions) is preferred for discussion of this specification. When sending e-mail, please put the text “trusted-types” in the subject, preferably like this: “[trusted-types] …summary of comment…”

This document was produced by the Web Application Security Working Group.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 March 2019 W3C Process Document.

## 1. Introduction

This section is not normative.

Certain classes of vulnerabilities occur when a web application takes a value from an attacker-controlled source (e.g. the document URL parameter, or postMessage channel) and passes that value, without appropriate sanitization to one of the injection sinks - various Web API functions with powerful capabilities.

These types of issues are traditionally difficult to prevent. Applications commonly call those injection sinks with attacker-controlled values without authors realizing it, since it’s not clear if the input was attacker-controlled when invoking the injection sink. Due to the dynamic nature of JavaScript it’s also difficult to ascertain that such pattern is not present in a given program. It is often missed during manual code reviews, and automated code analysis. As an example, if `aString` contains untrusted data, `foo[bar] = aString` is a statement that potentially can trigger a vulnerability, depending on a value of `foo` and `bar`.

This document focuses on prevening DOM-Based Cross-Site Scripting that occurs when attacker-controlled data reaches § 2.1.2 DOM XSS injection sinks, as that eventually causes execution of the script payload controlled by the attacker. DOM XSS is prevalent in the web applications as there are over 60 different injection sinks (e.g. `Element.innerHTML`, or `Location.href` setters).

This document defines Trusted Types - an API that allows applications to lock down injection sinks to only accept non-spoofable, typed values in place of strings. These values can in turn only be created from application-defined policies, allowing the authors to define rules guarding dangerous APIs, reducing the attack surface to small, isolated parts of the web application codebase, which are substantially easier to safeguard, monitor and review.

### 1.1. Goals

- Minimize the likelihood of client-side vulnerabilities that occur when calling powerful Web APIs with untrusted data - for example, minimize the likelihood of DOM XSS.

- Encourage a design in which security decisions are encapsulated within a small part of the application.

- Reduce security review surface for complex web application codebases.

- Allow the detection of vulnerabilities similar to how regular programming errors are detected and surfaced to the developers, with the assist of dynamic and static analysis tools.

### 1.2. Non-goals

- Prevent, or mitigate the result of injections into server-side generated markup, in specific reflections into the body of the scripts running in a document. To address server-side XSS vectors, we recommend existing solutions like templating systems or CSP script-src.

- Address resource confinement, e.g. to prevent data exfiltration, or connecting to external sources via [Fetch].

- Control subresource loading. Trusted Types aim to allow the authors to control loading resources that can script the current document, but not other subresources.

- Prevent cross-origin JavaScript execution (for example, Trusted Types don’t guard loading new documents with JavaScript code via `data:` URLs).

- Prevent malicious authors of the web application’s JavaScript code from being able to bypass the restrictions; attempting to protect against malicious authors would result in an overtly complex and not-practical design.

### 1.3. Use cases

- An author maintains a complex web application written in a framework that uses a secure templating system to generate the UI components. The application also depends on 3rd party client-side libraries that perform auxiliary tasks (e.g. analytics, performance monitoring). To ensure that none of these components introduce DOM XSS vulnerabilities, author defines a Trusted Type policy in the templating library and enables the enforcement for the DOM XSS injection sinks.

- An existing web application interacts with the DOM mostly using XSS-safe patterns (i.e. withour using DOM XSS injection sinks). In a few places, however, it resorts to using risky patterns like loading additional script using JSONP, calling into `innerHTML` or `eval`.

  Review finds that those places do not cause XSS (e.g. because user-controlled data is not part of the input to those sinks), but it’s hard to migrate the application off using these patterns.

  As such, CSP cannot be enforced on this application (without resorting to an unsafe version using `'unsafe-eval' 'unsafe-inline'`). Additionally, it’s possible some codebase with DOM XSS flaws was not included in a review, or will be introduced in the future.

  To address this risk, the author converts the reviewed parts to using Trusted Types, and enables Trusted Type enforcement. Addditional places using the injection sinks, should they exist in the future, are correctly blocked and reported.

- A security team is tasked with assuring that the client-side heavy application code does not contain XSS vulnerabilities. Since the server side code is homogeneous (it’s moslty an API backend), and the application enforces Trusted Types, the review only focuses on the Trusted Type policies and their rules. Later on the reviewed policy names are allowed in the 'trusted-types' CSP directive, safe for the developers to use.

  Any additonal code, including the code of often-changing dependencies, can be excluded from the review, unless it creates a Trusted Type policy. Without it, the code cannot cause a DOM XSS.

## 2. Framework

### 2.1. Injection sinks

This section is not normative.

An injection sink is a powerful Web API function that should only be called with trusted, validated or appropriately sanitized input. Calling the injection sink with attacker-controlled (i.e. injected) inputs has undesired consequences and is considered a security vulnerability.

Note: The exact list of injection sinks covered by this document is defined in § 4 Integrations.

It’s difficult to determine if a given application contains such a vulnerability (e.g. if it is vulnerable to DOM XSS) only by analyzing the invocations of injection sinks, as their inputs (usually strings) do not carry the information about their provenance. For example, while the application might intentionally call `eval()` with dynamically created inputs (e.g. for code obfuscation purposes), calling `eval()` on strings supplied by the attacker is definitely a security vulnerability - but it’s not easy to distinguish one from the other.

This document organizes the injection sinks into groups, based on the capabilities that sinks in a given group have. Enforcement for groups is controlled via trusted-types-sink-group values.

#### 2.1.1. HTML injection sinks

This section is not normative.

HTML injection sinks parse input strings into a DOM tree. Since HTML parsers can create arbitrary elements, including scripts, and set arbitrary attributes, enabling the enforcement of any trusted-types-sink-group also implies enforcing types for HTML injection sinks.

Examples of HTML injection sinks include:

- Functions that parse & insert HTML strings into the document like Element.innerHTML, Element.outerHTML setter, or `Document.write`.

- Functions that create a new same-origin `Document` with caller-controlled markup like `parseFromString()`,

#### 2.1.2. DOM XSS injection sinks

This section is not normative.

DOM XSS injection sinks evaluate an input string value in a way that could result in DOM XSS if that value is untrusted.

Examples of include:

- Setters for `Element` attributes that accept a URL of the code to load like `HTMLScriptElement.src`,

- Setters for `Element` attributes that accept a code to execute like `HTMLScriptElement.text`,

- Functions that execute code directly like `eval`,

- Navigation to 'javascript:' URLs.

Guarding DOM XSS injection sinks is controlled by the trusted-types-sink-group named 'script'.

### 2.2. Trusted Types

To allow the authors to control values reaching injection sinks, we introduce § 2.2 Trusted Types. The following list of Trusted Types indicating that a given value is trusted by the authors to be used with an injection sink in a certain context.

Note: Trusted in this context signifies the fact that the application author is confident that a given value can be safely used with an injection sink - she trusts it does not introduce a vulnerability. That does not imply that the value is indeed safe.

Note: This allows the authors to specify the intention when creating a given value, and the user agents to introduce checks based on the type of such value to preserve the authors' intent. For example, if authors intend a value to be used as an HTML snippet, an attempt to load a script from that value would fail.

Note: All Trusted Types wrap over an immutable string, specified when the objects are created. These objects are unforgeable in a sense that there is no JavaScript-exposed way to replace the inner string value of a given object - it’s stored in an internal slot with no setter exposed.

Note: All Trusted Types stringifiers return the inner string value. This makes it easy to incrementally migrate the application code into using Trusted Types in place of DOM strings (it’s possible to start producing types in parts of the application, while still using and accepting strings in other parts of the codebase). In that sense, Trusted Types are backwards-compatible with the regular DOM APIs.

#### 2.2.1. TrustedHTML

The TrustedHTML interface represents a string that a developer can confidently insert into an injection sink that will render it as HTML. These objects are immutable wrappers around a string, constructed via a `TrustedTypePolicy`'s `createHTML` method.

    [Exposed=Window]
    interface TrustedHTML {
      stringifier;
    };

TrustedHTML objects have a `[[Data]]` internal slot which holds a DOMString. The slot’s value is set when the object is created, and will never change during its lifetime.

To stringify a TrustedHTML object, return the DOMString from its `[[Data]]` internal slot.

#### 2.2.2. TrustedScript

The TrustedScript interface represents a string with an uncompiled script body that a developer can confidently pass into an injection sink that might lead to executing that script. These objects are immutable wrappers around a string, constructed via a `TrustedTypePolicy`'s `createScript` method.

    [Exposed=Window]
    interface TrustedScript {
      stringifier;
    };

TrustedScript objects have a `[[Data]]` internal slot which holds a DOMString. The slot’s value is set when the object is created, and will never change during its lifetime.

To stringify a TrustedScript object, return the DOMString from its `[[Data]]` internal slot.

#### 2.2.3. TrustedScriptURL

The TrustedScriptURL interface represents a string that a developer can confidently pass into an injection sink that will parse it as a URL of an external script resource. These objects are immutable wrappers around a string, constructed via a `TrustedTypePolicy`'s `createScriptURL` method.

    [Exposed=Window]
    interface TrustedScriptURL {
      stringifier;
    };

TrustedScriptURL objects have a `[[Data]]` internal slot which holds a USVString. The slot’s value is set when the object is created, and will never change during its lifetime.

To stringify a TrustedScriptURL object, return the USVString from its `[[Data]]` internal slot.

### 2.3. Policies

Trusted Types can only be created via user-defined and immutable policies that define rules for converting a string into a given Trusted Type object. Policies allows the authors to specify custom, programmatic rules that Trusted Types must adhere to.

Authors may define a policy that will sanitize an HTML string, allowing only a subset of tags and attributes that are known not to cause JavaScript execution. Any `TrustedHTML` object created through this policy can then be safely used in the application, and e.g. passed to `innerHTML` setter - even if the input value was controlled by the attacker, the policy rules neutralized it to adhere to policy-specific contract.

    const sanitizingPolicy = trustedTypes.createPolicy('sanitize-html', {
      createHTML: (input) => myTrustedSanitizer(input, { superSafe: 'ok'}),
    });

    myDiv.innerHTML = sanitizingPolicy.createHTML(untrustedValue);

Note: Trusted Type objects wrap values that are explicitly trusted by the author. As such, creating a Trusted Type object instance becomes a de facto injection sink, and hence code that creates a Trusted Type instances is security-critical. To allow for strict control over Trusted Type object creation we don’t expose the constructors of those directly, but require authors to create them via policies.

Multiple policies can be created in a given Realm, allowing the applications to define different rules for different parts of the codebase.

Library initialized with a policy allowing it to load additional scripts from a given host.

    const cdnScriptsPolicy = trustedTypes.createPolicy('cdn-scripts', {
      createScriptURL(url) {
        const parsed = new URL(url, document.baseURI);
        if (parsed.origin == 'https://mycdn.example') {
          return url;
        }
        throw new TypeError('invalid URL');
      },
    });

    myLibrary.init({policy: cdnScriptsPolicy});

Note: Trusted Type objects can only be created via policies. If enforcement is enabled, only the policy code can trigger an action of an injection sink and hence call-sites of the policies' `create*` functions are the only security-sensitive code in the entire program with regards to the actions of the injection sinks. Only this typically small subset of the entire code base needs to be security-reviewed - there’s no need to monitor or review the injection sinks themselves, as User Agents enforce that those sinks will only accept matching Trusted Type objects, and these in turn can only be created via policies.

The `createPolicy` function returns a policy object which `create*` functions will create Trusted Type objects after applying the policy rules.

Note: While it’s safe to freely use a policy that sanitizes its input anywhere in the application, there might be a need to create lax policies to be used internally, and only to be called with author-controlled input. For example, a client-side HTML templating library, an HTML sanitizer library, or a JS asynchronous code plugin loading subsystem each will likely need full control over HTML or URLs. The API design facilitates that - each policy may only be used if the callsite can obtain a reference to the policy (a return value from `createPolicy()`). As such, policy references can be treated as capabilities, access to which can be controlled using JavaScript techniques (e.g. via closures, internal function variables, or modules).

Unsafe no-op policy reachable only from within a single code block to ascertain that it’s called only with no attacker-controlled values.

    (function renderFootnote() {
      const unsafePolicy = trustedTypes.createPolicy('html', {
        createHTML: input => input,
      });
      const footnote = await fetch('/footnote.html').then(r => r.text());
      footNote.innerHTML = unsafePolicy.createHTML(footnote);
    })();

#### 2.3.1. TrustedTypePolicyFactory

TrustedTypePolicyFactory creates `policies` and verifies that Trusted Type object instances were created via one of the policies.

Note: This factory object is exposed to JavaScript through `window.trustedTypes` reference - see § 4.1.1 Extensions to the Window interface.

    [Exposed=Window] interface TrustedTypePolicyFactory {
        [Unforgeable] TrustedTypePolicy createPolicy(
            DOMString policyName, optional TrustedTypePolicyOptions policyOptions);
        [Unforgeable] sequence<DOMString> getPolicyNames();
        [Unforgeable] boolean isHTML(any value);
        [Unforgeable] boolean isScript(any value);
        [Unforgeable] boolean isScriptURL(any value);
        [Unforgeable] readonly attribute TrustedHTML emptyHTML;
        [Unforgeable] readonly attribute TrustedScript emptyScript;
        DOMString? getAttributeType(
            DOMString tagName,
            DOMString attribute,
            optional DOMString elementNs = "",
            optional DOMString attrNs = "");
        DOMString? getPropertyType(
            DOMString tagName,
            DOMString property,
            optional DOMString elementNs = "");
        readonly attribute TrustedTypePolicy? defaultPolicy;
    };

Internal slot `[[DefaultPolicy]]` may contain a `TrustedTypePolicy` object, and is initially empty.

Internal slot `[[CreatedPolicyNames]]` is an ordered set of strings, initially empty.

`createPolicy(policyName, policyOptions)`

  Creates a policy object that will implement the rules passed in the `TrustedTypePolicyOptions` policyOptions object. The allowed policy names may be restricted by Content Security Policy. If the policy name is not on the whitelist defined in the trusted-types CSP directive, the policy creation fails with a TypeError. Also, if unique policy names are enforced (i.e. `'allow-duplicates'` is not used), and `createPolicy` is called more than once with any given `policyName`, policy creation fails with a TypeError.

      // HTTP Response header: Content-Security-Policy: trusted-types foo
      trustedTypes.createPolicy("foo", {}); // ok.
      trustedTypes.createPolicy("bar", {}); // throws - name not on the whitelist.
      trustedTypes.createPolicy("foo", {}); // throws - duplicate name.

  Returns the result of executing a Create a Trusted Type Policy algorithm, with the following arguments:

  factory
    context object
  policyName
    policyName
  options
    policyOptions
  global
    context object's relevant global object

      const myPolicy = trustedTypes.createPolicy('myPolicy', {
        // This security-critical code needs a security review;
        // a flaw in this code could cause DOM XSS.
        createHTML(input) { return aSanitizer.sanitize(input) },
        createScriptURL(input) {
          const u = new URL(dirty, document.baseURI);
          if (APPLICATION_CONFIG.scriptOrigins.includes(u.origin)) {
            return u.href;
          }
          throw new Error('Cannot load scripts from this origin');
        },
      });

      document.querySelector("#foo").innerHTML = myPolicy.createHTML(aValue);
      scriptElement.src = myPolicy.createScriptURL(
          'https://scripts.myapp.example/script.js');

`getPolicyNames()`

  This function returns the names of all the policies that were already created.

  Returns a new list, comprising of all entries of the `[[CreatedPolicyNames]]` slot.

      trustedTypes.createPolicy('foo', ...);
      trustedTypes.createPolicy('bar', ...);
      trustedTypes.getPolicyNames(); // ['foo', 'bar']

`isHTML(value)`

  Returns true if value is an instance of `TrustedHTML` and has its `[[Data]]` internal slot set, false otherwise.

  Note: `is*` functions are used to check if a given object is truly a legitimate Trusted Type object (i.e. it was created via one of the configured policies). This is to be able to detect a forgery of the objects via e.g. Object.create or prototype chains manipulation.

      const html = policy.createHTML('<div>');
      trustedTypes.isHTML(html); // true

      const fake = Object.create(TrustedHTML.prototype);
      trustedTypes.isHTML(fake); // false

      trustedTypes.isHTML("<div>plain string</div>"); // false

`isScript(value)`

  Returns true if value is an instance of `TrustedScript` and has its `[[Data]]` internal slot set, false otherwise.

`isScriptURL(value)`

  Returns true if value is an instance of `TrustedScriptURL` and has its `[[Data]]` internal slot set, false otherwise.

`getPropertyType(tagName, property, elementNs)`

  Allows the authors to check if a Trusted Type is required for a given `Element`'s property (IDL attribute).

  This function returns the result of the following algorithm:

  1. Set localName to tagName in ASCII lowercase.

  2. If elementNs is an empty string, set elementNs to HTML namespace.

  3. Let interface be the element interface for localName and elementNs.

  4. If interface has an IDL attribute member which identifier is attribute, and `TrustedTypes` IDL extended attribute appears on that attribute, return stringified `TrustedTypes`'s identifier and abort futher steps.

     Note: This also takes into account all members of interface mixins that interface includes.

  5. Return null.

      trustedTypes.getPropertyType('div', 'innerHTML'); // "TrustedHTML"
      trustedTypes.getPropertyType('foo', 'bar'); // undefined

`getAttributeType(tagName, attribute, elementNs, attrNs)`

  Allows the authors to check if, (and if so, which) Trusted Type is required for a given `Element`'s content attribute, such that later on the call to `Element.setAttribute` passes the correct argument type.

  This function returns the result of the following algorithm:

  1. Set localName to tagName in ASCII lowercase.

  2. Set attribute to attribute in ASCII lowercase.

  3. If elementNs is an empty string, set elementNs to HTML namespace.

  4. If attrNs is an empty string, set attrNs to null.

  5. Let interface be the element interface for localName and elementNs.

  6. If interface does not have an IDL attribute that reflects a content attribute with localName local name and attrNs namespace, return undefined and abort further steps. Otherwise, let idlAttribute be that IDL attribute.

  7. If `TrustedTypes` IDL extended attribute appears on idlAttribute, return stringified `TrustedTypes`'s identifier and abort futher steps.

  8. Return null.

      trustedTypes.getAttributeType('script', 'SRC'); // "TrustedScriptURL"
      trustedTypes.getAttributeType('foo', 'bar'); // undefined

`emptyHTML`, of type TrustedHTML, readonly

  is a `TrustedHTML` object with its `[[Data]]` internal slot value set to an empty string.

    anElement.innerHTML = trustedTypes.emptyHTML; // no need to create a policy

`emptyScript`, of type TrustedScript, readonly

  is a `TrustedScript` object with its `[[Data]]` internal slot value set to an empty string.

Note: This object can be used to detect if the runtime environment has § 4.5.6 Support for eval(TrustedScript). While native Trusted Types implementation can support `eval(TrustedScript)`, it is impossible for a polyfill to emulate that, as eval(TrustedScript) will return its input without unwrapping and evaluating the code.

    // With native Trusted Types support eval(trustedTypes.emptyScript) will execute and return falsy undefined.
    // Without it, eval(trustedTypes.emptyScript) will return a truthy Object.
    const supportsTS = !eval(trustedTypes.emptyScript);

    eval(supportsTS ? myTrustedScriptObj : myTrustedScriptObj.toString());

`defaultPolicy`, of type TrustedTypePolicy, readonly, nullable

  Returns the value of `[[DefaultPolicy]]` internal slot, or null if the slot is empty.

    trustedTypes.defaultPolicy === null;  // true
    const dp = trustedTypes.createPolicy('default', {});
    trustedTypes.defaultPolicy === dp;  // true

#### 2.3.2. TrustedTypePolicy

Policy objects implement a TrustedTypePolicy interface and define a group of functions creating Trusted Type objects. Each of the `create*` functions converts a string value to a given Trusted Type variant, or throws a TypeError if a conversion of a given value is disallowed.

    [Exposed=Window]
    interface TrustedTypePolicy {
      [Unforgeable] readonly attribute DOMString name;
      [Unforgeable] TrustedHTML createHTML(DOMString input, any... arguments);
      [Unforgeable] TrustedScript createScript(DOMString input, any... arguments);
      [Unforgeable] TrustedScriptURL createScriptURL(DOMString input, any... arguments);
    };

Each policy has a name.

Each TrustedTypePolicy object has an `[[options]]` internal slot, holding the `TrustedTypePolicyOptions` object describing the actual behavior of the policy.

`createHTML(input, ...arguments)`

  Returns the result of executing the Create a Trusted Type algorithm, with the following arguments:

  policy
    context object
  trustedTypeName
    `"TrustedHTML"`
  value
    input
  arguments
    arguments
`createScript(input, ...arguments)`

  Returns the result of executing the Create a Trusted Type algorithm, with the following arguments:

  policy
    context object
  trustedTypeName
    `"TrustedScript"`
  value
    input
  arguments
    arguments
`createScriptURL(input, ...arguments)`

  Returns the result of executing the Create a Trusted Type algorithm, with the following arguments:

  policy
    context object
  trustedTypeName
    `"TrustedScriptURL"`
  value
    input
  arguments
    arguments

#### 2.3.3. TrustedTypePolicyOptions

This dictionary holds author-defined functions for converting string values into trusted values. These functions do not create Trusted Type object instances directly - this behavior is provided by `TrustedTypePolicy`.

    dictionary TrustedTypePolicyOptions {
       CreateHTMLCallback? createHTML;
       CreateScriptCallback? createScript;
       CreateScriptURLCallback? createScriptURL;
    };
    callback CreateHTMLCallback = DOMString (DOMString input, any... arguments);
    callback CreateScriptCallback = DOMString (DOMString input, any... arguments);
    callback CreateScriptURLCallback = USVString (DOMString input, any... arguments);

#### 2.3.4. Default policy

This section is not normative.

One of the policies, the policy with a name `"default"`, is special; When an injection sink is passed a string (instead of a Trusted Type object), this policy will be implicitly called by the user agent with the string value as the first argument, and the sink name as a second argument.

This allows the application to define a fallback behavior to use instead of causing a violation. The intention is to allow the applications to recover from an unexpected data flow, and sanitize the potentially attacker-controlled string "as a last resort", or reject a value if a safe value cannot be created. Errors thrown from within a policy are propagated to the application.

If the default policy doesn’t exist, or if its appropriate `create*` function returns null or undefined, it will cause a CSP violation. In the enforcing mode, an error will be thrown, but in report-only the original value passed to the default policy will be used.

Note: This optional behavior allows for introducing Trusted Type enforcement to applications that are still using legacy code that uses injection sinks. Needless to say, this policy should necessarily be defined with very strict rules not to bypass the security restrictions in unknown parts of the application. In an extreme case, a lax, no-op default policy defeats all the benefits of using Trusted Types to protect access to injection sinks. If possible, authors should resort to a default policy in a transitional period only, use it to detect and rewrite their dependencies that use injection sinks unsafely and eventually phase out the usage of the default policy entirely.

Note: See § 3.3 Get Trusted Type compliant string for details on how the default policy is applied.

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

    trustedTypes.createPolicy('default', {
      createScriptURL: (s, sink) => {
        console.log("Please refactor.");
        return s + "?default-policy-used&sink=" + encodeURIComponent(sink);
      }
    });

    aScriptElement.src = "https://cdn.example/script.js";
    // Please refactor.
    console.log(aScriptElement.src);
    // https://cdn.example/script.js?default-policy-used&sink=script.src

### 2.4. Enforcement

Note: Enforcement is the process of checking that a value has an appropriate type before it reaches an injection sink.

The JavaScript API that allows authors to create policies and Trusted Types objects from them is always available (via `trustedTypes`). Since injection sinks stringify their security sensitive arguments, and Trusted Type objects stringify to their inner string values, this allows the authors to use Trusted Types in place of strings.

To secure the access to injection sinks, on top of the JavaScript code using the Trusted Types, the user agent needs to enforce them i.e. assert that the injection sinks from a given group are never called with string values, and Trusted Type values are used instead. This section describes how authors may control this enforcing behavior.

Authors may also control their policies by specifying rules around policy creation.

#### 2.4.1. Content Security Policy

Applications may control Trusted Type enforcement via configuring a Content Security Policy. This document defines new directives that correspond to Trusted Types rules. The require-trusted-types-for directive specifies the injection sinks groups, for which the types should be required. The trusted-types directive controls how policies can be created.

Note: Using CSP mechanisms allows the authors to prepare their application for enforcing Trusted Types via using the `Content-Security-Report-Only` HTTP Response header.

Note: Most of the enforcement rules are defined as modifications of the algorithms in other specifications, see § 4 Integrations.

#### 2.4.2. TrustedTypes extended attribute

Note: This section describes the implementation details of the Trusted Types mechanism. IDL extended attributes are not exposed to the JavasScript code.

To annotate the injection sink functions that require Trusted Types, we introduce `[TrustedTypes]` IDL extended attribute. Its presence indicates that the relevant construct is to be supplemented with additional Trusted Types enforcement logic.

The `TrustedTypes` extended attribute takes an identifier as an argument. The only valid values for the identifier are `TrustedHTML`, `TrustedScript`, or `TrustedScriptURL`. This extended attribute must not appear on anything other than an attribute or an operation argument. Additionally, it must not appear on read only attributes.

When the extended attribute appears on an attribute, the setter for that attribute must run the following steps in place of the ones specified in its description:

1. If context object's relevant global object has a trusted type policy factory:

   Update when workers have TT.

   1. If the context object is an `Element`, let objectName be the context object's local name; Otherwise, let objectName be the context object's constructor name.

   2. Set sink to the result of concatenating the list « objectName, attribute identifier. » with `"."` as separator.

      For example, the following annotation and JavaScript code:

          partial interface mixin HTMLScriptElement {
            [CEReactions, TrustedTypes=TrustedScriptURL] attribute ScriptURLString src;
          };

          document.createElement('script').src = foo;
          document.createElement('script').setAttribute('SrC', foo);

      causes the sink value to be `"script.src"`.

   3. Set value to the result of running the Get Trusted Type compliant string algorithm, passing the following arguments:

      - the new value as input,

      - `TrustedTypes` extended attribute identifier as expectedType,

      - sink as sink,

      - `'script'` as sinkGroup,

      - context object's relevant global object as global.

      Remove hardcoding 'script' when new sink groups are specified.

   4. If an exception was thrown, rethrow exception and abort further steps.

2. Run the originally specified steps for this construct, using value as a new value to set.

Note: If the IDL attribute reflects a content attribute, identical steps should be performed when that content attribute is modified by JavaScript code e.g. via `Element.setAttribute()` function.

When the extended attribute appears on an operation argument, before its operation is invoked, run the following steps:

1. If context object's relevant global object has a trusted type policy factory:

   Update when workers have TT.

   1. If the context object is an `Element`, let objectName be the context object's local name; Otherwise, let objectName be the context object's constructor name.

   2. Set sink to the result of concatenating the list « objectName, operation identifier. » with `"."` as separator.

      For example, the following annotation and JavaScript code:

          partial interface Element {
            void insertAdjacentHTML(DOMString position, [TrustedTypes=TrustedHTML] HTMLString text);
          };

          document.createElement('a').insertAdjacentHTML('beforebegin', foo);

      causes the sink value to be `"a.insertAdjacentHTML"`.

   3. Set the new argument value to the result of running the Get Trusted Type compliant string algorithm, passing the following arguments:

      - the argument value as input,

      - `TrustedTypes` extended attribute identifier as expectedType,

      - sink as sink,

      - `'script'` as sinkGroup,

      - context object's relevant global object as global.

      Remove hardcoding 'script' when new sink types are specified.

   4. If an exception was thrown, rethrow exception and abort further steps.

2. Invoke the originally specified steps for the operation.

## 3. Algorithms

### 3.1. Create a Trusted Type Policy

To create a `TrustedTypePolicy`, given a `TrustedTypePolicyFactory` (factory), a string (policyName), `TrustedTypePolicyOptions` dictionary (options), and a global object (global) run these steps:

1. Let allowedByCSP be the result of executing Should Trusted Type policy creation be blocked by Content Security Policy? algorithm with global, policyName and factory’s `[[CreatedPolicyNames]]` slot value.

2. If allowedByCSP is `"Blocked"`, throw a `TypeError` and abort further steps.

3. If policyName is `default` and the factory’s `[[DefaultPolicy]]` slot value is not empty, throw a `TypeError` and abort further steps.

4. Let policy be a new `TrustedTypePolicy` object.

5. Set policy’s `name` property value to policyName.

6. Let policyOptions be a new `TrustedTypePolicyOptions` object.

7. Set policyOptions `createHTML` property to option’s `createHTML` property value.

8. Set policyOptions `createScript` property to option’s `createScript` property value.

9. Set policyOptions `createScriptURL` property to option’s `createScriptURL` property value.

10. Set policy’s `[[options]]` internal slot value to policyOptions.

11. If the policyName is `default`, set the factory’s `[[DefaultPolicy]]` slot value to policy.

12. Append policyName to factory’s `[[CreatedPolicyNames]]`.

13. Return policy.

### 3.2. Create a Trusted Type

Given a `TrustedTypePolicy` policy, a type name trustedTypeName, a string value and a list arguments, execute the following steps:

1. Let functionName be a function name for the given trustedTypeName, based on the following table:

   Function name | Trusted Type name
   --- | ---
   "createHTML" | "TrustedHTML"
   "createScript" | "TrustedScript"
   "createScriptURL" | "TrustedScriptURL"

2. Let options be the value of policy’s `[[options]]` slot.

3. Let function be the value of the property in options named functionName.

4. If function is `null`, throw a `TypeError`.

5. Let policyValue be the result of invoking function with value as a first argument, items of arguments as subsequent arguments, and callback **this** value set to `null`.

6. If policyValue is an error, return policyValue and abort the following steps.

7. If policy’s name is `"default"` and the policyValue is null or undefined, return policyValue.

   Note: This is used in a Get Trusted Type compliant string algorithm to signal that a value was rejected.

8. Let dataString be the result of stringifying policyValue.

9. Let trustedObject be a new instance of an interface with a type name trustedTypeName, with its `[[Data]]` internal slot value set to dataString.

10. Return trustedObject.

### 3.3. Get Trusted Type compliant string

This algorithm will return a string that can be used with an injection sink, optionally unwrapping it from a matching Trusted Type. It will ensure that the Trusted Type enforcement rules were respected.

Given a `TrustedType` type (expectedType), a global object (global), `TrustedType` or a string (input), a string (sink) and a string (sinkGroup), run these steps:

1. Assert: global is a `Window`.

   Synchronize when TT are added to workers (perhaps use "has a CSP list"?)

2. Let cspList be the global’s CSP list.

3. If cspList does not contain a policy which directive set containing a directive with a name `"require-trusted-types-for"`, or that directive does not contain a trusted-types-sink-group which is a match for a value sinkGroup, return stringified input and abort these steps.

4. If input has type expectedType, return stringified input and abort these steps.

5. Let convertedInput be the result of executing Process value with a default policy with the same arguments as this algorithm.

6. If the algorithm threw an error, rethrow the error and abort the following steps.

7. If convertedInput is `null` or `undefined`, execute the following steps:

   1. Let disposition be the result of executing Should sink type mismatch violation be blocked by Content Security Policy? algorithm, passing global, input as source, sinkGroup and sink.

   2. If disposition is `“Allowed”`, return stringified input and abort futher steps.

      Note: This step assures that the default policy rejection will be reported, but ignored in a report-only mode.

   3. Throw a `TypeError` and abort further steps.

8. Assert: convertedInput has type expectedType.

9. Return stringified convertedInput.

### 3.4. Process value with a default policy

This algorithm routes a value to be assigned to an injection sink through a default policy, should one exist.

Given a `TrustedType` type (expectedType), a global object (global), `TrustedType` or a string (input), and a string (sink), run these steps:

1. Let defaultPolicy be the value of global’s trusted type policy factory's `[[DefaultPolicy]]` slot. If the slot is empty, return `null`.

2. Let convertedInput be the result of executing Create a Trusted Type algorithm, with the following arguments:

   - defaultPolicy as policy

   - input as value

   - expectedType’s type name as trustedTypeName

   - « sink » as arguments

3. If the algorithm threw an error, rethrow it. Otherwise, return convertedInput.

### 3.5. Prepare the script URL and text

Given a `script` (script), this algorithm performs the following steps:

1. If script does not have a `src` content attribute, set its `[[ScriptURL]]` internal slot value to `null`.

2. Otherwise, if script’s `[[ScriptURL]]` internal slot value is not equal to its `src` attribute value, set script’s `[[ScriptURL]]` to the result of executing Get Trusted Type compliant string, with the following arguments:

   - `TrustedScriptURL` as expectedType,

   - script’s `Document`'s relevant global object as global,

   - script’s `src` attribute value as input,

   - `script.src` as sink,

   - `'script'` as sinkGroup.

   If the algorithm threw an error, rethrow the error and abort further steps.

3. If script’s `[[ScriptText]]` internal slot value is not equal to its child text content, set script’s `[[ScriptText]]` to the result of executing Get Trusted Type compliant string, with the following arguments:

   - `TrustedScriptURL` as expectedType,

   - script’s `Document`'s relevant global object as global,

   - script’s child text content attribute value,

   - `script.text` as sink,

   - `'script'` as sinkGroup.

   If the algorithm threw an error, rethrow the error.

## 4. Integrations

    typedef (DOMString or TrustedHTML) HTMLString;
    typedef (DOMString or TrustedScript) ScriptString;
    typedef (USVString or TrustedScriptURL) ScriptURLString;
    typedef (TrustedHTML or TrustedScript or TrustedScriptURL) TrustedType;

    typedef (([TreatNullAs=EmptyString] DOMString) or TrustedHTML) HTMLStringDefaultsEmpty;

Note: `HTMLStringDefaultsEmpty` is a non-nullable variant that accepts null on set. Having this separate type allows Web IDL §3.3.22 [TreatNullAs] to attach to DOMString per heycam/webidl#441.

TreatNullAs=EmptyString is confusing. See note "It should not be used in specifications unless ...". For some sinks a `null` value will result in "", and "null" for others. This already caused problems in the polyfill. <https://github.com/w3c/webappsec-trusted-types/issues/2>

### 4.1. Integration with HTML

`Window` objects have a trusted type policy factory, which is a `TrustedTypePolicyFactory` object.

Define for workers.

#### 4.1.1. Extensions to the Window interface

This document extends the `Window` interface defined by HTML:

    partial interface mixin Window {
      [Unforgeable] readonly attribute
          TrustedTypePolicyFactory trustedTypes;
    };

`trustedTypes` returns the trusted type policy factory of the current `Window`.

Note: The implementation in Chrome < 78 uses `window.TrustedTypes` instead of `window.trustedTypes`.

Remove the note when the API in Chrome is shipped.

#### 4.1.2. Extensions to the Document interface

This document modifies the `Document` interface defined by HTML:

    partial interface mixin Document {
      [CEReactions] void write([TrustedTypes=TrustedHTML] HTMLString... text);
      [CEReactions] void writeln([TrustedTypes=TrustedHTML] HTMLString... text);
    };

#### 4.1.3. Enforcement for scripts

##### 4.1.3.1. Slots with trusted values

This document modifies `script` elements. Each script has:

`[[ScriptURL]]` internal slot.

  A string, containing the URL to execute the script from that was set through a `TrustedTypes` compliant sink. Equivalent to `src` attribute value. Initially null.

`[[ScriptText]]` internal slot.

  A string, containing the body of the script to execute that was set through a `TrustedTypes` compliant sink. Equivalent to script’s child text content. Initially null.

##### 4.1.3.2. Setting slot values

This document modifies how `HTMLScriptElement` child text content can be set to allow applications to control dynamically created scripts. It does so by adding the `innerText` and `textContent` attributes directly on `HTMLScriptElement`. The behavior of the attributes remains the same as in their original counterparts, apart from additional behavior triggered by the `TrustedTypes` extended attribute presence.

Note: Using these IDL attributes is the recommended way of dynamically setting URL or a text of a script. Manipulating attribute nodes or text nodes directly will call a default policy on the final value when the script is prepared.

Figure out what to do with script.setAttribute('src'). See DOM#789.

    partial interface mixin HTMLScriptElement : HTMLElement {
     [CEReactions, TrustedTypes=TrustedScript] attribute [TreatNullAs=EmptyString] ScriptString innerText;
     [CEReactions, TrustedTypes=TrustedScript] attribute ScriptString? textContent;
     [CEReactions, TrustedTypes=TrustedScriptURL] attribute ScriptURLString src;
     [CEReactions, TrustedTypes=TrustedScript] attribute ScriptString text;
    };

On setting, the `innerText`, `textContent` and `text` IDL attributes perform the regular steps, and then set content object's `[[ScriptText]]` internal slot value with the stringified value.

On setting, the `src` IDL attribute performs the usual steps, and then sets content object's `[[ScriptURL]]` internal slot value to its `src` content attribute value.

##### 4.1.3.3. Slot value verification

The prepare a script algorithm is modified as follows:

1. If the `script` element is marked as having "already started", then return. The script is not executed.

2. If the element has its "parser-inserted" flag set, then set was-parser-inserted to true and unset the element’s "parser-inserted" flag. Otherwise, set was-parser-inserted to false.

   This is done so that if parser-inserted `script` elements fail to run when the parser tries to run them, e.g. because they are empty or specify an unsupported scripting language, another script can later mutate them and cause them to run again.

3. If was-parser-inserted is true and the element does not have an `async` attribute, then set the element’s "non-blocking" flag to true.

   This is done so that if a parser-inserted `script` element fails to run when the parser tries to run it, but it is later executed after a script dynamically updates it, it will execute in a non-blocking fashion even if the `async` attribute isn’t set.

4. Execute the Prepare the script URL and text algorithm upon the `script` element. If that algorithm threw an error, then return. The script is not executed.

5. Let source text be the element’s child text content `[[ScriptText]]` internal slot value .

6. Let src be the element’s `[[ScriptURL]]` internal slot value.

7. If the element has no `src` attribute src is null , and source text is the empty string, then return. The script is not executed.

8. If the element is not connected, then return. The script is not executed.

9. If either:

   - the `script` element has a `type` attribute and its value is the empty string, or
   - the `script` element has no `type` attribute but it has a `language` attribute and that attribute’s value is the empty string, or
   - the `script` element has neither a `type` attribute nor a `language` attribute, then

   ...let the script block’s type string for this `script` element be "`text/javascript`".

   Otherwise, if the `script` element has a `type` attribute, let the script block’s type string for this `script` element be the value of that attribute with leading and trailing ASCII whitespace stripped.

   Otherwise, the element has a non-empty `language` attribute; let the script block’s type string for this `script` element be the concatenation of the string "`text/`" followed by the value of the `language` attribute.

   The `language` attribute is never conforming, and is always ignored if there is a `type` attribute present.

   Determine the script’s type as follows:

   - If the script block’s type string is a JavaScript MIME type essence match, the script’s type is "`classic`".
   - If the script block’s type string is an ASCII case-insensitive match for the string "`module`", the script’s type is "`module`".
   - If neither of the above conditions are true, then return. No script is executed.

10. If was-parser-inserted is true, then flag the element as "parser-inserted" again, and set the element’s "non-blocking" flag to false.

11. Set the element’s "already started" flag.

12. If the element is flagged as "parser-inserted", but the element’s node document is not the `Document` of the parser that created the element, then return.

13. If scripting is disabled for the `script` element, then return. The script is not executed.

    The definition of scripting is disabled means that, amongst others, the following scripts will not execute: scripts in `XMLHttpRequest`’s `responseXML` documents, scripts in `DOMParser`-created documents, scripts in documents created by `XSLTProcessor`’s `transformToDocument` feature, and scripts that are first inserted by a script into a `Document` that was created using the `createDocument()` API. \[XHR\] \[DOMPARSING\] \[XSLTP\] \[DOM\]

14. If the `script` element has a `nomodule` content attribute and the script’s type is "`classic`", then return. The script is not executed.

    This means specifying `nomodule` on a module script has no effect; the algorithm continues onward.

15. If the `script` element does not have a `src` content attribute src is null , and the Should element’s inline behavior be blocked by Content Security Policy? algorithm returns "`Blocked`" when executed upon the `script` element, "`script`", and source text, then return. The script is not executed. \[CSP\]

16. If the `script` element has an `event` attribute and a `for` attribute, and the script’s type is "`classic`", then:

    1. Let for be the value of the `for` attribute.

    2. Let event be the value of the `event` attribute.

    3. Strip leading and trailing ASCII whitespace from event and for.

    4. If for is not an ASCII case-insensitive match for the string "`window`", then return. The script is not executed.

    5. If event is not an ASCII case-insensitive match for either the string "`onload`" or the string "`onload()`", then return. The script is not executed.

17. If the `script` element has a `charset` attribute, then let encoding be the result of getting an encoding from the value of the `charset` attribute.

    If the `script` element does not have a `charset` attribute, or if getting an encoding failed, let encoding be the same as the encoding of the `script` element’s node document.

    If the script’s type is "`module`", this encoding will be ignored.

18. Let classic script CORS setting be the current state of the element’s `crossorigin` content attribute.

19. Let module script credentials mode be the module script credentials mode for the element’s `crossorigin` content attribute.

20. Let cryptographic nonce be the element’s \[\[CryptographicNonce\]\] internal slot’s value.

21. If the `script` element has an `integrity` attribute, then let integrity metadata be that attribute’s value.

    Otherwise, let integrity metadata be the empty string.

22. Let referrer policy be the current state of the element’s `referrerpolicy` content attribute.

23. Let parser metadata be "`parser-inserted`" if the `script` element has been flagged as "parser-inserted", and "`not-parser-inserted`" otherwise.

24. Let options be a script fetch options whose cryptographic nonce is cryptographic nonce, integrity metadata is integrity metadata, parser metadata is parser metadata, credentials mode is module script credentials mode, and referrer policy is referrer policy.

25. Let settings object be the element’s node document’s relevant settings object.

26. If the element has a `src` content attribute src is not null , then:

    1. Let src be the value of the element’s `src` attribute.

    2. If src is the empty string, queue a task to fire an event named `error` at the element, and return.

    3. Set the element’s from an external file flag.

    4. Parse src relative to the element’s node document.

    5. If the previous step failed, queue a task to fire an event named `error` at the element, and return. Otherwise, let url be the resulting URL record.

    6. Switch on the script’s type:

       "`classic`"

         Fetch a classic script given url, settings object, options, classic script CORS setting, and encoding.

       "`module`"

         Fetch an external module script graph given url, settings object, and options.

       When the chosen algorithm asynchronously completes, set the script’s script to the result. At that time, the script is ready.

       For performance reasons, user agents may start fetching the classic script or module graph (as defined above) as soon as the `src` attribute is set, instead, in the hope that the element will be inserted into the document (and that the `crossorigin` attribute won’t change value in the meantime). Either way, once the element is inserted into the document, the load must have started as described in this step. If the UA performs such prefetching, but the element is never inserted in the document, or the `src` attribute is dynamically changed, or the `crossorigin` attribute is dynamically changed, then the user agent will not execute the script so obtained, and the fetching process will have been effectively wasted.

27. If the element does not have a `src` content attribute src is null , run these substeps:

    1. Let base URL be the `script` element’s node document’s document base URL.

    2. Switch on the script’s type:

       "`classic`"

         1. Let script be the result of creating a classic script using source text, settings object, base URL, and options.

         2. Set the script’s script to script.

         3. The script is ready.

       "`module`"

         1. Fetch an inline module script graph, given source text, base URL, settings object, and options. When this asynchronously completes, set the script’s script to the result. At that time, the script is ready.

28. Then, follow the first of the following options that describes the situation:

    If the script’s type is "`classic`", and the element has a `src` attribute, and the element has a `defer` attribute, and the element has been flagged as "parser-inserted", and the element does not have an `async` attribute
    If the script’s type is "`module`", and the element has been flagged as "parser-inserted", and the element does not have an `async` attribute

      Add the element to the end of the list of scripts that will execute when the document has finished parsing associated with the `Document` of the parser that created the element.

      When the script is ready, set the element’s "ready to be parser-executed" flag. The parser will handle executing the script.

    If the script’s type is "`classic`", and the element has a `src` attribute, and the element has been flagged as "parser-inserted", and the element does not have an `async` attribute

      The element is the pending parsing-blocking script of the `Document` of the parser that created the element. (There can only be one such script per `Document` at a time.)

      When the script is ready, set the element’s "ready to be parser-executed" flag. The parser will handle executing the script.

    If the script’s type is "`classic`", and the element has a `src` attribute, and the element does not have an `async` attribute, and the element does not have the "non-blocking" flag set
    If the script’s type is "`module`", and the element does not have an `async` attribute, and the element does not have the "non-blocking" flag set

      Add the element to the end of the list of scripts that will execute in order as soon as possible associated with the node document of the `script` element at the time the prepare a script algorithm started.

      When the script is ready, run the following steps:

      1. If the element is not now the first element in the list of scripts that will execute in order as soon as possible to which it was added above, then mark the element as ready but return without executing the script yet.

      2. Execution: Execute the script block corresponding to the first script element in this list of scripts that will execute in order as soon as possible.

      3. Remove the first element from this list of scripts that will execute in order as soon as possible.

      4. If this list of scripts that will execute in order as soon as possible is still not empty and the first entry has already been marked as ready, then jump back to the step labeled execution.

    If the script’s type is "`classic`", and the element has a `src` attribute
    If the script’s type is "`module`"

      The element must be added to the set of scripts that will execute as soon as possible of the node document of the `script` element at the time the prepare a script algorithm started.

      When the script is ready, execute the script block and then remove the element from the set of scripts that will execute as soon as possible.

    If the element does not have a `src` attribute, and the element has been flagged as "parser-inserted", and either the parser that created the `script` is an XML parser or it’s an HTML parser whose script nesting level is not greater than one, and the `Document` of the HTML parser or XML parser that created the `script` element has a style sheet that is blocking scripts

      The element is the pending parsing-blocking script of the `Document` of the parser that created the element. (There can only be one such script per `Document` at a time.)

      Set the element’s "ready to be parser-executed" flag. The parser will handle executing the script.

    Otherwise
      Immediately execute the script block, even if other scripts are already executing.

#### 4.1.4. Enforcement in element attributes

This document modifies following IDL attributes of various DOM elements:

    partial interface mixin HTMLIFrameElement : HTMLElement {
      [CEReactions, TrustedTypes=TrustedHTML] attribute HTMLString srcdoc;
    };

    partial interface HTMLEmbedElement : HTMLElement {
      [CEReactions, TrustedTypes=TrustedScriptURL] attribute ScriptURLString src;
    };

    partial interface HTMLObjectElement : HTMLElement {
      [CEReactions, TrustedTypes=TrustedScriptURL] attribute ScriptURLString data;
      [CEReactions, TrustedTypes=TrustedScriptURL] attribute DOMString codeBase; // obsolete
    };

Add base.href enforcement.

#### 4.1.5. Enforcement in timer functions

This document modifies the `WindowOrWorkerGlobalScope` interface mixin:

    typedef (ScriptString or Function) TrustedTimerHandler;

    partial interface mixin WindowOrWorkerGlobalScope {
      long setTimeout(TrustedTimerHandler handler, optional long timeout = 0, any... arguments);
      long setInterval(TrustedTimerHandler handler, optional long timeout = 0, any... arguments);
    };

To the timer initialization steps algorithm, add this step between 7.1 and 7.2:

1. If the first operation argument is not a `Function`, or if the first operation argument is a `TrustedType`, set the first operation argument to the result of executing the Get Trusted Type compliant string algorithm, with

   - global set to the context object's relevant global object.

   - input set to the first method argument, and

   - expectedType set to `TrustedScript`.

   - sink set to `Window.setInterval` if repeat is true, `Window.setTimeout` otherwise.

   - sinkGroup set to `'script'`.

     Note: This matches the logic that the extended attribute would apply.

Note: This makes sure that a `TrustedScript` is passed to timer functions in place of a string when Trusted Types are enforced, but also unconditionally accepts any `Function` object.

#### 4.1.6. Enforcement in event handler content attributes

This document modifies the attribute change steps for an event handler content attribute.

At the beginning of step 5, insert the following steps:

1. Let value be the result of executing the Get Trusted Type compliant string algorithm, with the following arguments:

   - value as input,

   - `TrustedScript` as expectedType,

   - `'script'` as sinkGroup

   - sink being the result of concatenating the list « element’s local name, localName » with `"."` as a separator.

     Note: For example, `document.createElement('div').onclick = value` will result in sink being `'div.onclick'`.

   - eventTarget’s relevant global object as global,

2. If the algorithm throws an error, abort these steps.

Note: This also applies to events in SVG 2 §15.9 Event attributes.

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

    const img = document.createElement('img');
    img.setAttribute('onerror', 'alert(1)'); // TypeError

### 4.2. Integration with SVG

This document modifies the `SVGScriptElement` interface to enforce Trusted Types:

    partial interface mixin SVGScriptElement : SVGElement {
     // overwrites the definition in SVGURIReference.
     [TrustedTypes=TrustedScriptURL] readonly attribute ScriptURLString href;
    };

### 4.3. Integration with DOM

This document modifies the `Element` interface, adding attribute validation steps:

This and other specifications may define attribute validation steps for elements. The algorithm is passed element, localName, value, and namespace.

This document changes the handle attribute changes algorithm, adding the following step at the beginning:

1. Run the attribute validation steps with element, attribute’s local name, newValue and attribute’s namespace. If this throws an exception, then rethrow the exception and abort further steps.

Additionally, this document changes the append an attribute algorithm:

To append an attribute attribute to an element element with a value , run these steps:

1. Handle attribute changes for attribute with element, null, and attribute’s value value .

2. Set attribute’s value to value.

3. Append attribute to element’s attribute list.

4. Set attribute’s element to element.

Callers of this algorithm are changed accordingly.

Remove when DOM #809 is merged.

### 4.4. Integration with DOM Parsing

This document modifies the following interfaces defined by [DOM-Parsing]:

    partial interface Element {
      [CEReactions, TrustedTypes=TrustedHTML] attribute HTMLStringDefaultsEmpty outerHTML;
      [CEReactions] void insertAdjacentHTML(DOMString position, [TrustedTypes=TrustedHTML] HTMLString text);
    };

    partial interface mixin InnerHTML { // specified in a draft version at https://w3c.github.io/DOM-Parsing/#the-innerhtml-mixin
      [CEReactions, TrustedTypes=TrustedHTML] attribute HTMLStringDefaultsEmpty innerHTML;
    };

    partial interface Range {
      [CEReactions, NewObject] DocumentFragment createContextualFragment([TrustedTypes=TrustedHTML] HTMLString fragment);
    };

    [Constructor, Exposed=Window]
    interface DOMParser {
      [NewObject] Document parseFromString([TrustedTypes=TrustedHTML] HTMLString str, SupportedType type);
    };

### 4.5. Integration with Content Security Policy

#### 4.5.1. require-trusted-types-for directive

This document defines require-trusted-types-for - a new Content Security Policy directive.

`require-trusted-types-for` directive configures the Trusted Types framework for all the injection sinks of certain groups in a current realm. Specifically, it defines what should be the behavior when a string value is passed to an injection sink of a given group (i.e. should the type-based enforcement be enabled for such sinks).

Note: Currently, only the enforcement for § 2.1.2 DOM XSS injection sinks is specified.

The syntax for the directive’s name and value is described by the following ABNF:

    directive-name = "require-trusted-types-for"
    directive-value = trusted-types-sink-group *( required-ascii-whitespace trusted-types-sink-group)
    trusted-types-sink-group = "'script'"

Enforce Trusted Types at the DOM XSS injection sinks.

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

##### 4.5.1.1. `require-trusted-types-for` Pre-Navigation check

Given a request (request), a string navigation type and a policy (policy), this algorithm returns `"Blocked"` if a navigation violates the `require-trusted-types-for` directive’s constraints and `"Allowed"` otherwise. This constitutes the `require-trusted-types-for` directive’s pre-navigation check:

Note: This algorithm assures that the code to be executed by a navigation to a `javascript:` URL will have to pass through a default policy’s `createScript` function, in addition to all other restrictions imposed by other CSP directives.

1. If request’s url's scheme is not `"javascript"`, return `"Allowed"` and abort further steps.

2. Let urlString be the result of running the URL serializer on request’s url.

3. Let encodedScriptSource be the result of removing the leading `"javascript:"` from urlString.

4. Let convertedScriptSource be the result of executing Process value with a default policy algorithm, with the following arguments:

   - `TrustedScript` as expectedType

   - request’s clients's global object as global

   - encodedScriptSource as input

   - `"Location.href"` as sink

   If that algorithm threw an error or convertedScriptSource is not a `TrustedScript` object, return "Blocked" and abort further steps.

5. Set urlString to be the result of prepending `"javascript:"` to stringified convertedScriptSource.

6. Let newURL be the result of running the URL parser on urlString. If the parser returns a failure, return `"Blocked"` and abort further steps.

7. Set request’s url to newURL.

   Note: No other CSP directives operate on `javascript:` URLs in a pre-navigation check. Other directives that check javascript: URLs will operate on the modified URL later, in the inline check.

8. Return `"Allowed"`.

#### 4.5.2. trusted-types directive

This document defines trusted-types - a new Content Security Policy directive. The `trusted-types` directive controls the creation of Trusted Type policies.

The syntax for the directive’s name and value is described by the following ABNF:

    directive-name = "trusted-types"
    directive-value = serialized-tt-configuration
    serialized-tt-configuration = ( tt-expression *( required-ascii-whitespace tt-expression ) )
    tt-expression = tt-policy-name  / tt-keyword
    tt-policy-name = 1*( ALPHA / DIGIT / "-" / "#" / "=" / "_" / "/" / "@" / "." / "%")
    tt-keyword = "'allow-duplicates'"

Types are enforced at sinks, and only two policies may be created: “one” and “two”.

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

An empty directive value indicates policies may not be created, and sinks expect Trusted Type values, i.e. no DOM XSS injection sinks can be used at all.

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

Keyword `'allow-duplicates'` allows for creating policies with a name that was already used.

    Content-Security-Policy: trusted-types foo bar 'allow-duplicates'

If the policy named `default` is present in the list, it refers to the default policy. All strings passed to injection sinks will be passed through it instead of being rejected outright.

    Content-Security-Policy: trusted-types one two default

#### 4.5.3. Should sink type mismatch violation be blocked by Content Security Policy?

Given a global object (global), a string (sink), a string (sinkGroup) and a string (source) this algorithm returns `"Blocked"` if the injection sink requires a Trusted Type, and `"Allowed"` otherwise.

1. Let result be `"Allowed"`.

2. For each policy in global’s CSP list:

   1. If policy’s directive set does not contain a directive which name is `"require-trusted-types-for"`, skip to the next policy.

   2. Let directive be the policy’s directive set’s directive which name is `"require-trusted-types-for"`

   3. If directive’s value does not contain a trusted-types-sink-group which is a match for a value sinkGroup, skip to the next policy.

   4. Let violation be the result of executing Create a violation object for global, policy, and directive on global, policy and `"require-trusted-types-for"`

   5. Set violation’s resource to `"trusted-types-sink"`.

   6. Let trimmedSource be the substring of source, containing its first 40 characters.

   7. Set violation’s sample to be the result of concatenating the list « sink, trimmedSource « using space (`"\x20"`) as a separator.

   8. Execute Report a violation on violation.

   9. If policy’s disposition is `"enforce"`, then set result to `"Blocked"`.

3. Return result.

#### 4.5.4. Should Trusted Type policy creation be blocked by Content Security Policy?

Given a global object (global), a string (policyName) and a list of strings (createdPolicyNames), this algorithm returns `"Blocked"` if the Trusted Type Policy should not be created, and `"Allowed"` otherwise.

1. Let result be `"Allowed"`.

2. For each policy in global’s CSP list:

   1. Let createViolation be false.

   2. If policy’s directive set does not contain a directive which name is `"trusted-types"`, skip to the next policy.

   3. Let directive be the policy’s directive set’s directive which name is `"trusted-types"`

   4. If createdPolicyNames contains policyName and directive’s value does not contain a tt-keyword which is a match for a value `'allow-duplicates'`, set createViolation to true.

      Note: `trusted-types policyA policyB 'allow-duplicates'` allows authors to create policies with duplicated names.

   5. If directive’s value does not contain a tt-policy-name, which value is policyName, set createViolation to true.

   6. If createViolation is false, skip to the next policy.

   7. Let violation be the result of executing Create a violation object for global, policy, and directive on global, policy and `"trusted-types"`

   8. Set violation’s resource to `"trusted-types-policy"`.

   9. Set violation’s sample to the substring of policyName, containing its first 40 characters.

   10. Execute Report a violation on violation.

   11. If policy’s disposition is `"enforce"`, then set result to `"Blocked"`.

3. Return result.

#### 4.5.5. Violation object changes

Violation object resource also allows `"trusted-types-policy"` and `"trusted-types-sink"` as values.

#### 4.5.6. Support for eval(TrustedScript)

This document modifies the EnsureCSPDoesNotBlockStringCompilation which is reproduced in its entirety below with additions and deletions.

Note: See TC39/ecma262 issue #938 (adding the value to be compiled to algorithm parameters).

Note: EcmaScript code may call `Function()` and `eval` cross realm.

    let f = new self.top.Function(source);

In this case, the callerRealm’s Window is `self` and the calleeRealm’s Window is `self.top`. The Trusted Types portion of this algorithm uses calleeRealm for consistency with other sinks.

    // Assigning a string to another Realm’s DOM sink uses that Realm’s default policy.
    self.top.body.innerHTML = 'Hello, World!';
    // Using another Realm’s builtin Function constructor should analogously use that
    // Realm’s default policy.
    new self.top.Function('alert(1)')()

This is subtly different from the CSP directive enforcement portion which rejects if either the calleeRealm or callerRealm’s Content-Security-Policy rejects string compilation.

Given two realms (callerRealm and calleeRealm), and a string value (source), this algorithm returns normally

the source string to compile if compilation is allowed, and throws an "`EvalError`" if not:

1. Let sourceString be the result of executing the Get Trusted Type compliant string algorithm, with:

   - calleeRealm as global,

   - source as input,

   - `eval` as sink,

   - `'script'` as sinkGroup,

   - `TrustedScript` as expectedType.

2. If the algorithm throws an error, throw an `EvalError`.

3. Let globals be a list containing calleeRealm’s global object and calleeRealm’s global object.

4. For each global in globals:

   1. Let result be "`Allowed`".

   2. For each policy in global’s CSP list:

      1. Let source-list be `null`.

      2. If policy contains a directive whose name is "`script-src`", then set source-list to that directive's value.

         Otherwise if policy contains a directive whose name is "`default-src`", then set source-list to that directive’s value.

      3. If source-list is not `null`, and does not contain a source expression which is an ASCII case-insensitive match for the string "`'unsafe-eval'`" then:

         1. Let violation be the result of executing Content Security Policy Level 3 §create-violation-for-global on global, policy, and "`script-src`".

         2. Set violation’s resource to "`inline`".

         3. If source-list contains the expression "`'report-sample'`", then set violation’s sample to the substring of source sourceString containing its first 40 characters.

         4. Execute Content Security Policy Level 3 §report-violation on violation.

         5. If policy’s disposition is "`enforce`", then set result to "`Blocked`".

   3. If result is "`Blocked`", throw an `EvalError` exception.

5. Return sourceString.

Note: returning sourceString means that the string that gets compiled is that returned by any default policy in the course of executing Get Trusted Type compliant string.

This depends on a solution to issue #144 like TC39 HostBeforeCompile

In some cases, the violation "`'report-sample'`" contain the result of applying the default policy to a string argument which differs. Specifically when, there is a default policy, isExempt is false, and source there is a CSP policy for either the callerRealm or callerRealm that disallows "`'unsafe-eval'"`. Is this a feature or a bug?

Note: The previous algorithm reports violations via both report-uris where callerRealm != calleeRealm. If Get Trusted Type compliant string reports an error, it only reports it via its calleeRealm’s report-uri.

## 5. Security Considerations

Trusted Types are not intended to protect access to injection sinks in an actively malicious execution environment. It’s assumed that the application is written by non-malicious authors; the intent is to prevent developer mistakes that could result in security bugs, and not to defend against first-party malicious code actively trying to bypass policy restrictions. Below we enumerate already identified vectors that remain risky even in environments with enforced Trusted Types.

### 5.1. Cross-document vectors

While the code running in a window in which Trusted Types are enforced cannot dynamically create nodes that would bypass the policy restrictions, it is possible that such nodes can be imported or adopted from documents in other windows, that don’t have the same set of restrictions. In essence - it is possible to bypass Trusted Types if a malicious author creates a setup in which a restricted document colludes with an unrestricted one.

CSP propagation rules (see Content Security Policy Level 3 §initialize-document-csp partially address this issue, as new local scheme documents will inherit the same set of restrictions. To address this issue comprehensively, other mechanisms like Origin Policy should be used to ensure that baseline security rules are applied for the whole origin.

### 5.2. Deprecated features

Some long-deprecated and rarely used plaform features are not subject to Trusted Types, and could potentially be used by malicious authors to overcome the restrictions:

- HTML imports

### 5.3. Best practices for policy design

Trusted Types limit the scope of the code that can introduce vulnerabilities via injection sinks to the implementation of policies. In this design, insecure policies can still expose injection sinks to untrusted data. Special emphasis needs to be taken by use policies that are either secure for all possible inputs, or limit the access to insecure policies, such that they are only called with non-attacker controlled inputs.

As policies are custom JavaScript code, they may be written in a way that heavily depends on a global state. We advise against this. The policies should be self-contained as much as possible. All objects that may alter security decisions a policy makes effectively become the policy, and should be guarded & reviewed together.

Refer to the external document on secure policy design.

## 6. Implementation Considerations

### 6.1. Vendor-specific Extensions and Addons

Restriction imposed by Trusted Types SHOULD NOT interfere with the operation of user-agent features like addons, extensions, or bookmarklets. These kinds of features generally advance the user’s priority over page authors, as espoused in [html-design-principles]. Specifically, extensions SHOULD be able to pass strings to the injection sinks without triggering default policy execution, violation generation, or the rejection of the value.

## Conformance

### Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with `class="example"`, like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with `class="note"`, like this:

Note, this is an informative note.

### Conformant Algorithms

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize.

## Index

### Terms defined by this specification

- append an attribute, in §4.3
- attribute validation steps, in §4.3
- codeBase, in §4.1.4
- Create a Trusted Type, in §3.2
- Create a Trusted Type Policy, in §3.1
- createContextualFragment(fragment), in §4.4
- createHTML, in §2.3.3
- CreateHTMLCallback, in §2.3.3
- createHTML(input), in §2.3.2
- createHTML(input, ...arguments), in §2.3.2
- createPolicy(policyName), in §2.3.1
- createPolicy(policyName, policyOptions), in §2.3.1
- createScript, in §2.3.3
- CreateScriptCallback, in §2.3.3
- createScript(input), in §2.3.2
- createScript(input, ...arguments), in §2.3.2
- createScriptURL, in §2.3.3
- CreateScriptURLCallback, in §2.3.3
- createScriptURL(input), in §2.3.2
- createScriptURL(input, ...arguments), in §2.3.2
- data, in §4.1.4
- Default policy, in §2.3.4
- defaultPolicy, in §2.3.1
- DOMParser, in §4.4
- emptyHTML, in §2.3.1
- emptyScript, in §2.3.1
- Enforcement, in §2.4
- getAttributeType(tagName, attribute), in §2.3.1
- getAttributeType(tagName, attribute, elementNs), in §2.3.1
- getAttributeType(tagName, attribute, elementNs, attrNs), in §2.3.1
- getPolicyNames(), in §2.3.1
- getPropertyType(tagName, property), in §2.3.1
- getPropertyType(tagName, property, elementNs), in §2.3.1
- Get Trusted Type compliant string, in §3.3
- href, in §4.2
- HTMLString, in §4
- HTMLStringDefaultsEmpty, in §4
- injection sink, in §2.1
- innerHTML, in §4.4
- innerText, in §4.1.3.2
- insertAdjacentHTML(position, text), in §4.4
- isHTML(value), in §2.3.1
- isScriptURL(value), in §2.3.1
- isScript(value), in §2.3.1
- list of scripts that will execute in order as soon as possible, in §4.1.3.3
- list of scripts that will execute when the document has finished parsing, in §4.1.3.3
- name
  - attribute for TrustedTypePolicy, in §2.3.2
  - dfn for TrustedTypePolicy, in §2.3.2
- outerHTML, in §4.4
- parseFromString(str, type), in §4.4
- Policies, in §2.3
- Prepare the script URL and text, in §3.5
- Process value with a default policy, in §3.4
- require-trusted-types-for-directive, in §4.5.1
- ScriptString, in §4
- [[ScriptText]], in §4.1.3.1
- [[ScriptURL]], in §4.1.3.1
- ScriptURLString, in §4
- serialized-tt-configuration, in §4.5.2
- setInterval(handler), in §4.1.5
- setInterval(handler, timeout), in §4.1.5
- setInterval(handler, timeout, ...arguments), in §4.1.5
- set of scripts that will execute as soon as possible, in §4.1.3.3
- setTimeout(handler), in §4.1.5
- setTimeout(handler, timeout), in §4.1.5
- setTimeout(handler, timeout, ...arguments), in §4.1.5
- Should sink type mismatch violation be blocked by Content Security Policy?, in §4.5.3
- Should Trusted Type policy creation be blocked by Content Security Policy?, in §4.5.4
- src
  - attribute for HTMLEmbedElement, in §4.1.4
  - attribute for HTMLScriptElement, in §4.1.3.2
- srcdoc, in §4.1.4
- stringification behavior
  - dfn for TrustedHTML, in §2.2.1
  - dfn for TrustedScript, in §2.2.2
  - dfn for TrustedScriptURL, in §2.2.3
- text, in §4.1.3.2
- textContent, in §4.1.3.2
- TrustedHTML
  - (interface), in §2.2.1
  - (type), in §2.2.1
- TrustedScript
  - (interface), in §2.2.2
  - (type), in §2.2.2
- TrustedScriptURL
  - (interface), in §2.2.3
  - (type), in §2.2.3
- TrustedTimerHandler, in §4.1.5
- Trusted Type, in §2.2
- TrustedType, in §4
- TrustedTypePolicy
  - (interface), in §2.3.2
  - (type), in §2.3.2
- trusted type policy factory, in §4.1
- TrustedTypePolicyFactory
  - (interface), in §2.3.1
  - (type), in §2.3.1
- TrustedTypePolicyOptions
  - (dictionary), in §2.3.3
  - (type), in §2.3.3
- TrustedTypes, in §2.4.2
- trustedTypes, in §4.1.1
- trusted-types-directive, in §4.5.2
- trusted-types-sink-group, in §4.5.1
- tt-expression, in §4.5.2
- tt-keyword, in §4.5.2
- tt-policy-name, in §4.5.2
- write(), in §4.1.2
- writeln(), in §4.1.2
- writeln(...text), in §4.1.2
- write(...text), in §4.1.2

https://dom.spec.whatwg.org/#document Referenced in:

- 2.1.1. HTML injection sinks
- 3.5. Prepare the script URL and text (2)
- 4.1.2. Extensions to the Document interface (2)
- 4.4. Integration with DOM Parsing

https://dom.spec.whatwg.org/#documentfragment Referenced in:

- 4.4. Integration with DOM Parsing

https://dom.spec.whatwg.org/#element Referenced in:

- 2.1.2. DOM XSS injection sinks (2)
- 2.3.1. TrustedTypePolicyFactory (2)
- 2.4.2. TrustedTypes extended attribute (2)
- 4.3. Integration with DOM
- 4.4. Integration with DOM Parsing

https://dom.spec.whatwg.org/#range Referenced in:

- 4.4. Integration with DOM Parsing

https://dom.spec.whatwg.org/#concept-node-append Referenced in:

- 4.3. Integration with DOM

https://dom.spec.whatwg.org/#concept-attribute Referenced in:

- 2.3.1. TrustedTypePolicyFactory (2) (3)
- 2.4.2. TrustedTypes extended attribute (2)
- 4.3. Integration with DOM

https://dom.spec.whatwg.org/#concept-element-attributes-change-ext Referenced in:

- 4.1.6. Enforcement in event handler content attributes

https://dom.spec.whatwg.org/#concept-element-attribute Referenced in:

- 4.3. Integration with DOM

https://dom.spec.whatwg.org/#concept-child-text-content Referenced in:

- 3.5. Prepare the script URL and text (2)
- 4.1.3.1. Slots with trusted values
- 4.1.3.2. Setting slot values
- 4.1.3.3. Slot value verification

https://dom.spec.whatwg.org/#context-object Referenced in:

- 2.3.1. TrustedTypePolicyFactory (2)
- 2.4.2. TrustedTypes extended attribute (2) (3) (4) (5) (6) (7) (8) (9) (10)
- 4.1.5. Enforcement in timer functions

https://dom.spec.whatwg.org/#concept-attribute-element Referenced in:

- 4.3. Integration with DOM

https://dom.spec.whatwg.org/#concept-element-interface Referenced in:

- 2.3.1. TrustedTypePolicyFactory (2)

https://dom.spec.whatwg.org/#concept-element-local-name Referenced in:

- 2.4.2. TrustedTypes extended attribute (2)
- 4.1.6. Enforcement in event handler content attributes

https://dom.spec.whatwg.org/#concept-attribute-namespace Referenced in:

- 4.3. Integration with DOM

https://dom.spec.whatwg.org/#other-applicable-specifications Referenced in:

- 4.3. Integration with DOM

https://dom.spec.whatwg.org/#dom-node-textcontent Referenced in:

- 4.1.3.2. Setting slot values (2)

https://dom.spec.whatwg.org/#concept-attribute-value Referenced in:

- 4.3. Integration with DOM (2)

https://www.w3.org/TR/DOM-Parsing/#h-the-domparser-interface Referenced in:

- 4.4. Integration with DOM Parsing

https://fetch.spec.whatwg.org/#dom-requestdestination-script Referenced in:

- 3.5. Prepare the script URL and text
- 4.1.3.1. Slots with trusted values
- 4.1.3.3. Slot value verification

https://fetch.spec.whatwg.org/#concept-request-client Referenced in:

- 4.5.1.1. require-trusted-types-for Pre-Navigation check

https://fetch.spec.whatwg.org/#local-scheme Referenced in:

- 5.1. Cross-document vectors

https://fetch.spec.whatwg.org/#concept-request-url Referenced in:

- 4.5.1.1. require-trusted-types-for Pre-Navigation check (2) (3)

https://html.spec.whatwg.org/multipage/custom-elements.html#cereactions Referenced in:

- 4.1.2. Extensions to the Document interface (2)
- 4.1.3.2. Setting slot values (2) (3) (4)
- 4.1.4. Enforcement in element attributes (2) (3) (4)
- 4.4. Integration with DOM Parsing (2) (3) (4)

https://html.spec.whatwg.org/multipage/dom.html#htmlelement Referenced in:

- 4.1.3.2. Setting slot values
- 4.1.4. Enforcement in element attributes (2) (3)

https://html.spec.whatwg.org/multipage/iframe-embed-object.html#htmlembedelement Referenced in:

- 4.1.4. Enforcement in element attributes

https://html.spec.whatwg.org/multipage/iframe-embed-object.html#htmliframeelement Referenced in:

- 4.1.4. Enforcement in element attributes

https://html.spec.whatwg.org/multipage/iframe-embed-object.html#htmlobjectelement Referenced in:

- 4.1.4. Enforcement in element attributes

https://html.spec.whatwg.org/multipage/scripting.html#htmlscriptelement Referenced in:

- 4.1.3.2. Setting slot values (2) (3)

https://html.spec.whatwg.org/multipage/window-object.html#window Referenced in:

- 3.3. Get Trusted Type compliant string
- 4.1. Integration with HTML
- 4.1.1. Extensions to the Window interface (2) (3)

https://html.spec.whatwg.org/multipage/webappapis.html#windoworworkerglobalscope Referenced in:

- 4.1.5. Enforcement in timer functions (2)

https://html.spec.whatwg.org/multipage/webappapis.html#concept-settings-object-global Referenced in:

- 4.5.1.1. require-trusted-types-for Pre-Navigation check

https://html.spec.whatwg.org/multipage/dom.html#dom-innertext Referenced in:

- 4.1.3.2. Setting slot values (2)

https://html.spec.whatwg.org/multipage/scripting.html#prepare-a-script Referenced in:

- 4.1.3.3. Slot value verification

https://html.spec.whatwg.org/multipage/webappapis.html#concept-global-object-realm Referenced in:

- 2.3. Policies
- 4.5.1. require-trusted-types-for directive

https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflect Referenced in:

- 2.3.1. TrustedTypePolicyFactory

https://html.spec.whatwg.org/multipage/webappapis.html#concept-relevant-global Referenced in:

- 2.3.1. TrustedTypePolicyFactory
- 2.4.2. TrustedTypes extended attribute (2) (3) (4)
- 3.5. Prepare the script URL and text (2)
- 4.1.5. Enforcement in timer functions
- 4.1.6. Enforcement in event handler content attributes

https://infra.spec.whatwg.org/#list-append Referenced in:

- 4.3. Integration with DOM

https://infra.spec.whatwg.org/#ascii-case-insensitive Referenced in:

- 4.1.3.3. Slot value verification (2) (3)
- 4.5.6. Support for eval(TrustedScript)

https://infra.spec.whatwg.org/#ascii-lowercase Referenced in:

- 2.3.1. TrustedTypePolicyFactory (2) (3)

https://infra.spec.whatwg.org/#string-concatenate Referenced in:

- 2.4.2. TrustedTypes extended attribute (2)
- 4.1.6. Enforcement in event handler content attributes
- 4.5.3. Should sink type mismatch violation be blocked by Content Security Policy?

https://infra.spec.whatwg.org/#list-contain Referenced in:

- 4.5.6. Support for eval(TrustedScript)

https://infra.spec.whatwg.org/#html-namespace Referenced in:

- 2.3.1. TrustedTypePolicyFactory (2)

https://infra.spec.whatwg.org/#ordered-set Referenced in:

- 2.3.1. TrustedTypePolicyFactory

https://svgwg.org/svg2-draft/types.html#InterfaceSVGElement Referenced in:

- 4.2. Integration with SVG

https://svgwg.org/svg2-draft/interact.html#InterfaceSVGScriptElement Referenced in:

- 4.2. Integration with SVG (2)

https://url.spec.whatwg.org/#concept-url-scheme Referenced in:

- 4.5.1.1. require-trusted-types-for Pre-Navigation check

https://url.spec.whatwg.org/#concept-url-parser Referenced in:

- 4.5.1.1. require-trusted-types-for Pre-Navigation check

https://url.spec.whatwg.org/#concept-url-serializer Referenced in:

- 4.5.1.1. require-trusted-types-for Pre-Navigation check

https://heycam.github.io/webidl/#idl-DOMString Referenced in:

- 2.3.1. TrustedTypePolicyFactory (2) (3) (4) (5) (6) (7) (8) (9) (10) (11)
- 2.3.2. TrustedTypePolicy (2) (3) (4)
- 2.3.3. TrustedTypePolicyOptions (2) (3) (4) (5)
- 4. Integrations (2) (3)
- 4.1.4. Enforcement in element attributes
- 4.4. Integration with DOM Parsing

https://heycam.github.io/webidl/#exceptiondef-evalerror Referenced in:

- 4.5.6. Support for eval(TrustedScript)

https://heycam.github.io/webidl/#Exposed Referenced in:

- 2.2.1. TrustedHTML
- 2.2.2. TrustedScript
- 2.2.3. TrustedScriptURL
- 2.3.1. TrustedTypePolicyFactory
- 2.3.2. TrustedTypePolicy
- 4.4. Integration with DOM Parsing

https://heycam.github.io/webidl/#Function Referenced in:

- 4.1.5. Enforcement in timer functions (2) (3)

https://heycam.github.io/webidl/#NewObject Referenced in:

- 4.4. Integration with DOM Parsing (2)

https://heycam.github.io/webidl/#TreatNullAs Referenced in:

- 4. Integrations
- 4.1.3.2. Setting slot values

https://heycam.github.io/webidl/#exceptiondef-typeerror Referenced in:

- 3.1. Create a Trusted Type Policy (2)
- 3.2. Create a Trusted Type
- 3.3. Get Trusted Type compliant string

https://heycam.github.io/webidl/#idl-USVString Referenced in:

- 2.3.3. TrustedTypePolicyOptions
- 4. Integrations

https://heycam.github.io/webidl/#Unforgeable Referenced in:

- 2.3.1. TrustedTypePolicyFactory (2) (3) (4) (5) (6) (7)
- 2.3.2. TrustedTypePolicy (2) (3) (4)
- 4.1.1. Extensions to the Window interface

https://heycam.github.io/webidl/#idl-boolean Referenced in:

- 2.3.1. TrustedTypePolicyFactory (2) (3)

https://heycam.github.io/webidl/#dfn-extended-attribute Referenced in:

- 2.4.2. TrustedTypes extended attribute

https://heycam.github.io/webidl/#include Referenced in:

- 2.3.1. TrustedTypePolicyFactory

https://heycam.github.io/webidl/#interface-mixin Referenced in:

- 2.3.1. TrustedTypePolicyFactory

https://heycam.github.io/webidl/#idl-long Referenced in:

- 4.1.5. Enforcement in timer functions (2) (3) (4)

https://heycam.github.io/webidl/#dfn-operation Referenced in:

- 2.4.2. TrustedTypes extended attribute (2) (3)

https://heycam.github.io/webidl/#dfn-read-only Referenced in:

- 2.4.2. TrustedTypes extended attribute

https://heycam.github.io/webidl/#dfn-xattr-identifier Referenced in:

- 2.4.2. TrustedTypes extended attribute

### Terms defined by reference

- [DOM] defines the following terms:
  - Document
  - DocumentFragment
  - Element
  - Range
  - append
  - attribute
  - attribute change steps
  - attribute list
  - child text content
  - context object
  - element (for Attr)
  - element interface
  - local name (for Element)
  - namespace
  - other applicable specifications
  - textContent
  - value
- [DOM-Parsing] defines the following terms:
  - SupportedType
- [Fetch] defines the following terms:
  - "script"
  - client
  - local scheme
  - url
- [HTML] defines the following terms:
  - CEReactions
  - HTMLElement
  - HTMLEmbedElement
  - HTMLIFrameElement
  - HTMLObjectElement
  - HTMLScriptElement
  - Window
  - WindowOrWorkerGlobalScope
  - global object (for environment settings object)
  - innerText
  - prepare a script
  - realm
  - reflect
  - relevant global object
- [INFRA] defines the following terms:
  - append
  - ascii case-insensitive
  - ascii lowercase
  - concatenate
  - contain
  - html namespace
  - ordered set
- [SVG2] defines the following terms:
  - SVGElement
  - SVGScriptElement
- [URL] defines the following terms:
  - scheme
  - url parser
  - url serializer
- [WebIDL] defines the following terms:
  - DOMString
  - EvalError
  - Exposed
  - Function
  - NewObject
  - TreatNullAs
  - TypeError
  - USVString
  - Unforgeable
  - boolean
  - extended attribute
  - include
  - interface mixin
  - long
  - operation
  - read only
  - takes an identifier

## References

### Normative References

[CSP3]
  Mike West. Content Security Policy Level 3. 15 October 2018. WD. URL: https://www.w3.org/TR/CSP3/
[DOM]
  Anne van Kesteren. DOM Standard. Living Standard. URL: https://dom.spec.whatwg.org/
[DOM-Parsing]
  Travis Leithead. DOM Parsing and Serialization. 17 May 2016. WD. URL: https://www.w3.org/TR/DOM-Parsing/
[Fetch]
  Anne van Kesteren. Fetch Standard. Living Standard. URL: https://fetch.spec.whatwg.org/
[HTML]
  Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[INFRA]
  Anne van Kesteren; Domenic Denicola. Infra Standard. Living Standard. URL: https://infra.spec.whatwg.org/
[RFC2119]
  S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[SVG2]
  Amelia Bellamy-Royds; et al. Scalable Vector Graphics (SVG) 2. 4 October 2018. CR. URL: https://www.w3.org/TR/SVG2/
[URL]
  Anne van Kesteren. URL Standard. Living Standard. URL: https://url.spec.whatwg.org/
[WebIDL]
  Boris Zbarsky. Web IDL. 15 December 2016. ED. URL: https://heycam.github.io/webidl/

### Informative References

[HTML-DESIGN-PRINCIPLES]
  Anne van Kesteren; Maciej Stachowiak. HTML Design Principles. 26 November 2007. WD. URL: https://www.w3.org/TR/html-design-principles/
[HTML5]
  Ian Hickson; et al. HTML5. 27 March 2018. REC. URL: https://www.w3.org/TR/html5/

## IDL Index

    [Exposed=Window]
    interface TrustedHTML {
      stringifier;
    };

    [Exposed=Window]
    interface TrustedScript {
      stringifier;
    };

    [Exposed=Window]
    interface TrustedScriptURL {
      stringifier;
    };

    [Exposed=Window] interface TrustedTypePolicyFactory {
        [Unforgeable] TrustedTypePolicy createPolicy(
            DOMString policyName, optional TrustedTypePolicyOptions policyOptions);
        [Unforgeable] sequence<DOMString> getPolicyNames();
        [Unforgeable] boolean isHTML(any value);
        [Unforgeable] boolean isScript(any value);
        [Unforgeable] boolean isScriptURL(any value);
        [Unforgeable] readonly attribute TrustedHTML emptyHTML;
        [Unforgeable] readonly attribute TrustedScript emptyScript;
        DOMString? getAttributeType(
            DOMString tagName,
            DOMString attribute,
            optional DOMString elementNs = "",
            optional DOMString attrNs = "");
        DOMString? getPropertyType(
            DOMString tagName,
            DOMString property,
            optional DOMString elementNs = "");
        readonly attribute TrustedTypePolicy? defaultPolicy;
    };

    [Exposed=Window]
    interface TrustedTypePolicy {
      [Unforgeable] readonly attribute DOMString name;
      [Unforgeable] TrustedHTML createHTML(DOMString input, any... arguments);
      [Unforgeable] TrustedScript createScript(DOMString input, any... arguments);
      [Unforgeable] TrustedScriptURL createScriptURL(DOMString input, any... arguments);
    };

    dictionary TrustedTypePolicyOptions {
       CreateHTMLCallback? createHTML;
       CreateScriptCallback? createScript;
       CreateScriptURLCallback? createScriptURL;
    };
    callback CreateHTMLCallback = DOMString (DOMString input, any... arguments);
    callback CreateScriptCallback = DOMString (DOMString input, any... arguments);
    callback CreateScriptURLCallback = USVString (DOMString input, any... arguments);

    typedef (DOMString or TrustedHTML) HTMLString;
    typedef (DOMString or TrustedScript) ScriptString;
    typedef (USVString or TrustedScriptURL) ScriptURLString;
    typedef (TrustedHTML or TrustedScript or TrustedScriptURL) TrustedType;

    typedef (([TreatNullAs=EmptyString] DOMString) or TrustedHTML) HTMLStringDefaultsEmpty;

    partial interface mixin Window {
      [Unforgeable] readonly attribute
          TrustedTypePolicyFactory trustedTypes;
    };

    partial interface mixin Document {
      [CEReactions] void write([TrustedTypes=TrustedHTML] HTMLString... text);
      [CEReactions] void writeln([TrustedTypes=TrustedHTML] HTMLString... text);
    };

    partial interface mixin HTMLScriptElement : HTMLElement {
     [CEReactions, TrustedTypes=TrustedScript] attribute [TreatNullAs=EmptyString] ScriptString innerText;
     [CEReactions, TrustedTypes=TrustedScript] attribute ScriptString? textContent;
     [CEReactions, TrustedTypes=TrustedScriptURL] attribute ScriptURLString src;
     [CEReactions, TrustedTypes=TrustedScript] attribute ScriptString text;
    };

    partial interface mixin HTMLIFrameElement : HTMLElement {
      [CEReactions, TrustedTypes=TrustedHTML] attribute HTMLString srcdoc;
    };

    partial interface HTMLEmbedElement : HTMLElement {
      [CEReactions, TrustedTypes=TrustedScriptURL] attribute ScriptURLString src;
    };

    partial interface HTMLObjectElement : HTMLElement {
      [CEReactions, TrustedTypes=TrustedScriptURL] attribute ScriptURLString data;
      [CEReactions, TrustedTypes=TrustedScriptURL] attribute DOMString codeBase; // obsolete
    };

    typedef (ScriptString or Function) TrustedTimerHandler;

    partial interface mixin WindowOrWorkerGlobalScope {
      long setTimeout(TrustedTimerHandler handler, optional long timeout = 0, any... arguments);
      long setInterval(TrustedTimerHandler handler, optional long timeout = 0, any... arguments);
    };

    partial interface mixin SVGScriptElement : SVGElement {
     // overwrites the definition in SVGURIReference.
     [TrustedTypes=TrustedScriptURL] readonly attribute ScriptURLString href;
    };

    partial interface Element {
      [CEReactions, TrustedTypes=TrustedHTML] attribute HTMLStringDefaultsEmpty outerHTML;
      [CEReactions] void insertAdjacentHTML(DOMString position, [TrustedTypes=TrustedHTML] HTMLString text);
    };

    partial interface mixin InnerHTML { // specified in a draft version at https://w3c.github.io/DOM-Parsing/#the-innerhtml-mixin
      [CEReactions, TrustedTypes=TrustedHTML] attribute HTMLStringDefaultsEmpty innerHTML;
    };

    partial interface Range {
      [CEReactions, NewObject] DocumentFragment createContextualFragment([TrustedTypes=TrustedHTML] HTMLString fragment);
    };

    [Constructor, Exposed=Window]
    interface DOMParser {
      [NewObject] Document parseFromString([TrustedTypes=TrustedHTML] HTMLString str, SupportedType type);
    };

## Issues Index

Update when workers have TT. ↵
Remove hardcoding 'script' when new sink groups are specified. ↵
Update when workers have TT. ↵
Remove hardcoding 'script' when new sink types are specified. ↵
Synchronize when TT are added to workers (perhaps use "has a CSP list"?) ↵
TreatNullAs=EmptyString is confusing. See note "It should not be used in specifications unless ...". For some sinks a `null` value will result in "", and "null" for others. This already caused problems in the polyfill. <https://github.com/w3c/webappsec-trusted-types/issues/2> ↵
Define for workers. ↵
Remove the note when the API in Chrome is shipped. ↵
Figure out what to do with script.setAttribute('src'). See DOM#789. ↵
Add base.href enforcement. ↵
Remove when DOM #809 is merged. ↵
This depends on a solution to issue #144 like TC39 HostBeforeCompile ↵
In some cases, the violation "`'report-sample'`" contain the result of applying the default policy to a string argument which differs. Specifically when, there is a default policy, isExempt is false, and source there is a CSP policy for either the callerRealm or callerRealm that disallows "`'unsafe-eval'"`. Is this a feature or a bug? ↵
Refer to the external document on secure policy design. ↵
#injection-sink Referenced in:

- 1. Introduction
- 2.1. Injection sinks
- 2.1.1. HTML injection sinks
- 2.1.2. DOM XSS injection sinks
- 2.2. Trusted Types
- 2.2.1. TrustedHTML
- 2.2.2. TrustedScript
- 2.2.3. TrustedScriptURL
- 2.3. Policies (2) (3) (4)
- 2.3.4. Default policy (2)
- 2.4. Enforcement (2) (3)
- 2.4.1. Content Security Policy
- 2.4.2. TrustedTypes extended attribute
- 3.3. Get Trusted Type compliant string
- 3.4. Process value with a default policy
- 4.5.1. require-trusted-types-for directive (2)
- 4.5.2. trusted-types directive (2)
- 4.5.3. Should sink type mismatch violation be blocked by Content Security Policy?
- 5. Security Considerations
- 5.3. Best practices for policy design (2)
- 6.1. Vendor-specific Extensions and Addons

#trusted-type Referenced in:

- 2.3. Policies
- 2.3.1. TrustedTypePolicyFactory
- 2.3.3. TrustedTypePolicyOptions
- 2.4. Enforcement
- 3.3. Get Trusted Type compliant string
- 4.5.3. Should sink type mismatch violation be blocked by Content Security Policy?

#trustedhtml Referenced in:

- 2.3. Policies
- 2.3.1. TrustedTypePolicyFactory (2) (3) (4)
- 2.3.2. TrustedTypePolicy
- 2.4.2. TrustedTypes extended attribute
- 4. Integrations (2) (3)
- 4.1.2. Extensions to the Document interface (2)
- 4.1.4. Enforcement in element attributes
- 4.4. Integration with DOM Parsing (2) (3) (4) (5)

#trustedscript Referenced in:

- 2.3.1. TrustedTypePolicyFactory (2) (3) (4)
- 2.3.2. TrustedTypePolicy
- 2.4.2. TrustedTypes extended attribute
- 4. Integrations (2)
- 4.1.3.2. Setting slot values (2) (3)
- 4.1.5. Enforcement in timer functions (2)
- 4.1.6. Enforcement in event handler content attributes
- 4.5.1.1. require-trusted-types-for Pre-Navigation check (2)
- 4.5.6. Support for eval(TrustedScript)

#trustedscripturl Referenced in:

- 2.3.1. TrustedTypePolicyFactory
- 2.3.2. TrustedTypePolicy
- 2.4.2. TrustedTypes extended attribute
- 3.5. Prepare the script URL and text (2)
- 4. Integrations (2)
- 4.1.3.2. Setting slot values
- 4.1.4. Enforcement in element attributes (2) (3)
- 4.2. Integration with SVG

#policies Referenced in:

- 1. Introduction
- 1.3. Use cases
- 2.3. Policies
- 2.4. Enforcement
- 2.4.1. Content Security Policy
- 4.5.2. trusted-types directive
- 5.3. Best practices for policy design

#trustedtypepolicyfactory Referenced in:

- 3.1. Create a Trusted Type Policy
- 4.1. Integration with HTML
- 4.1.1. Extensions to the Window interface

#dom-trustedtypepolicyfactory-createpolicy Referenced in:

- 2.3. Policies (2)
- 2.3.1. TrustedTypePolicyFactory

#dom-trustedtypepolicyfactory-getpolicynames Referenced in:

- 2.3.1. TrustedTypePolicyFactory

#dom-trustedtypepolicyfactory-ishtml Referenced in:

- 2.3.1. TrustedTypePolicyFactory

#dom-trustedtypepolicyfactory-isscript Referenced in:

- 2.3.1. TrustedTypePolicyFactory

#dom-trustedtypepolicyfactory-isscripturl Referenced in:

- 2.3.1. TrustedTypePolicyFactory

#dom-trustedtypepolicyfactory-getpropertytype Referenced in:

- 2.3.1. TrustedTypePolicyFactory

#dom-trustedtypepolicyfactory-getattributetype Referenced in:

- 2.3.1. TrustedTypePolicyFactory

#dom-trustedtypepolicyfactory-emptyhtml Referenced in:

- 2.3.1. TrustedTypePolicyFactory

#dom-trustedtypepolicyfactory-emptyscript Referenced in:

- 2.3.1. TrustedTypePolicyFactory

#dom-trustedtypepolicyfactory-defaultpolicy Referenced in:

- 2.3.1. TrustedTypePolicyFactory

#trustedtypepolicy Referenced in:

- 2.2.1. TrustedHTML
- 2.2.2. TrustedScript
- 2.2.3. TrustedScriptURL
- 2.3.1. TrustedTypePolicyFactory (2) (3) (4) (5)
- 2.3.3. TrustedTypePolicyOptions
- 3.1. Create a Trusted Type Policy (2)
- 3.2. Create a Trusted Type

#trustedtypepolicy-name Referenced in:

- 2.3.4. Default policy
- 3.2. Create a Trusted Type

#dom-trustedtypepolicy-createhtml Referenced in:

- 2.2.1. TrustedHTML
- 2.3.2. TrustedTypePolicy
- 3.1. Create a Trusted Type Policy

#dom-trustedtypepolicy-createscript Referenced in:

- 2.2.2. TrustedScript
- 2.3.2. TrustedTypePolicy
- 3.1. Create a Trusted Type Policy

#dom-trustedtypepolicy-createscripturl Referenced in:

- 2.2.3. TrustedScriptURL
- 2.3.2. TrustedTypePolicy
- 3.1. Create a Trusted Type Policy

#dictdef-trustedtypepolicyoptions Referenced in:

- 2.3.1. TrustedTypePolicyFactory (2)
- 2.3.2. TrustedTypePolicy
- 3.1. Create a Trusted Type Policy (2)

#dom-trustedtypepolicyoptions-createhtml Referenced in:

- 3.1. Create a Trusted Type Policy

#dom-trustedtypepolicyoptions-createscript Referenced in:

- 3.1. Create a Trusted Type Policy

#dom-trustedtypepolicyoptions-createscripturl Referenced in:

- 3.1. Create a Trusted Type Policy

#callbackdef-createhtmlcallback Referenced in:

- 2.3.3. TrustedTypePolicyOptions

#callbackdef-createscriptcallback Referenced in:

- 2.3.3. TrustedTypePolicyOptions

#callbackdef-createscripturlcallback Referenced in:

- 2.3.3. TrustedTypePolicyOptions

#default-policy Referenced in:

- 4.5.1.1. require-trusted-types-for Pre-Navigation check
- 4.5.2. trusted-types directive
- 4.5.6. Support for eval(TrustedScript) (2)
- 6.1. Vendor-specific Extensions and Addons

#enforcement Referenced in:

- 1.3. Use cases
- 2.1. Injection sinks
- 2.1.1. HTML injection sinks
- 2.3. Policies (2)
- 2.3.4. Default policy
- 3.3. Get Trusted Type compliant string

#extendedattrdef-trustedtypes Referenced in:

- 2.3.1. TrustedTypePolicyFactory (2) (3) (4)
- 2.4.2. TrustedTypes extended attribute (2) (3)
- 4.1.2. Extensions to the Document interface (2)
- 4.1.3.1. Slots with trusted values (2)
- 4.1.3.2. Setting slot values (2) (3) (4) (5)
- 4.1.4. Enforcement in element attributes (2) (3) (4)
- 4.2. Integration with SVG
- 4.4. Integration with DOM Parsing (2) (3) (4) (5)

#abstract-opdef-create-a-trusted-type-policy Referenced in:

- 2.3.1. TrustedTypePolicyFactory

#abstract-opdef-create-a-trusted-type Referenced in:

- 2.3.2. TrustedTypePolicy (2) (3)
- 3.4. Process value with a default policy

#abstract-opdef-get-trusted-type-compliant-string Referenced in:

- 2.4.2. TrustedTypes extended attribute (2)
- 3.2. Create a Trusted Type
- 3.5. Prepare the script URL and text (2)
- 4.1.5. Enforcement in timer functions
- 4.1.6. Enforcement in event handler content attributes
- 4.5.6. Support for eval(TrustedScript) (2) (3)

#abstract-opdef-process-value-with-a-default-policy Referenced in:

- 3.3. Get Trusted Type compliant string
- 4.5.1.1. require-trusted-types-for Pre-Navigation check

#abstract-opdef-prepare-the-script-url-and-text Referenced in:

- 4.1.3.3. Slot value verification

#typedefdef-htmlstring Referenced in:

- 4.1.2. Extensions to the Document interface (2)
- 4.1.4. Enforcement in element attributes
- 4.4. Integration with DOM Parsing (2) (3)

#typedefdef-scriptstring Referenced in:

- 4.1.3.2. Setting slot values (2) (3)
- 4.1.5. Enforcement in timer functions

#typedefdef-scripturlstring Referenced in:

- 4.1.3.2. Setting slot values
- 4.1.4. Enforcement in element attributes (2)
- 4.2. Integration with SVG

#typedefdef-trustedtype Referenced in:

- 3.3. Get Trusted Type compliant string (2)
- 3.4. Process value with a default policy (2)
- 4.1.5. Enforcement in timer functions

#typedefdef-htmlstringdefaultsempty Referenced in:

- 4. Integrations
- 4.4. Integration with DOM Parsing (2)

#window-trusted-type-policy-factory Referenced in:

- 2.4.2. TrustedTypes extended attribute (2)
- 3.4. Process value with a default policy

#dom-window-trustedtypes Referenced in:

- 2.4. Enforcement
- 4.1.1. Extensions to the Window interface

#dom-document-write Referenced in:

- 2.1.1. HTML injection sinks

#dom-htmlscriptelement-src Referenced in:

- 2.1.2. DOM XSS injection sinks
- 4.1.3.1. Slots with trusted values
- 4.1.3.2. Setting slot values

#dom-htmlscriptelement-text Referenced in:

- 2.1.2. DOM XSS injection sinks
- 4.1.3.2. Setting slot values

#typedefdef-trustedtimerhandler Referenced in:

- 4.1.5. Enforcement in timer functions (2)

#concept-element-attributes-validation-ext Referenced in:

- 4.3. Integration with DOM (2)

#dom-domparser-parsefromstring Referenced in:

- 2.1.1. HTML injection sinks

#trusted-types-sink-group Referenced in:

- 2.1. Injection sinks
- 2.1.1. HTML injection sinks
- 2.1.2. DOM XSS injection sinks
- 3.3. Get Trusted Type compliant string
- 4.5.1. require-trusted-types-for directive (2)
- 4.5.3. Should sink type mismatch violation be blocked by Content Security Policy?

#trusted-types-directive Referenced in:

- 2.3.1. TrustedTypePolicyFactory

#serialized-tt-configuration Referenced in:

- 4.5.2. trusted-types directive

#tt-expression Referenced in:

- 4.5.2. trusted-types directive (2)

#tt-policy-name Referenced in:

- 4.5.2. trusted-types directive
- 4.5.4. Should Trusted Type policy creation be blocked by Content Security Policy?

#tt-keyword Referenced in:

- 4.5.2. trusted-types directive
- 4.5.4. Should Trusted Type policy creation be blocked by Content Security Policy?

#abstract-opdef-should-sink-type-mismatch-violation-be-blocked-by-content-security-policy Referenced in:

- 3.3. Get Trusted Type compliant string

#abstract-opdef-should-trusted-type-policy-creation-be-blocked-by-content-security-policy Referenced in:

- 3.1. Create a Trusted Type Policy