For the Mozilla implementation of <script type=module>, I have some concerns about the mandatory CORS requirement before we're ready to ship an implementation. I was hoping we could have a discussion here to see if we could get some clarity around the tradeoffs of this particular question.

As I see it, the risk of imposing a stricter CORS requirement for module scripts than for classic scripts is an adoption tax: it adds an extra burden for hosts serving modules to multiple origins. The obvious category is CDNs that aren't currently serving CORS headers, but there are also use cases like single-vendor apps with asset subdomains, and perhaps others we aren't thinking of.

While I'm sure some might think of that as a feature -- i.e., using modules to incentivize the adoption of CORS -- we have to contend with the multiplied adoption risks, and it's hard for me to really know how to evaluate that risk. (It'd be helpful to hear from multi-origin authors and hosts, BTW, to hear whether they think this kind of change is something they feel they can absorb, or whether mandatory CORS would cause them any roadblocks.)

Meanwhile, it's not clear to me what the precise rationale is. My assumption is that there's a security argument, but I'd like some clarity about what it is.

The first question is, is this attempting to migrate the web away from existing security issues, or is it attempting to prevent some new security issue? The former seems implausible to me; no matter how widespread the adoption of module scripts, you can't prevent malicious content from using classic scripts. IOW, closing any historical <script> gaps in the design of <script type=module> doesn't stop attackers from using <script>.

If the claim is that modules introduce some new issue, we should try to be clear about what that is. So far I haven't been able to puzzle out a threat model for which module scripts are meaningfully different from classic scripts:

• Malicious server side effects? Even with mandated CORS, the spec doesn't use preflighting, so even as written it doesn't prevent module scripts from triggering any of the same side effects that classic scripts can.
• Leaking sensitive information from the server to the client by reading fetched data? Non-CORS data is censored in the browser.
• Leaking sensitive information from the server to the client via script execution? Classic scripts have all the same execution powers as module scripts; modules add import but of course classic scripts can already XHR/fetch.
• Leaking sensitive server files in data formats (CSV, JSON, etc) by treating them as JS? The import/export syntax is the only difference from the JS grammar, and doesn't plausibly overlap with any data file formats.
• What else? I had a brief chat with @annevk, who mentioned something about leaking cross-origin referer information in transitive loads, but I don't understand the threat model (nor how it differs from, for example, cross-origin CSS with imports).

The primary benefit of requiring no-preflight CORS seems to be the additional power to read cross-origin data (script source, stack traces). But that's not enough to justify the removal of the power to execute cross-origin module scripts without CORS.

If there is a threat model that no-preflight CORS is supposed to protect against with module scripts, I'd like to understand what it is. Even just an example exploit would be helpful. If we can understand the rationale, we can evaluate the tradeoffs.

cc: @domenic, @annevk, @jonco3