Trusted Types

[kara]

Description

Author: @koto

Trusted Types enable writing web applications that are free from DOM-Based Cross-Site-Scripting (XSS), the most prevalent web application vulnerability.

DOM-Based XSS occurs when attacker-controlled values reach certain Web API functions, like Element.innerHTML which causes the execution of the attacker's JavaScript code. This pattern is common, especially in larger applications, and detecting it requires complex interprocedural data flow tracking in a dynamic language ( a[b] = c might actually be a vulnerability). Before Trusted Types adoption at Google, DOM-Based XSS accounted for >%50 of XSS reported to Google VRP.

Trusted Types lock down those execution sinks to only accept values that were created securely; either because they are static values in the code or because they were created through author-created policies. One can also create a default, catch-all policy, e.g. to sanitize HTML or programmatically control where the scripts can be loaded from.

The lockdown is controlled via CSP, which enables breakage-free rollouts with report-only mode, and gradual, backwards-compatible code migration - using the new APIs without locking down the execution sinks. In fact, about 60% of pages rendered by Chrome globally already use Trusted Types, likely via inclusion of Alphabet's libraries, whereas around 14% of the traffic enforces Trusted Types via CSP.

Altogether, Trusted Types enable both writing new applications that are XSS-free, and eliminating DOM-Based XSS from existing applications, with a track record from Microsoft, Meta and Alphabet adoptions. As a data point, Alphabet applications migrated to Trusted Types have 0 reported XSS against them and we only see these bugs in applications not yet migrated, which is a significant reduction. In 2018 Google VRP rewarded $360K for all XSSes, in 2022 it was $95K.

Specification

https://www.w3.org/TR/2022/WD-trusted-types-20220927/

Open Issues

No response

Tests

https://wpt.fyi/results/trusted-types

Current Implementations

• Blink
• Gecko
• WebKit

Standards Positions

Firefox: mozilla/standards-positions#20

Safari: WebKit/standards-positions#186

Browser bug reports

Limited feedback, but https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3ESecurityFeature%3ETrustedTypes&can=1

Developer discussions

Trusted Types rollouts - w3c
Trusted Types - mid 2021 report

Meta uses Trusted Types by default for new products, and rolls out TT enforcement in existing products (in 2022 they reported 50% already migrated).
MS uses Trusted Types for Edge integration applications (Bing Collections), and in Edge WebUI pages.

Integration of Trusted Types completed or ongoing for several libraries and frameworks (https://github.com/w3c/trusted-types/wiki/Integrations) - the page might be a bit outdated, e.g.

• TT are supported in Next.js
• TT are a top priority for the Angular framework, as it would allow them to move away from user space-level safe-value constructs.

Polls & Surveys

No response

Existing Usage

https://chromestatus.com/metrics/feature/timeline/popularity/3279 (60% of page loads create a Trusted Types Policy in main document, or a subframe)
https://chromestatus.com/metrics/feature/timeline/popularity/2724 (0.2% use a default Trusted Type policy)
https://chromestatus.com/metrics/feature/timeline/popularity/3160 (12.5% enforce Trusted Types via CSP)
https://chromestatus.com/metrics/feature/timeline/popularity/3161 (2.8% use a report-only Trusted Types CSP)

Workarounds

No response

Accessibility Impact

No response

Privacy Impact

No response

Other

No response

[jelbourn]

Hey there, TL for Angular here- I just want to add our support behind this proposal. Cross-platform support for trusted types would be a meaningful improvement not just for Angular, but all web frameworks. Angular currently implements its own userspace safe value system (in addition to trusted type support) to help guard against XSS attacks. Native support here would let us drop all of this code.

Other web frameworks typically don't implement these types of safeguards, relying on developers to independently know how to protect themselves from XSS whenever there's a need to render rich html content or dynamically load risky resources. Native support here takes a big step towards a safer web.

[annevk]

This is a proposal that's never gotten multi-implementer interest. Using Interop to change that seems inappropriate.

[gregwhitworth]

Salesforce strongly supports the Trusted Types proposal, considering the imminent regulatory changes in the Netherlands and the broader EU, as outlined in the eIDAS Regulation.

The U/PW.03 Standard of DigiD assessment demands the removal of 'unsafe-eval' from CSP, a challenge that will be mirrored across Europe. This presents critical compliance and potential reputation risks for our customers, especially in the public sector and healthcare.

Trusted Types have shown efficacy in XSS risk reduction, demonstrated by Google's successful adoption. This underlines the standard's relevance and potential impact.

Addressing a concern raised in the thread, we believe that the urgency of these regulatory requirements justifies the discussion of Trusted Types in the Interop 2024 context. A collaborative approach to standardization and implementation of Trusted Types is vital for web security and compliance, underscoring its pertinence in such forums.

[dandclark]

Thank you for proposing Trusted Types for inclusion in Interop 2024.

We wanted to let you know that this proposal was not selected to be part of Interop this year.

This is because we got many more proposals than we could include in this year's project. Note that individual vendors may nevertheless choose to advance work in this area during the forthcoming year. We would welcome this proposal being resubmitted again next year if necessary.

For an overview of our process, see proposal selection. Thank you again for contributing to Interop 2024!

Posted on behalf of the Interop team.