Handle non-DOM APIs of loading scripts comprehensively.
koto opened this issue · 2 comments
koto commented
Right now it's posisble to load scripts by specifying a string (either by passing a module identifier, or a URL), e.g. via
- static import (ES modules)
- dynamic
import()(#117) - workers (
newWorker()) importScripts- worklets
We have to figure out if and how to cover them with Trusted Types.
koto commented
- 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.
importScriptsand Worker construction is something we'd like to tackle separately in a later release.
koto commented
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"?