2

I have this three files:

script.js

alert("script")

module.mjs

alert("module")

and index.html

<script src="./script.js"></script>
<script src="./module.mjs" type="module"></script>

No server is running.

If I open the browser and navigate to my local index.html file, I can see the scripts alert being displayed but the module is blocked by cross origin policy.

Both Chrome and Firefox show the same behavior but I'm accessing all the files from my local environment, so why they say that there is a cross origin policy violation in one case and not in the other?

A partial reason can be found here but in my case the script.js is loaded, why the cross origin policy is applied only on ES6 modules?

asdru
  • 1,147
  • 10
  • 19
  • Is it duplicate of https://stackoverflow.com/questions/52139811/javascript-module-not-working-in-browser/53743685 ? – xmedeko Oct 13 '21 at 09:18
  • Duplicate of https://stackoverflow.com/questions/52139811/javascript-module-not-working-in-browser/53743685 – xmedeko Oct 13 '21 at 09:20
  • It's not the same question, I'm asking why the HTML `script` tag have a different download behavior if the attribute ` type="module"` is present: scripts without such attribute skip the same origin policy. Why? is a kind of back compatibility choice or are the old js scripts safer than the new es6 ones (this would be quite strange)? – asdru Oct 13 '21 at 11:34
  • OK, then if would be good to change the title to something like "Why the cross origin policy is applied only on ES6 modules?" – xmedeko Oct 13 '21 at 12:34

1 Answers1

2

Support for cross-origin script loading for non-modules without CORS is a legacy feature for backwards compatibility.

From a discussion during the development of the spec:

The web's fundamental security model is the same origin policy. We have several legacy exceptions to that rule from before that security model was in place, with script tags being one of the most egregious and most dangerous. (See the various "JSONP" attacks.)

Many years ago, perhaps with the introduction of XHR or web fonts (I can't recall precisely), we drew a line in the sand, and said no new web platform features would break the same origin policy. The existing features need to be grandfathered in and subject to carefully-honed and oft-exploited exceptions, for the sake of not breaking the web, but we certainly can't add any more holes to our security policy.

That's why, from our perspective, making module scripts bypass the CORS protocol (and thus the same-origin policy) is a non-starter. It's not about a specific attack scenario, apart from the ones already enabled by classic scripts; it's about making sure that new features added to the platform don't also suffer from the past's bad security hygiene.

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335