Intent to Implement: Trusted Types for DOM Manipulation
mk...@chromium.org
(Ugh, sorry for the double-post. The other thread's title didn't include the magic words "Intent to Implement".)
Contact emails
mk...@chromium.org, ko...@google.com, sle...@google.com
Explainer
https://github.com/mikewest/trusted-types
Design doc/Spec
We don't have a spec. TAG review of the general direction requested at https://github.com/w3ctag/design-reviews/issues/198.
Summary
This feature is a little vague at the moment, but breaks into three pieces:
1. We'll introduce a set of types that correspond to various DOM APIs that convert strings to DOM / URLs / etc. These types will auto-escape the characters that would be interesting in a given context, or allow explicit unsafe creation of an unescaped string.
2. We'll enumerate the DOM sinks we're interested in protecting, and overload each with a variant that accepts a relevant type rather than a `DOMString`.
3. We'll give developers some mechanism to disable the `DOMString` variants to force themselves through the type system.
Motivation
DOM-based XSS attacks keep popping up on websites (and it's only becoming a more common vector as folks discover gadgets in popular libraries). Internally, Google has had a good deal of success at combating this kind of problem with compile-time enforcement of a set of safe HTML types that allow security reviewers to concentrate their time on the places that generate strings meant for the DOM, rather than auditing each DOM manipulation.
Our goal here is to determine whether there's something generic that we can extract from the various rule sets enforced internally.
Risks
Interoperability and Compatibility
The goal of this system is to allow developers to layer the new types on top of their existing code in a piecemeal fashion. We imagine existing libraries shifting their templating/sanitization systems to rest on top of these types when available, and on top of strings when they aren't.
Edge: No signals
Firefox: No signals (though we've had private conversations that show at least marginal interest in the general direction)
Safari: No signals
Web developers: Google makes extensive use of a type system internally, and wrote it up in https://research.google.com/pubs/pub42934.html.
Ergonomics
This feature will be used along with all the DOM manipulation APIs that accept strings and turn them into DOM. If we're successful at getting a type system in place, we'll need to keep it in mind when designing new DOM manipulation APIs that might accept strings.
Activation
As above, we're aiming for piecemeal adoption. That can certainly be facilitated with a polyfill that represents the same API to developers, but relies on stringification semantics rather than magical C++ underpinnings. koto@ has already built a tiny proof of concept as a polyfill in user-space. The Blink additions are only necessary for the bits and pieces his polyfill can't fill (e.g. `[Unforgeable]` objects like `location`).
Debuggability
The debugging story here should not be different than any other JavaScript API: we'll add some new interfaces, and we'll add some behavior to existing setters and methods that allow the potential execution of strings that are passed in. We'll have clear exception messages for the places that throw/reject, and that (hopefully!) will be enough.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Link to entry on the feature dashboard
https://www.chromestatus.com/features/5650088592408576Requesting approval to ship?
Ha! No.
-mike