BerandaComputers and TechnologyCORS for Private Networks (RFC1918)

CORS for Private Networks (RFC1918)

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

To understand how this change impacts the web ecosystem, the Chrome team is
looking for feedback from developers who build servers for private networks.

What’s wrong with the status quo?

Many web servers run within a private network—wireless routers, printers,
intranet websites, enterprise services, and Internet of Things (IoT) devices are only part of them.
They might seem to be in a safer environment than the ones exposed to the public
but those servers can be abused by attackers using a web page as a proxy. For
example, malicious websites can embed a URL that, when simply viewed by the
victim (on a JavaScript-enabled browser), attempts to change the DNS server
settings on the victim’s home broadband router. This type of attack is called
” and
it happened in
More than 300,000 vulnerable wireless routers were exploited by having their DNS
settings changed and allowing attackers to redirect users to malicious servers.


To mitigate the threat of similar attacks, the web community is bringing
CORS-RFC1918Cross Origin Resource
Sharing (CORS)
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
are still under development.)

Developers of such devices or servers will be requested to do two things:

  • Make sure the website making requests to a private network is served over
  • Set up the server support for CORS-RFC1918 and respond with expected HTTP

What kinds of requests are affected?

Affected requests include:

  • Requests from the public network to a private network
  • Requests from a private network to a local network
  • Requests from the public network to a local network

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 ::1/128, 2000::/3 and ff00::/8 subnets.

A local network

A destination that resolves to the “loopback” space ( defined in
section of RFC1122 of IPv4, the
“link-local” space ( 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.

Relationship between public, private, local networks in CORS-RFC1918
Relationship between public, private, local networks in CORS-RFC1918.

Chrome’s plans to enable CORS-RFC1918

Chrome is bringing CORS-RFC1918 in two steps:

Step 1: Requests to private network resources will be allowed only from HTTPS web pages

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.

CORS-RFC1918 errors will be reported as CORS policy errors in the console.
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:

CORS-RFC1918 errors will also be reported as CORS error errors in the Network panel.
CORS-RFC1918 errors will also be reported as CORS error errors in the Network panel.

In Chrome 87, CORS-RFC1918 errors are only reported in the DevTools Console as

You can try it out yourself using this test

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.

Feedback wanted

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:

  • Go to chrome://flags#block-insecure-private-network-requests, turn on the
    flag and see if your website sends requests to the private network resource as
  • If you encounter any issues or have feedback, file an issue at
    and set the component to Blink>SecurityFeature>CORS>RFC1918.

Example feedback

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 Chrome would love to hear from you.

Hero image by Stephen
on Unsplash.

Last updated:

Improve article

Read More



Please enter your comment!
Please enter your name here

Most Popular

Recent Comments