trusted-types
trusted-types copied to clipboard
w3c
Figure out if we need `'trusted-script'` in `script-src`
trusted-script keyword is used now for javascript: navigations and eval guarding. Since we've integrated with CSP logic, perhaps the keyword is now superfluous?
If a website uses eval or javacsript: and it uses script-src, it needs to set appropriate unsafe-* keywords anyhow, for browsers with no trusted-types support.
We are close to having working downgrades. See #218 for a working downgrade-to-string for eval; for javascript: navigation, the default policy will simply not be created, and therefore called.
It seems like a combination of script-src ... 'unsafe-inline' 'unsafe-eval'; trusted-types ... correctly limits the unsafe behavior to Trusted Types, with a working downgrade to string for non-supporting browsers. IOW, trusted-types directive adds additional restrictions independent of script-src, which seems to be not violating CSP principles, and is conceptually simpler.
cc @mikesamuel @mikewest
/cc @mikewest , Do you have an opinion here? Essentially, it all boils down to whether trusted-types directive (and a JS code conforming to it) should be able to bypass existing restrictions in script-src, or would we require a new keyword in script-src as well.
I think you're right that script-src 'trusted-script' ...; trusted-types name is less backwards-compatible than script-src 'unsafe-eval' ...; trusted-types name. I think I'm comfortable treating trusted-types name as an attenuation of 'unsafe-eval' without a separate keyword.
I'm reopening this issue to restart this conversation. I think something that's been missed in previous considerations is that some use cases might care more about security than compatability.
think you're right that script-src 'trusted-script' ...; trusted-types name is less backwards-compatible than script-src 'unsafe-eval' ...; trusted-types name
This lack of backwards compatability is a desired characterstic. Currently to use eval in TT envs you have to add a keyword that means browsers without TT allow you full unmitigated eval. Which is not always desirable.
If we added a new trusted-script (or trusted-eval or some other name) keyword then that would allow you access to eval where supported and degrade to smaller feature set where it's not provided.
@lukewarlow thanks for reopening this. we certainly need this resolved to be able to move forward with the regulations in Europe.
cc @gregwhitworth
As part of https://github.com/w3c/trusted-types/pull/464 - we get the raw arguments to eval and new Function() so we can ensure they are trusted types which would make this easier
A worry I have here is that with Trusted Types the definition of trust lies with the website. And while I suppose a website could always bypass its own policies (e.g., to bypass unsafe-eval you could have a <script src> proxy of sorts I think) this seems easier with Trusted Types (have a no-op policy).
In particular because regulation around security policies might encourage perverse incentives.
@annevk I think the main incentive here is to prevent evaluation in browsers without TT, as this constitutes a security problem today with no way to mitigate it without introducing UA sniffing.
Closing this to focus discussions in https://github.com/w3c/webappsec-csp/pull/665