Skip to content
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

Handle non-DOM APIs of loading scripts comprehensively. #232

Open
koto opened this issue Oct 31, 2019 · 2 comments
Open

Handle non-DOM APIs of loading scripts comprehensively. #232

koto opened this issue Oct 31, 2019 · 2 comments
Labels
future In consideration for the future releases of the API spec
Milestone

Comments

@koto
Copy link
Member

koto commented Oct 31, 2019

Right now it's posisble to load scripts by specifying a string (either by passing a module identifier, or a URL), e.g. via

We have to figure out if and how to cover them with Trusted Types.

@koto koto added spec future In consideration for the future releases of the API labels Mar 2, 2020
@koto
Copy link
Member Author

koto commented Mar 6, 2020

  • static ES Module imports are definitely out of scope - the reasoning is that anyone able to control your JS program body directly (able to control the module identifiers that are passed to static imports) has code execution capability. https://w3c.github.io/webappsec-trusted-types/dist/spec/#security-considerations
  • dynamic import work needs appropriate hooks in ECMAScript - this is tracked via https://github.com/tc39/dynamic-import-host-adjustment
  • worklets run in an isolated environment, they can't cause DOM XSS in a way script loading can. In future, we might be able to guard them via module specifiers, but it's not currently possible.
  • importScripts and Worker construction is something we'd like to tackle separately in a later release.

@koto
Copy link
Member Author

koto commented May 12, 2020

https://github.com/WICG/webpackage/blob/master/explainers/subresource-loading.md introduces yet another way of indirectly changing the scripts that end up being loaded, similar to base tag (yay!).

Perhaps we should have another type for these "indirect script URLs"?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
future In consideration for the future releases of the API spec
Projects
None yet
Development

No branches or pull requests

1 participant