standards-positions
standards-positions copied to clipboard
WebKit
Trusted Types
WebKittens
@annevk @hober @marcoscaceres
Title of the spec
Trusted Types
URL to the spec
https://www.w3.org/TR/trusted-types/
URL to the spec's repository
https://github.com/w3c/trusted-types/tree/main/spec
TAG Design Review URL
https://github.com/w3ctag/design-reviews/issues/198
Mozilla standards-positions issue URL
https://github.com/mozilla/standards-positions/issues/20
WebKit Bugzilla URL
No response
Radar URL
No response
Description
Trusted Types is an optional browser mechanism for web sites to help protect themselves against cross-site scripting (XSS) attacks. It limits the attack surface from potentially the entire code base to a handful of "policies" that a developer can implement and install, and the browser will then enforce. Trusted Types can help to ensure that risky parts of the DOM can only be used by data that has gone through such a developer-supplied policy.
Sharing some data points that might be useful to consider while evaluating the position:
-
XSS is still prevalent in Web Applications:
-
#1vulnerability in HackerOne 2021 industry report -
#1vulnerability in Bugcrowd 2021 Report -
#2vulnerability in 2022 CWE Top 25 list -
#3vulnerability in Injection category in 2021 OWASP report (note that the category contains other vulnerability types), -
#3vulnerability in CVE charts in 2022
-
-
Adoption across the Internet:
- Meta, Microsoft and Google indicated in W3C WebAppSec forum that they have successfully deployed Trusted Types in number of their applications and that they recommend its usage across Web Applications,
- https://mitigation.supply/ - Trusted Types enforcement in 14% of Chromes's page loads (from 10% in March 2022). Strict CSP enforcement at 25%.
- HTTPArchive crawls (credentialless scans) show enforcing CSP with Trusted Types served on >200 non-Google-related domains in March 2023. >160 domains serve report-only CSP. Some of those are served on login pages (e.g. auth.heroku.com, app.knudge.com, login.erply.com), suggesting integration in underlying web applications.
-
Existing Browser Support
- Browser Support Tracker: https://caniuse.com/trusted-types
- Chrome: supported since version 83 released in May 2020
- Edge: supported since version 83 released in May 2020
- Opera: supported since version 69 released in June 2020
- Firefox: not supported; position: not harmful (previous discussion)
Supporting Trusted Types in Safari would match the level of protection in other browsers and would add additional defense against XSS.
The title of the label clarifies that from: is not about who is asking the WebKit community, but rather who the proposal is from. So this is accurate.
I guess this was the position in 2020 at least ... Did @othermaciej's concerns/comments get worked out?
I posted this on Interop 2024 as well but posting across the position issues as well just in case it gets lost:
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.
I did not immediately understand the relation, but https://github.com/w3c/trusted-types/issues/143 clarifies it a bit. Given TrustedScript.fromLiteral() from https://w3c.github.io/trusted-types/dist/spec/#trusted-script it appears as if Trusted Types would allow you to bypass the spirit of that assessment. As in, instead of eval('something()') you'd write eval(TrustedScript.fromLiteral(`something()`)) and it would not be considered "unsafe". I hope I'm misunderstanding something. Could you clarify perhaps?
Especially the existence of https://w3c.github.io/trusted-types/dist/spec/#default-policy-hdr suggests that when regulation is not aware of Trusted Types existing, Trusted Types, such regulation, and budget/deadlines might encourage application developers to do rather dangerous things.
I can't speak for the spirit of the regulatory assessment, but a crucial difference between eval and TrustedScript.fromLiteral case is that the latter cannot be a DOM XSS, since the value passed to fromLiteral has to literally be present in a code, with no interpolation allowed.
If the spirit aims to reduce the risk of XSS, and user-controlled data passed to eval is recognized as a significant part of the problem, fromLiteral addresses that completely. The letter of the regulation, however, seems to be mostly concerned about the presence of unsafe keywords in CSP, which TT actually doesn't change. In other words, eval(TrustedScript.fromLiteral(`something`) still throws if a document has a script-src CSP without unsafe-eval. TT don't relax existing CSP restrictions, only add to them.
@annevk in general, we need a mechanism for controlled evaluation, to reduce the risk of XSS, and that is the spirit of this new regulation. To that intent, TrustedTypes seems to be the leading candidate to pave the way, and in a sense, provide a mechanism to support legacy systems that were designed prior to the CSP era.
I think @koto is on point with respect to TrustedScript.fromLiteral, that should not be an issue for us at salesforce, although I don't think fromLiteral was ever implemented (I suspect due to its complexity). Neither it is the default token, we managed to add abstractions everywhere we do a control evaluation in our codebase, we didn't manage to remove the evaluation though.
@koto with respect to unsafe-eval presence, I hope that we can find a solution that blocks eval in non-TT compatible browsers (even if that means degraded service), while allowing controlled evaluation in newer browsers with TT enabled. That is the ask, and to that extend, introducing a new csp rule that is somewhat redundant to unsafe-eval seems fine to me.
I'm very confused by the feedback from @gregwhitworth and @caridy. As @koto pointed out TT can't weaken CSP.
@gregwhitworth @caridy is your hope that CSP is modified to have a non-unsafe-eval rule that nonetheless allows eval() when TT is used because something in TT makes that okay? And that this would satisfy the DigiD regulation? That seems like a lot of hypotheticals? Or are there concrete proposals here to evaluate?
Apart from that, it also seems concerning that the current draft reportedly lacks features Chromium has implemented (per https://github.com/mozilla/standards-positions/issues/20#issuecomment-1853427823) and apparently also has features that are not being implemented? Such as fromLiteral?
On the flip-side the arguments presented in https://github.com/mozilla/standards-positions/issues/20#issuecomment-1783279722 are compelling and do make it seem like Trusted Types could be a valuable addition to the web platform.
@annevk
As @koto pointed out TT can't weaken CSP.
I'm also getting confused. TT is part of CSP headers today. I also understand that implementers see them as two different/separate pieces, but for a developer, you're effectively making changes to one header. The question is what changes a developer has to make to the header to support controlled evaluation to prevent XSS, it is not about what technology does the job under the hood. Additionally, and historically, implementers have found ways to support "legacy" browsers that only support a subset of the CSP headers supported by newer browsers, and that is great and desirable. This time around, there is another factor, regulators enforcing that a very particular CSP header (unsafe-eval) not to be present. We are going to be at odds with the regulators, and how are we going to overcome this? Either regulators change their position (very unlikely but possible), or we find ways to introduce CSP header changes that allows us to do control evaluation using TT while not having unsafe-eval present in the header. And as always, take that with a grain of salt because I'm just in the middle of the crossed fire here trying to figure how to articulate where we are today.
Apart from that, it also seems concerning that the current draft reportedly lacks features Chromium has implemented (per https://github.com/mozilla/standards-positions/issues/20#issuecomment-1853427823) and apparently also has features that are not being implemented? Such as fromLiteral?
We are working with igalia to try to identify those, opening issues for each individual case, and try to come to agreements to move forward (e.g.: https://github.com/w3c/trusted-types/issues/398). cc @lukewarlow
Apart from that, it also seems concerning that the current draft reportedly lacks features Chromium has implemented (per https://github.com/mozilla/standards-positions/issues/20#issuecomment-1853427823) and apparently also has features that are not being implemented? Such as fromLiteral?
To provide more context to this, I'm not aware of anything Chrome has shipped to stable that isn't in the spec. They additionally have implemented some features behind experimental flags, some such as fromLiteral are in the spec atm (though see https://github.com/w3c/trusted-types/issues/398 for discussion on deferring that to level 2), others such as the beforecreatepolicy event aren't specced (see https://github.com/w3c/trusted-types/issues/270 for the discussion about it, this too will be deferred to v2 but I've requested a spec PR based on Chrome's implementation to evaluate).
We at Igalia are committed to bringing the specification up to scratch, I've already opened a number of issues to try and get answers to unanswered questions.
Wrt to the CSP integration I can see value in a potential trusted-eval (name tbd) expression to replace unsafe-eval. This new value along with the existing trusted types directives could create a situation where trusted types are enforced on eval (etc) and in unsupporting browsers you don't have access to eval at all (as opposed to unsafe where you would fallback to lower security). This would seem to address the regulatory requirements while also providing actual value in the form of additional security guarantees.
Of course this doesn't stop code running in browsers without CSP or with it disabled but that would seem out of scope for this.
Regardless that discussion is best had in the relevant standards bodies just thought I'd try and provide a bit of additional context.
Just throwing it out there. I know this has compat consequences, but given the real and perceived complexity in CSP, I could also envision that Trusted Types detangles its controls from CSP completely.
Wrt to the CSP integration I can see value in a potential
trusted-eval(name tbd) expression to replaceunsafe-eval. This new value along with the existing trusted types directives could create a situation where trusted types are enforced on eval (etc) and in unsupporting browsers you don't have access to eval at all
@lukewarlow With "don't have access", do you mean eval becomes a no-op, or something else?
(as opposed to unsafe where you would fallback to lower security). This would seem to address the regulatory requirements while also providing actual value in the form of additional security guarantees.
Of course this doesn't stop code running in browsers without CSP or with it disabled but that would seem out of scope for this.
Regardless that discussion is best had in the relevant standards bodies just thought I'd try and provide a bit of additional context.
It would behave as if you have strict csp without unsafe-eval today. I believe there'd discussions surrounding the eval csp aspect elsewhere so I'll leave a comment there.
Though that aspect is rather adjacent to trusted types API in general so I don't want to get caught up on that aspect.
According to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#unsafe_eval_expressions it'd behave as a no-op.