Mitigate the risks associated with unintentional exposure of devices and servers on a client’s internal network to the web at large.
Malicious websites making requests to devices and servers hosted on a private network have long been a threat. Attackers may, for example, change a wireless router's configuration to enable Man-in-the-Middle attacks. CORS-RFC1918 is a proposal to block such requests by default on the browser and require internal devices to opt-in to requests from the public internet.
To understand how this change impacts the web ecosystem, the Chrome team is looking for feedback from developers who build servers for private networks.
To mitigate the threat of similar attacks, the web community is bringing CORS-RFC1918—Cross Origin Resource Sharing (CORS) specialized for private networks defined in RFC1918.
Browsers that implement CORS check with target resources whether they are okay being loaded from a different origin. This is accomplished either with extra headers inline describing the access or by using a mechanism called preflight requests, depending on the complexity. Read Cross Origin Resource Sharing to learn more.
With CORS-RFC1918 the browser will block loading resources over the private network by default except ones that are explicitly allowed by the server using CORS and through HTTPS. The website making requests to those resources will need to send CORS headers and the server will need to explicitly state that it accepts the cross-origin request by responding with corresponding CORS headers. (The exact CORS headers are still under development.)
Developers of such devices or servers will be requested to do two things:
Affected requests include:
A private network A destination that resolves to the private address space defined in Section 3 of RFC1918 in IPv4, an IPv4-mapped IPv6 address where the mapped IPv4 address is itself private, or an IPv6 address outside the
A local network A destination that resolves to the "loopback" space (
127.0.0.0/8) defined in section 22.214.171.124 of RFC1122 of IPv4, the "link-local" space (
169.254.0.0/16) defined in RFC3927 of IPv4, the "Unique Local Address" prefix (
fc00::/7) defined in Section 3 of RFC4193 of IPv6, or the "link-local" prefix (
fe80::/10) defined in section 2.5.6 of RFC4291 of IPv6.
A public network All others.
Chrome is bringing CORS-RFC1918 in two steps:
Chrome 87 adds a flag that mandates public websites making requests to private network resources to be on HTTPS. You can go to
chrome://flags#block-insecure-private-network-requests to enable it. With this flag turned on, any requests to a private network resource from an HTTP website will be blocked.
Starting from Chrome 88, CORS-RFC1918 errors will be reported as CORS policy errors in the console.
In the Network panel of Chrome DevTools you can enable the Blocked Requests checkbox to focus in on blocked requests:
In Chrome 87, CORS-RFC1918 errors are only reported in the DevTools Console as
You can try it out yourself using this test website.
In the future, whenever a public website is trying to fetch resources from a private or a local network, Chrome will send a preflight request before the actual request.
The request will include an
Access-Control-Request-Private-Network: true header in addition to other CORS request headers. Among other things, these headers identify the origin making the request, allowing for fine-grained access control. The server can respond with an
Access-Control-Allow-Private-Network: true header to explicitly indicate that it grants access to the resource.
These headers are still under development and may change in the future. No action is currently required.
If you are hosting a website within a private network that expects requests from public networks, the Chrome team is interested in your feedback and use cases. There are two things you can do to help:
chrome://flags#block-insecure-private-network-requests, turn on the flag and see if your website sends requests to the private network resource as expected.
Our wireless router serves an admin website for the same private network but through HTTP. If HTTPS is required for websites that embed the admin website, it will be mixed content. Should we enable HTTPS on the admin website in a closed network?
This is exactly the type of feedback Chrome is looking for. Please file an issue with your concrete use case at crbug.com. Chrome would love to hear from you.
Hero image by Stephen Philips on Unsplash.