Dynamic import - for the web platform - is a DOM XSS execution sink (a'la eval). Unlike static import, its value cannot be determined statically, and the websites have no effective way of guarding what module specifiers are allowed.
The only existing solution is based on guarding the target script URL post-resolution via Content Security Policy script-src whitelists, but that variant of CSP is known to be ineffective. Dynamic imports (and imports in general) are incompatible with the nonce-based or hash-based approach. While that has a limited impact for static imports (as the module specifiers are discoverable during code compilation), it's much worse for dynamic imports (as module specifiers are more likely to be controlllable by the attacker via regular DOM XSS methods).
Given that the web platform is ridden with DOM XSS, I believe introduction of dynamic imports in this shape only soldifies that (as the existing security mechanisms are not fitting).
A single change might make dynamic import better in this regard:
Pass non-string module specifiers for dynamic imports to host environments. E.g. pass specifier instead of specifierString in step 7 of Runtime Semantics: Evaluation. That allows the host to perform additional validation in HostImportModuleDynamically - for example, a Trusted Type might be required, or the module identifier might carry other additional data that augment making a security decision before calling FinishDynamicImport (with a stringified specifier). Without this the hosts are unable to implement a security mechanism that guards the producion of dynamic module specifiers. Instead only a (non-existing) whitelist-based approach for the module identifiers may be used in the future (e.g. in HostResolveImportedModule) , which seems very limiting, especially given that we know already whitelists are not sufficient in the web platform.
Dynamic import - for the web platform - is a DOM XSS execution sink (a'la eval). Unlike static import, its value cannot be determined statically, and the websites have no effective way of guarding what module specifiers are allowed.
The only existing solution is based on guarding the target script URL post-resolution via Content Security Policy
script-srcwhitelists, but that variant of CSP is known to be ineffective. Dynamic imports (and imports in general) are incompatible with the nonce-based or hash-based approach. While that has a limited impact for static imports (as the module specifiers are discoverable during code compilation), it's much worse for dynamic imports (as module specifiers are more likely to be controlllable by the attacker via regular DOM XSS methods).Given that the web platform is ridden with DOM XSS, I believe introduction of dynamic imports in this shape only soldifies that (as the existing security mechanisms are not fitting).
A single change might make dynamic import better in this regard:
Pass non-string module specifiers for dynamic imports to host environments. E.g. pass
specifierinstead ofspecifierStringin step 7 of Runtime Semantics: Evaluation. That allows the host to perform additional validation in HostImportModuleDynamically - for example, a Trusted Type might be required, or the module identifier might carry other additional data that augment making a security decision before calling FinishDynamicImport (with a stringified specifier). Without this the hosts are unable to implement a security mechanism that guards the producion of dynamic module specifiers. Instead only a (non-existing) whitelist-based approach for the module identifiers may be used in the future (e.g. in HostResolveImportedModule) , which seems very limiting, especially given that we know already whitelists are not sufficient in the web platform.