Google is testing a new feature to prevent malicious public websites from pivoting through a user’s browser to attack devices and services on internal, private networks.
More simply, Google plans to prevent bad websites on the internet from attacking a visitor’s devices (like printers or routers) in your home or on your computer. People usually consider these devices safe as they’re not directly connected to the internet and are protected by a router.
“To prevent malicious websites from pivoting through the user agent’s network position to attack devices and services which reasonably assumed they were unreachable from the Internet at large, by virtue of residing on the user’s local intranet or the user’s machine,” Google described the idea in a support document.
Block unsafe requests to internal networks
The proposed “Private Network Access protections” feature, which will be in a “warning-only” mode in Chrome 123, conducts checks before a public website (referred to as “site A”) directs a browser to visit another site (referred to as “site B”) within the user’s private network.
The checks include verifying if the request comes from a secure context and sending a preliminary request to see if site B (e.g. HTTP server running on loopback address or router’s web panel) permits access from a public website through specific requests called CORS-preflight requests.
Unlike existing protections for subresources and workers, this feature focuses specifically on navigation requests. Its primary purpose is to shield users’ private networks from potential threats.
In an example provided by Google, the developers illustrate an HTML iframe on a public website that performs a CSRF attack that changes the DNS configuration of a visitor’s router on their local network.
Under this new proposal, when the browser detects that a public site attempts to connect to an internal device, the browser will send a preflight request to the device first.
If there is no response, the connection will be blocked. However, if the internal device responds, it can tell the browser whether the request should be allowed using an ‘Access-Control-Request-Private-Network‘ header.
This allows requests to devices on an internal network to be automatically blocked unless the device explicitly allows the connection from public websites.
While in the warning stage, even if the checks fail, the feature won’t block the requests. Instead, developers will see a warning in the DevTools console, giving them time to adjust before stricter enforcement begins.
However, Google warns that even if a request is blocked, an automatic reload by the browser will allow the request to go through, as it would be seen as an internal => internal connection.
“Private Network Access protections will not apply in this case since the feature was designed to protect users’ private network from more-public web pages,” warns Google.
To prevent this, Google proposes to block auto-reloading of a page if the Private Network Access feature previously blocked it.
When this happens, the web browser will display an error message stating that you can allow the request to go through by manually reloading the page, as shown below.
Source: Google
This page would include a new Google Chrome error message, “BLOCKED_BY_PRIVATE_NETWORK_ACCESS_CHECKS,” to tell you when a page can’t load because it didn’t pass Private Network Access security checks.
The idea behind the security upgrade
The motivation behind this development is to prevent malicious websites on the internet from exploiting flaws on devices and servers in users’ internal networks, which were presumed safe from internet-based threats.
This includes protecting against unauthorized access to users’ routers and software interfaces running on local devices—a growing concern as more applications deploy web interfaces assuming nonexistent protections.
According to a support document, Google started exploring this idea in 2021 to prevent external websites from making harmful requests to resources within the private network (localhost or a private IP address).
While the immediate goal is to mitigate risks like those from “SOHO Pharming” attacks and CSRF (Cross-Site Request Forgery) vulnerabilities, the specification does not aim to secure HTTPS connections for local services—a necessary step for integrating public and non-public resources securely but beyond the current scope of the specification.