Consider support module identifiers as a whitelist

[koto]

Is is possible to optionally make the module map a whitelist of module identifiers that can be imported? For most applications it should be possible to generate the modules that the application uses at deployment time, allowing the module map to serve like a next-generation CSP script-src directive, but tailored to modules. That seems like a useful property.

[domenic]

I think that's out of scope for this proposal, and instead makes more sense as part of CSP's script-src. Safelisting really should be done at the URL level, not at this one-level-removed abstraction.

[koto]

I see the point; that said, URL whitelists are not as useful as commonly perceived and other CSP mechanisms (nonces, hashes) cannot be effectively used to guard module code - there's no mechanism to pass a hash or a nonce. As such, module loading might end up becoming a new XSS vector that existing security mechanisms have no effective way of coping with.

The module maps initially look like a good layer to apply an elegant solution to those concerns. @arturjanc

[guybedford]

Dynamic import is clearly a security vulnerability, and import maps are the way to control its resolution so this argument definitely makes a lot of sense.

For example, if every scope of the import map was restricted to only be allowed to load relative URLs from within its own scope, and every other URL had to be explicitly determined in the import map we would get some amazing security properties.

But our entire development of the web is based on the concept of security as an afterthought, and the processes are certainly not in place to change that here, so this certainly won't be viable.

[domenic]

@koto I don't really understand your response.

• If URL whitelists are not useful, why would module specifier whitelists be good, when module specifiers map directly to URLs?
• The fact that there's no way to pash a hash or nonce for module imports is a separate discussion, not related to this issue, or indeed to the import maps proposal.

[koto]

• If URL whitelists are not useful, why would module specifier whitelists be good, when module specifiers map directly to URLs?

Because I think they offer a more interesting (from a security perspective) abstraction for the modern applications - instead of a flat list of URLs, a tree that describes the application dependencies, together with a way of limiting certain capabilities to certain modules. It seems useful to treat it as some sort of application manifest, and then enforcing that the application at runtime adheres to it provides security benefits. In the current form of the proposal, this seems like quite close to be able to achieve this. Simply (if the application opts-in) deny loading modules that are not on the import map.

• The fact that there's no way to pash a hash or nonce for module imports is a separate discussion, not related to this issue, or indeed to the import maps proposal.

Yes, I agree, sorry for conflating those two. Nonces are, in general, not the way to go anyway for modules, but it feels like hashes might (though, understandably, URL => hash map can also just be specified elsewhere; this just seems like a nice place for it as well).

[domenic]

This proposal doesn't have any dependency structure, so I am still unclear on why specifiers are different from URLs. It would be good to provide an example of something that can only be done with specifiers, and not done with URLs.

[koto]

It's not about what (security metadata) can't be specified for URLs in principle, it's more that for now the platform has no way of specifying that for modules - and that import maps look like a good candidate, since they already specify the URLs in a declarative format.

To give an example - there is no way to provide SRI integrity digest value for imported modules. They used an integrity attribute for standard <script>s, but for module imports there's no such mechanism.

So I guess the argument is that I think import maps are sufficiently close to what the platform needs not to regress on security features for import modules. There's nothing wrong with import maps as-is. I'm just suggesting that it might be worth adding these small features, as otherwise we either regress or have to built another mechanism only for security.

[domenic]

OK. I suggest instead you use a manifest format that works for all URLs and resources, not just modules that need a specifier alias.