You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We propose Trusted Types - an API that allows applications to lock down DOM XSS 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 writing values to the DOM, and reducing the DOM XSS attack surface to small, isolated parts of the web application codebase, which are substantially easier to safeguard, monitor and review.
The creation of policies is controlled by a new Content Security Policy directive - trusted-types. The API uses existing CSP mechanisms to report violations, control enforcement and support report-only mode.
Motivation and Use Cases
We believe it's too easy to introduce, and too difficult to detect DOM-Based Cross-Site-Scripting (DOM XSS). As a consequence, XSS remains to be one of the most prevalent vulnerability types in web applications.
Web developers are exposed to an insecure by default API that has to be carefully used not to pass user-controlled data to one of the many injection sinks - and mistakes happen. Instead, we propose a secure by default mode for the injection sinks, that requires the developers to process the data before it is passed to those sinks. With the introduction of policies developers - or their security teams - can specify the programmatic security rules for their applications, and lock down the application via Content Security Policy, significantly reducing the DOM XSS attack surface.
Trusted Types are designed in a way to allow gradual migration, have a fallback mechanism, and -- thanks to using a type system -- allow the security rules to be surfaced to the developers when they are writing the code.
The exemplary use cases are outlined in the spec draft.
Compatibility Risk
The API is extensible - we can always introduce further types (e.g. there's an interest from Chromium to add new types to cover browser extension APIs), and there is a way of querying the currently enabled enforcements from JS, so authors can detect which types are required in which injection sinks.
Since the existing applications have to work in non-Trusted-Types-supporting browsers, removing the API for them doesn't break them - the risk is present when/if the code unconditionally assumes the environment supports Trusted Types. The API supports feature detection (e.g. via 'trustedTypes' in window) and the recommended way is to default to string-based injection sinks it Trusted Types are not available, so the actual risk of breakage upon deprecation is minimal and could potentially be mitigated by a polyfill of the API.
Ongoing technical constraints
We want to add the features to the browsers, for all environments as this helps with code portability.
Chrome implementation is tracked in this component, so we expect similar issues will be encountered by other browser vendors implementing it. Essentially the implementation requires to define a JS API, create TT objects and conditionally require them at sinks. There is also a new CSP directive to control the behavior of the API.
This may affect a lot of users of a web. We expect the early adopers of the API to be large web applications written using modern frameworks. E.g. most Google applications use a concept like Trusted Types, but enforced by the JS compiler. Modern JavaScript frameworks try to steer away developers from risky sinks - see dangerouslySetInnerHTML in React, or sanitize the data put there. The existing DOM API surface already enables XSS bugs - the number 1 web bug, which seems to be confirmed by analyzing e.g. findings from bug bounties - see here for a collection of results. 70% of payouts from Google Vulnerability Rewards program are a result of reporting an XSS bug (most of which are DOM XSS).
Adoption at Google so far has already surfaced a few ways developers unknowingly abused our security controls to interact with the DOM API directly and creating a potential DOM XSS bug. We expect this - surfacing risky patterns - to happen more as the adoption grows.
Security and Privacy
We hope to make applications practically secure from DOM XSS, by asserting that the security rules are centralized for application, and integrating with the existing JS frameworks that deal with templating or perform dynamic script loading. Essentially we're trying to push developers to interacting with risky injection sinks rarely, if at all - and use the reviewed, secure libraries for the rare cases that need to use those sinks. Existing Security considerations are listed inline in the spec draft text.
Accessibility
No implications
Internationalization
No implications
The text was updated successfully, but these errors were encountered:
Working group decision to adopt
https://lists.w3.org/Archives/Public/public-webappsec/2019Sep/0003.html
Proposal
Specification draft is at https://wicg.github.io/trusted-types/dist/spec/index.html
Summary
We propose Trusted Types - an API that allows applications to lock down DOM XSS 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 writing values to the DOM, and reducing the DOM XSS attack surface to small, isolated parts of the web application codebase, which are substantially easier to safeguard, monitor and review.
The creation of policies is controlled by a new Content Security Policy directive -
trusted-types. The API uses existing CSP mechanisms to report violations, control enforcement and support report-only mode.Motivation and Use Cases
We believe it's too easy to introduce, and too difficult to detect DOM-Based Cross-Site-Scripting (DOM XSS). As a consequence, XSS remains to be one of the most prevalent vulnerability types in web applications.
Web developers are exposed to an insecure by default API that has to be carefully used not to pass user-controlled data to one of the many injection sinks - and mistakes happen. Instead, we propose a secure by default mode for the injection sinks, that requires the developers to process the data before it is passed to those sinks. With the introduction of policies developers - or their security teams - can specify the programmatic security rules for their applications, and lock down the application via Content Security Policy, significantly reducing the DOM XSS attack surface.
Trusted Types are designed in a way to allow gradual migration, have a fallback mechanism, and -- thanks to using a type system -- allow the security rules to be surfaced to the developers when they are writing the code.
The exemplary use cases are outlined in the spec draft.
Compatibility Risk
The API is extensible - we can always introduce further types (e.g. there's an interest from Chromium to add new types to cover browser extension APIs), and there is a way of querying the currently enabled enforcements from JS, so authors can detect which types are required in which injection sinks.
Since the existing applications have to work in non-Trusted-Types-supporting browsers, removing the API for them doesn't break them - the risk is present when/if the code unconditionally assumes the environment supports Trusted Types. The API supports feature detection (e.g. via
'trustedTypes' in window) and the recommended way is to default to string-based injection sinks it Trusted Types are not available, so the actual risk of breakage upon deprecation is minimal and could potentially be mitigated by a polyfill of the API.Ongoing technical constraints
We want to add the features to the browsers, for all environments as this helps with code portability.
Chrome implementation is tracked in this component, so we expect similar issues will be encountered by other browser vendors implementing it. Essentially the implementation requires to define a JS API, create TT objects and conditionally require them at sinks. There is also a new CSP directive to control the behavior of the API.
Link to implementation experience and demos
Integrations | Resources
Data
This may affect a lot of users of a web. We expect the early adopers of the API to be large web applications written using modern frameworks. E.g. most Google applications use a concept like Trusted Types, but enforced by the JS compiler. Modern JavaScript frameworks try to steer away developers from risky sinks - see dangerouslySetInnerHTML in React, or sanitize the data put there. The existing DOM API surface already enables XSS bugs - the number 1 web bug, which seems to be confirmed by analyzing e.g. findings from bug bounties - see here for a collection of results. 70% of payouts from Google Vulnerability Rewards program are a result of reporting an XSS bug (most of which are DOM XSS).
Adoption at Google so far has already surfaced a few ways developers unknowingly abused our security controls to interact with the DOM API directly and creating a potential DOM XSS bug. We expect this - surfacing risky patterns - to happen more as the adoption grows.
Security and Privacy
We hope to make applications practically secure from DOM XSS, by asserting that the security rules are centralized for application, and integrating with the existing JS frameworks that deal with templating or perform dynamic script loading. Essentially we're trying to push developers to interacting with risky injection sinks rarely, if at all - and use the reviewed, secure libraries for the rare cases that need to use those sinks. Existing Security considerations are listed inline in the spec draft text.
Accessibility
No implications
Internationalization
No implications
The text was updated successfully, but these errors were encountered: