Import assertions and CSP

[guybedford]

@annevk brought up an important discussion in whatwg/html#7233. Currently CSS and JSON modules are falling under the script-src CSP policy by virtue of their integration into the module system.

CSP requires an upfront indicator of the policy in play in order to perform its security checks.

Import assertions might be a way to inform the CSP policy type for a given resource.

Is this a direction this specification would want to take a position on or does the existing spec allow and or encourage such directions for HTML?

[guybedford]

It sounds to me like the use as a CSP policy indicator may require a clarification to this specification point:

moduleRequest.[[Assertions]] must not influence the interpretation of the module or the module specifier

Where we explicitly note that it may influence other guarding security layer interpretations such as CSP, as long as they do not involve functional reinterpretations of the module.

[ljharb]

since CSP just rejects or allows, it seems like it would already be in keeping with the proposal.

[annevk]

Well, it would end up changing the interpretation of the module specifier. I.e., how it ends up mapping to a request. But maybe "must not influence" is vague enough.

[ljharb]

@annevk as long as the presence of the assertion either gives you "the same module" or "fails to load", i think it's fine - iow, "the interpretation of the module" only matters if it actually loads.

I'm assuming that a failing CSP check would fail the module graph, as opposed to loading a different module?

[annevk]

Sure, but I still think that statement could use some clarification (or reduction in scope).

[nicolo-ribaudo]

The invariant has been relaxed to permit what HTML needs. Thanks everyone for taking part in the discussion!

I'm closing this issue, as any discussion should now continue on the HTML side at whatwg/html#7233.