CSP & cross-origin module blocks

[jakearchibald]

From the README:

as they are parsed in syntax with the surrounding JavaScript code, they cannot be a vector for injection attacks

postMessage across windows allow communication between origins, and presumably this means modules can be passed between origins. Does the CSP story still hold true?

OriginA could forbid eval and forbid execution of scripts from OriginB, but OriginA could receive a module from OriginB via window.onmessage and instantiate it, bypassing both of those CSP rules.

[surma]

I am not sure CSP is relevant here, but cross-origin likely is.

I’d equate it to doing import("https://other-domain.com/my-module.mjs"), which you can’t do without the right CORS headers. As a result import(moduleBlockFromOtherDomain) probably shouldn’t succeed either unless CORS headers are set. So this might have to trigger a preflight request (but I am not good with CORS, tho, so I am hoping to work this out with some experts during the HTML integration).

[jakearchibald]

I don't think CORS is relevant here. OriginB already allowed OriginA visibility into the module by calling originAWindow.postMessage(message, originA).

The problem isn't that OriginB's security was bypassed, it's that OriginA's CSP was bypassed.

[littledan]

Yeah, this does seem like something of a leak risk. I think it should be pretty straightforward for module blocks' HTML integration to keep track of the origin where they were defined, so that such CSP rules can check it when the module is imported.

[jakearchibald]

I think it should be pretty straightforward for module blocks' HTML integration to keep track of the origin where they were defined

It seems like that information will already be there to make import.meta.url work.

[littledan]

Yeah there will be various kinds of things to do in HTML integration. Also they need to be keys in the module map. @surma and I plan to get started on this all tomorrow.