Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question / Feature Request] CORS-RFC1918 Support #236

Open
NoelDavies opened this issue May 18, 2021 · 5 comments · May be fixed by #274
Open

[Question / Feature Request] CORS-RFC1918 Support #236

NoelDavies opened this issue May 18, 2021 · 5 comments · May be fixed by #274

Comments

@NoelDavies
Copy link

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
Copy link
Contributor

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
Copy link

@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
Copy link

mash commented Feb 21, 2022

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
Copy link

Abhi347 commented May 2, 2022

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 joostdebruijn linked a pull request Aug 2, 2022 that will close this issue
@joostdebruijn
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants