-
Notifications
You must be signed in to change notification settings - Fork 169
Make webcomponents-loader.js
compatible with the Trusted Types API
#501
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…ted-types` option.
… writes a `<script>`. Not yet enforced.
Local WCT tests passed as expected, since no trusted types policy is being enforced yet: |
Hmm, I was expecting the last commit to start enforcing trusted types and cause the test to fail, but they passed: |
That test is now failing with a timeout, as expected: |
… the header without spaces in between.
After adding the new policy, the tests pass again: |
…a command line option.
…` policy isn't allowed.
… isn't available.
b867622
to
3e59faf
Compare
…er is enforcing trusted types.
3e59faf
to
2489843
Compare
var trustedTypesAreEnforced = (() => { | ||
try { | ||
document.createElement('input').setAttribute('oninput', ''); | ||
} catch (e) { | ||
return true; | ||
} | ||
return false; | ||
})(); | ||
|
||
if ( | ||
window.trustedTypes && | ||
trustedTypesAreEnforced && | ||
!window.trustedTypes.isScriptURL(window.WebComponents.root) | ||
) { | ||
throw new Error('`WebComponents.root` must be a `TrustedScriptURL`.'); | ||
} | ||
url = trustedTypesPolicyWrapper.createScriptURL( | ||
window.WebComponents.root + polyfillFile | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@koto, I'm curious what you think about this w.r.t. w3c/trusted-types#36. The issue here is that WebComponents.root
is arbitrary input used to build a string that I'm stamping here as a TrustedScriptURL
, so I'd like to enforce that it is also a TrustedScriptURL
. However, if I don't check for and enforce only at the same time as the browser, then this error would be thrown even if the browser is only reporting trusted type violations. Is there a better way to propagate enforcement like this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We think it's an antipattern to change the behavior only if require-trusted-types-for
(or any CSP directive, for that matter) is enforced. The issue with that is that report-only can't be safely used to iron out all the violations, and authors risk breaking production apps the moment enforcing CSP replaces the reporting one.
The safe (but breaking) route out of this is, I think, to introduce WebComponents.rootAsTrustedScriptURL
(naming TBD) and use only that when window.trustedTypes
is available.
The less-safe (but b/w compatible) is to continue using .root
, and just documenting that the value should not be user controlled. To my understanding the loader is only used for polyfills anyway, and these would only be loaded for older browsers, which could only get TT via a polyfill, so the practical risk is minimal here.
I would personally just go for the second option, given the constraints.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, yeah, the second option sounds best in this case since I don't think we'd want to make a breaking change to the loader at this point. Thanks for your input!
…nts.root` and the relevant tests.
…ted as a dangerous URL sink.
d0c4291
to
1eda9d0
Compare
packages/webcomponentsjs/README.md
Outdated
bundle it selects based on feature detection. You should also treat | ||
`WebComponents.root` as if it were required to be set to a `TrustedScriptURL` | ||
when trusted types are being enforced. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bundle it selects based on feature detection. You should also treat | |
`WebComponents.root` as if it were required to be set to a `TrustedScriptURL` | |
when trusted types are being enforced. | |
bundle it selects based on feature detection. If you set `WebComponents.root` | |
(which is rare), it should be set to a TrustedScriptURL for Trusted Types | |
compatibility. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll work on the language more here. I don't think we can actually enforce that this is a TrustedScriptURL
without making a breaking change, but I think I could word this so that the idea that it should only be set to values that would be considered as safe as a TrustedScriptURL
was more clear. I.e. we can't actually enforce the safety ourselves, so users should know that it needs to be treated this way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've updated this slightly, PTAL
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WDYT of this suggestion now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, this is better - updated.
… if `WebComponents.root` is one also.
…d types are enforced. Co-authored-by: Peter Burns <[email protected]>
This is passing locally and in internal test runs so I'm going to merge despite the test infra problems. |
Fixes https://github.com/Polymer/internal/issues/1272