Trusted Types
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 https://github.com/w3c/trusted-types/issues/347 or because they were created through author-created https://github.com/w3c/trusted-types/issues/347. 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.
Since 2023, Trusted Types is being upstreamed into HTML.
Interop 2026, 2025, and 2024 proposals: https://github.com/web-platform-tests/interop/issues/1138, https://github.com/web-platform-tests/interop/issues/800, https://github.com/web-platform-tests/interop/issues/500
cc: @otherdaniel
Discussion on GitHub (4)
Related: #1416
Are there specific parts of trusted types that lack interop? This is shipped in all 3 major engines now.
I think the general state of TT interop is pretty good indeed!
wpt.fyi identifies ~20-50 tests for each browser that they don't pass just yet. Ironing out the remaining issue seems like a good idea to me. On our end, being an Interop target would bring enough additional attention that we should be able to improve our passing rate further.
FWIW, the main thing which is failing in Firefox is trusted-types-from-literal.tentative.html , which is non-standard thing. I guess we should just remove that whole test. It is not enabled in any browser in their release versions.
But other than that, seems very reasonable to get the last few failures fixed in browsers.