[Question / Feature Request] CORS-RFC1918 Support

[NoelDavies]

Is your feature request related to a problem? Please describe.
I've not seen this mentioned before (apologies if it has come up).

Chrome will soon implement this and block any public to private requests (public domain to 127.0.0.1).

See https://chromestatus.com/feature/5436853517811712

Describe the solution you'd like
Update the cors package to easily set the new CORS header (maybe auto-magically?)
https://wicg.github.io/private-network-access/#headers

Describe alternatives you've considered
I could host a centralized server, but I'd rather not do this for my users.

Additional context
Chrome's current warning message

This now appears in chrome:
[Deprecation] The website requested a subresource from a network that it could only access because of its users' privileged network position. These requests expose non-public devices and servers to the internet, increasing the risk of a cross-site request forgery (CSRF) attack, and/or information leakage. To mitigate these risks, Chrome deprecates requests to non-public subresources when initiated from non-secure contexts, and will start blocking them in Chrome 92 (July 2021). See https://chromestatus.com/feature/5436853517811712 for more details.

(Sidenote - spoke to to the socket.io devs and they pointed me to you guys - socketio/socket.io#3929)

[dougwilson]

Yea, an option to enable this can certainly be added. I'm not sure what you mean by auto magically, though. Can you elaborate on what you are picturing with that?

[bitconym]

@dougwilson what @NoelDavies means is that you can automatically enable and add the required headers if you detect private IP like 127.0.0.1 or in the private ranges as specified here: https://wicg.github.io/private-network-access/#ip-address-space-heading

I'm personally against that as it defies the purpose of having these headers in the first place. But we can have some property like allowPrivateNetworkAccess if set to true CORS module can auto-add the required header Access-Control-Allow-Private-Network: true.

As I understand in the preflight request the client needs to use the header Access-Control-Request-Private-Network for OPTIONS preflight request to pass.

[mash]

Chrome 98 seems to have started to add and require Access-Control-Request-Private-Network header.
https://developer.chrome.com/blog/private-network-access-preflight/

After disabling chrome://flags/#block-insecure-private-network-requests , Chrome still adds and requires the header.

For future visitors, you can do:

app.use('/', function (req, res, next) {
  if (req.headers["access-control-request-private-network"]) {
    res.setHeader("access-control-allow-private-network", "true");
  }
  next(null);
})

But I hope to see some flag in cors package.

[Abhi347]

Chrome Beta version 102, started the experiment again and the preflight requests are sent with Access-Control-Request-Private-Network header.

For future readers, disabling both the following flags are required, in case you wanna disable requesting the headers from the Chrome browser for now.

chrome://flags/#block-insecure-private-network-requests
chrome://flags/#private-network-access-send-preflights

[joostdebruijn]

I created PR #274 for this.

About the "maybe auto-magically?": user agents should only send the Access-Control-Request-Private-Network-header when they do requests to private networks. So, in my PR Access-Control-Allow-Private-Network: true is only returned when the user agent requested it in the CORS preflight.