Improve docs for new CORS changes in 5.2.1

[Banner-Keith]

Documentation Is:

• Missing
• Needed
• Confusing
• Not Sure?

With the change made in the latest version of webpack dev server, there are some CORS changes that need to be made. My first clue something was changed was 403 errors being thrown.

It would be nice to have Access-Control-Allow-Origin documented in the webpack-dev server page on the webpack site and in the readme like the release notes have.

In addition, I found that I needed to add a crossorigin attribute to my script and link tags for the requests to succeed. So that may be good to include as well.

[alexander-akait]

In addition, I found that I needed to add a crossorigin attribute to my script and link tags for the requests to succeed. So that may be good to include as well.

In basic usage you don't need it and everything will work fine, can you provide your using (maybe reproducible test repo)?

We already have docs about how to use headers, we can't provide all CORS guidelines in our docs, because this topic is quite broad and there are quite a lot of resources on how to set it up

[Banner-Keith]

I will have to see if I can create a test repo for this. The big one is we are using HtmlWebpackPlugin and HtmlWebpackInjectAttributesPlugin to inject dynamic script and link tags into the HTML. The auto-generated tags will not have the crossorigin attribute by default. So I would assume that anyone using the latest dev server and also using HtmlWebpackPlugin might also experience this issue.

If this isn't something you see being a common issue this ticket can be closed. At least it is searchable here if anyone decides to search issues here and this is useful to them.

[kristof-spaas-hs]

We are experiencing the same issue, our script are also dynamically injected without the crossorigin attribute by default which causes a 403 being thrown.
Should it not be possible to still make use of a Access-Control-Allow-Origin header?
The newly added middleware does not seem to take the header into account.

[xiaoYown]

'Access-Control-Allow-Origin': '*'

Not effective, I have to downgrade.

[alexander-akait]

@Banner-Keith Please create reproducible test repo, you should not inject crossorigin in normal usage

@kristof-spaas-hs If you need help please avoid messages like the same, create re reproducible test repo and I will help

@xiaoYown It means you have problems with your env, because Access-Control-Allow-Origin should work

[MattiasJa]

We resolved the 403 issue for chunks loading by setting below :

output: {
crossOriginLoading: 'anonymous',
},

[fish-face]

We have also run into an issue with all our bundles being inaccessible over the dev server as of this release. We have 'Access-Control-Allow-Origin': '*', and this is returned if I manually curl -i URLs which are being blocked by the browser.

Other workarounds mentioned here do not work for us; neither adding crossorigin to resource tags nor crossOriginLoading: 'anonymous' to module.exports.output.

Our situation is using webpack_loader with Django.

I have limited knowledge of CORS details, but it seems to me that the change is in fact wrong. Isn't Sec-Fetch-Mode: no-cors specifically supposed to permit cross origin GET requests such as fetching stylesheets, which this change makes no allowance for?

In any case I would like to suggest that this change be reverted for the time being. We are talking about a dev server; a cross-site origin issue should not cause problems, right? Is there a compelling reason to make this a breaking change in a patch release?? Loads of downstream projects caught this breaking change automatically because there was no major version bump indicating backwards-incompatibility. If it turns out that this change is correct, contrary to what I said above, you can always cut a major release?

[riconnon]

I'm also very confused by this change and very frustrated by the breakage.
I'm working on a project with allowedHosts set to "all" and Access-Control-Allow-Origin header set to "*" and the dev server is not blocking requests, so clearly the change is not working as intended.

Unless I'm very much mistaken it's not normal to block requests on the server side for Cross-Origin protection since Cross-Origin resource loading protections are for the client and implemented by the client.

Especially since this is a DEV server it is definitely an incredibly odd decision to make a breaking change in a bugfix release that resolves a, questionable at best, "security issue".

Was any threat modelling done to determine the severity of this "bug" before the fix was merged and released as a bugfix? If it is considered a security bug is there a CVE assigned?

[martijnpieters]

Besides downgrading to version 5.2.0, you could also consider disabling the newly added cross-origin-header-check middleware in version 5.2.1.

That could be done by setting the devServer.setupMiddlewares value in the webpack config to something like:

setupMiddlewares: (middlewares) => {
  return middlewares.filter(middleware => middleware.name !== "cross-origin-header-check");
}

As mentioned later: use it at your own risk, If you are working in a secure environment you have nothing to worry about, but if not you may end up with a vulnerability.

[riconnon]

@martijnpieters that's very helpful, thanks, but it's a workaround at best...

I'd really like to understand how, with this feature in place, I am supposed to configure this to work given that allowedHosts: "all" and "Access-Control-Allow-Origin": "*", as implied by the changelog messages which is the only documentation of this new behaviour, is not sufficient.

[fish-face]

Other googling of this issue found people proxying all connections to their app through the webpack dev server so that nothing was cross-origin... Maybe it is simply not anticipated that cross-origin requests to the dev server happen? Doesn't align with the documentation of crossOriginLoading though.

But yes, hopefully a maintainer can enlighten us soon about the anticipated threat this is supposed to protect against and the intended behaviour, which will determine if this is a behaviour bug or missing docs.

[martijnpieters]

@martijnpieters that's very helpful, thanks, but it's a workaround at best...

I'd really like to understand how, with this feature in place, I am supposed to configure this to work given that allowedHosts: "all" and "Access-Control-Allow-Origin": "*", as implied by the changelog messages which is the only documentation of this new behaviour, is not sufficient.

@riconnon Yes, it's a workaround. But there's no other way to disable this (new) piece of code:

        if (
          headers["sec-fetch-mode"] === "no-cors" &&
          headers["sec-fetch-site"] === "cross-site"
        ) {
          res.statusCode = 403;
          res.end("Cross-Origin request blocked");
          return;
        }

So for version 5.2.1, settings like allowedHosts: "all" and "Access-Control-Allow-Origin": "*" will not change anything about the returned 403.

[Hypnosphi]

a cross-site origin issue should not cause problems

I can imagine some malicious website requesting resources from some commonly used ports on localhost and basically stealing your source code. So unless you're only working on open source projects that can be problematic

[riconnon]

a cross-site origin issue should not cause problems

I can imagine some malicious website requesting resources from some commonly used ports on localhost and basically stealing your source code. So unless you're only working on open source projects that can be problematic

The cross-origin protections in place in my browser will prevent that already. I'm not aware of a need for this to be implemented server-side.

[riconnon]

@martijnpieters that's very helpful, thanks, but it's a workaround at best...
I'd really like to understand how, with this feature in place, I am supposed to configure this to work given that allowedHosts: "all" and "Access-Control-Allow-Origin": "*", as implied by the changelog messages which is the only documentation of this new behaviour, is not sufficient.

@riconnon Yes, it's a workaround. But there's no other way to disable this (new) piece of code:

    if (
      headers["sec-fetch-mode"] === "no-cors" &&
      headers["sec-fetch-site"] === "cross-site"
    ) {
      res.statusCode = 403;
      res.end("Cross-Origin request blocked");
      return;
    }

So for version 5.2.1, settings like allowedHosts: "all" and "Access-Control-Allow-Origin": "*" will not change anything about the returned 403.

Very frustrating. The changelog says:

unless allowed by Access-Control-Allow-Origin header

and

unless configured by allowedHosts

so these two statements are very actively misleading if that doesn't actually work.