CORS error on request to localhost dev server from remote site

Question

On Friday I had a working dev environment. On Monday I had a broken one. I encountered this error message in the Chrome dev-tools console for all my assets:

Access to CSS stylesheet at 'http://localhost:8080/build/app.css' from origin 'http://example.com' has been blocked by CORS policy: The request client is not a secure context and the resource is in more-private adress space local.

Is there any quick fix for this? I tried setting access-control-allow-origin in my webpack devServer.headers config to no avail:

config.devServer.headers = {
  'Access-Control-Allow-Origin': '*',
  'Access-Control-Allow-Headers': 'Origin, X-Requested-With, Content-Type, Accept'
}

Answer 1

As of April 2024

A new W3C draft proposes a new setting in the fetch options named targetAddressSpace.

It can be used to allow mixed-content requests from public to private address spaces, like this:

fetch("http://router.local/ping", {
    targetAddressSpace: "private",
});

Currently only supported since Chrome 124.

Reference:

• https://wicg.github.io/private-network-access/#permission-prompt
• https://developer.chrome.com/blog/pna-permission-prompt-ot
• https://caniuse.com/mdn-api_request_targetaddressspace

Answer 2

Temporary work around.

In Windows command prompt run the below command and restart the chrome.

reg add HKEY_CURRENT_USER\SOFTWARE\Policies\Google\Chrome /t REG_DWORD /v InsecurePrivateNetworkRequestsAllowed /d 1 /f

The above command will create the following entry in windows registry.

Reference:

https://developer.chrome.com/blog/private-network-access-update/

https://chromeenterprise.google/policies/#InsecurePrivateNetworkRequestsAllowed

Answer 3

December 2022 update

I think they renamed the flag ...

• Try chrome://flags/#allow-insecure-localhost
• Set to Enabled
• Restart Chrome

Answer 4

just a Chrome client way to ignore this warning and make assets accessable:

1: go to chrome://flags/#block-insecure-private-network-requests

2: set Block insecure private network requests to Disabled

Note: this just works fine when you're in your own computer or your dev environment

Answer 5

Access to CSS stylesheet at 'http://sub.domain.com/font/Sahel.css' from origin 'http://sub.domain.com' has been blocked by CORS policy: The request client is not a secure context and the resource is in more-private address space private.

I'm developing a web-base system for the company I work in, and we have set up the dns and domain to access the system locally while we are inside the company and access it through internet while we are not there. no https cer was installed ever.

Above quote shows up from time to time and refers to same domain as one in a private level and the other as a less private! and it will be fixed by Ctrl + F5. so ridiculous!

In my case, adding a dynamic version using ?v=time() at the end of ALL OF MY LOCAL LINKS fixed my problem, but it costs downloading all scripts, css, fonts everytime user load the page!

Answer 6

Just came across this subject, since I had the same problem with a webserver instance in our local network. This is not necessarily a complex problem. It may happen, e.g. if you include javascript libraries from public resources, such as vue.js or node.js. To avoid this in a local network, store a copy of the library on your local server and reference it in your web pages. E.g. instead of using:

<script src="https://cdnjs.cloudflare.com/ajax/libs/vue/3.2.31/vue.global.min.js"></script>

use

<script src="./lib/vue.global.min.js"></script>

Answer 7

While it is a good thing that Chrome now protects users from cross-site request forgery (CSRF) attacks targeting routers and other devices on private networks, it also means that legitimate applications, namely business applications, that rely on cross-site requests to resources on private networks are negatively affected and need to be changed. In my company, we maintain a web application that is exposed publicly through HTTPs and calls a web service on label printers on the client's private network. We ended up developing a proxy that accepts web service requests on a public and secure endpoint, and forwards them to the web service on the private network. We are now making this proxy available for others to use: https://p2prox.io/

Answer 8

I was able to allow requests from localhost to localhost with setting one new server header to preflight and usual requests:

Access-Control-Allow-Private-Network: true

Source:
https://web.dev/cors-rfc1918-feedback/#step-2:-sending-preflight-requests-with-a-special-header

Answer 9

Original Answer

I finally found the answer, in this RFC about CORS-RFC1918 from a Chrome-team member. To sum it up, Chrome has implemented CORS-RFC1918, which prevents public network resources from requesting private-network resources - unless the public-network resource is secure (HTTPS) and the private-network resource provides appropriate (yet-undefined) CORS headers.

There's also a Chrome flag you can change to disable the new behavior for now: chrome://flags/#block-insecure-private-network-requests

Disabling that flag does mean you're re-opening the security hole that Chrome's new behavior is meant to close.

---

Update 2021: A few months after I posted this question, the flag I referenced in my original answer was removed, and instead of disabling a security feature I was forced to solve the problem more satisfactorily by serving assets over HTTPS.

Update 2022: Chrome 98 is out, and it introduces support for Preflight requests. According to the announcement, failed requests are supposed to produce a warning and have no other effect, but in my case they are full errors that break my development sites. So I had to add middleware to teach webpack-dev-server how to serve preflight requests.

Private Network Access (formerly CORS-RFC1918) is a specification that forbids requests from less private network resources to more private network resources. Like HTTP to HTTPS, or a remote host to localhost.

The ultimate solution was to add a self-signed certificate and middleware which enabled requests from my remote dev server to my localhost webpack-dev-server for assets.

Generate certificates

cd path/to/.ssl
npx mkcert create-cert

Configure webpack-dev-server to use certificates and serve preflight requests

module.exports = {
  //...
  devServer: {
    https: {
      key: readFileSync("./.ssl/cert.key"),
      cert: readFileSync("./.ssl/cert.crt"),
      cacert: readFileSync("./.ssl/ca.crt"),
    },

    allowedHosts: ".example.dev", // should match host in origin below
    setupMiddlewares(middlewares, devServer) {
      // Serve OPTIONS requests
      devServer.app.options('*', (req, res) => {
        // Only serve if request has expected origin header
        if (/^https:\/\/example\.dev$/.test(req.headers.origin)) {
          res.set({
            "Access-Control-Allow-Credentials": "true",
            "Access-Control-Allow-Private-Network": "true",
            // Using * results in error if request includes credentials
            "Access-Control-Allow-Origin": req.headers.origin,
          })

          res.sendStatus(200)
        }
      }

      return middlewares
    }
  }
}

Trust certificates

1. Right click ca.crt in Windows Explorer and select Install Certificate
2. Select Current User.
3. Choose Place all certificates in the following store, then Browse..., and select Trusted Root Certification Authorities.
4. Finish.

Firefox-specific instructions

Firefox doesn't respect your authoritah! by default. Configure it to do so with these steps:

1. Type about:config into the address bar
2. Search for security.enterprise_roots.enabled
3. Toggle the setting to true