How Chromium Protects Local Networks from Web Probing

This article provides a comprehensive overview of the privacy and security protections implemented by the Chromium web browser to stop public websites from probing Local Area Network (LAN) IP addresses. By utilizing the Private Network Access (PNA) specification, Chromium prevents malicious websites from scanning internal networks, fingerprinting local devices, and exploiting vulnerable routers or IoT hardware. Below is a direct breakdown of the specific technical mechanisms—including IP categorization, Secure Context mandates, and preflight headers—that Chromium uses to enforce these boundaries.

Categorization of IP Address Spaces

To enforce network boundaries, Chromium categorizes all IP addresses into three distinct address spaces:

• Public: Globally routable IP addresses accessible over the open internet.
• Private: IP addresses reserved for local area networks (such as 192.168.x.x, 10.x.x.x, and 172.16.x.x as defined in RFC 1918).
• Local: Loopback addresses that refer to the user's own host machine (such as 127.0.0.1 or ::1).

Chromium considers the local space to be more private than the private space, and the private space to be more private than the public space. Private Network Access rules are triggered automatically whenever a website attempts to make a network request from a more public address space to a more private one.

Mandatory Secure Contexts (HTTPS)

Chromium requires that any public website attempting to communicate with a private network must be served over a Secure Context (HTTPS).

If an insecure (HTTP) public website attempts to fetch a resource from a private LAN IP address, Chromium blocks the request immediately. This prevents attackers on the same network from intercepting traffic to inject scripts that probe the local network.

Explicit CORS Preflight Handshakes

Historically, websites could use simple HTML tags (like <img> or <script>) to blindly send requests to local IP addresses and measure response times to map out a user's home network. Chromium neutralizes this by enforcing Cross-Origin Resource Sharing (CORS) preflight requests for all private network requests, regardless of how the request is initiated.

Before Chromium sends the actual request to the local device, it sends an OPTIONS preflight request containing a specific header:

Access-Control-Request-Private-Network: true

For the connection to succeed, the target device on the LAN must explicitly grant permission by responding with:

Access-Control-Allow-Private-Network: true

If the local device does not return this exact header, Chromium aborts the request andwithholds the response data from the public website. Because legacy routers and vulnerable IoT devices are not programmed to return this header, they are automatically protected from unauthorized web probing and Cross-Site Request Forgery (CSRF) attacks.

Defense Against DNS Rebinding

Attackers often use DNS rebinding—where a public domain name is configured to resolve to a private IP address like 192.168.1.1—to bypass same-origin policies.

Chromium defeats this by evaluating the actual resolved IP address of the target server rather than trusting the domain name. Even if a website requests a resource from what appears to be a public domain, Chromium checks the resolved IP address right before establishing the connection. If that IP falls within the private or local address range, the PNA protections and preflight checks are strictly enforced.

Timing Attack Mitigations

Websites can sometimes infer the existence of a device on a LAN simply by measuring how long it takes for a connection to fail or be rejected. Because the PNA preflight check happens at the browser level before any payload is sent, and because unauthorized requests are uniformally blocked before reaching the JavaScript execution context, the initiating website receives a generic network error. This reduces the accuracy of side-channel timing attacks used to scan local ports.

User Permission Prompts for Local Devices

A major challenge for local network security is that most LAN devices (like printers or smart home hubs) do not have valid TLS certificates, meaning they can only communicate over plain HTTP. When an HTTPS public website tries to connect to an HTTP local device, Chromium's "Mixed Content" blocker normally terminates the connection.

To allow legitimate use cases while maintaining privacy against probing, Chromium implements a user-facing permission prompt. If a public HTTPS site requests access to an HTTP local device, it can explicitly opt into a permission flow.

During the preflight handshake, the local device must return two additional headers to identify itself:

• Private-Network-Access-ID: The MAC address or unique identifier of the device.
• Private-Network-Access-Name: A human-readable name for the device.

Chromium uses this information to display a prompt to the user, asking if they want to allow the public website to connect to that specific local device. The website cannot probe or interact with the local IP unless the user manually clicks "Allow."