Chrome's Private Network Access Update: Secure Your Network and Prepare for Deprecation

Chrome is tightening security with the Private Network Access (PNA) specification, formerly known as CORS-RFC1918, to defend users against Cross-Site Request Forgery (CSRF) attacks targeting routers and other private network devices. These attacks can redirect users to malicious servers, impacting hundreds of thousands. Understand the changes and how to prepare.

What's Changing? Key Updates to Private Network Access

• Blocking Insecure Requests: Chrome will block requests from non-secure websites (those without HTTPS) to private networks.
• Deprecation Trial: A deprecation trial offers a temporary extension for developers. If you need more time to adjust, you can request an extension for specific origins.
• Chrome Policy Bypass: Managed Chrome deployments can use Chrome policies to permanently bypass the deprecation.

Important Dates: Chrome's Private Network Access Timeline

• November 2020: Initial feedback requested on upcoming changes.
• March 2021: Changes announced, specification renamed to Private Network Access.
• April 2021: Chrome 90 releases with deprecation warnings.
• June 2021: Chrome 92 (Beta) initially forbids private network requests but is deferred to Chrome 93.
• July 2021: Deprecation and trial deferred to Chrome 94; private websites are excluded.
• August 2021: Chrome 94 (Beta) allows developers to sign up for the deprecation trial.
• September 2021: Chrome 94 (Stable) requires developers to deploy trial tokens.
• December 2022: Origin trial survey results in extension to Chrome 113.
• March 2023: Deprecation trial extended to Chrome 116, ending in Chrome 117. A permission-based mechanism is in development.
• May 2023 (Tentative): Chrome 114 introduces the permission-based mechanism.
• September 2023: Chrome 117 ends the deprecation trial, blocking all private network requests from public, non-secure contexts.

Understanding Private Network Access (PNA)

PNA restricts websites from sending requests to servers on private networks, permitting them only from secure contexts. It enhances the Cross-Origin Resource Sharing (CORS) protocol, requiring websites to explicitly request permission from private network servers before sending requests.

Private network requests target servers with more private IP addresses than the request origin. This includes requests from a public website (like https://example.com) to a private one (like http://router.local) or from a private site to localhost.

Deprecation Trials Explained

Deprecation trials offer a way to phase out web features, giving websites time to adjust. During a trial, deprecated features are disabled by default. Developers can register for the trial to obtain tokens, allowing their websites to temporarily use the feature.

Chrome 94 and Beyond: What's Changing?

From Chrome 94, public non-secure contexts cannot make requests to the private network. A deprecation trial lets developers continue using the feature until Chrome 117 by registering for tokens.

Chrome policies can disable the deprecation entirely or for specific origins, assisting managed Chrome installations.

Recommended Actions for Developers

The primary step is to gain time using the deprecation trial or policies, followed by implementing a long-term fix.

1. Register for the Deprecation Trial

• Register for the Private Network Access origin trial to get a trial token.
• Add the Origin-Trial: $token to your response header on main resource and navigation responses.

2. Enable Policies (For Managed Environments)

• Use the InsecurePrivateNetworkRequestsAllowed or InsecurePrivateNetworkRequestsAllowedForUrls policies.

Addressing Specific Scenarios

Accessing Localhost

Upgrade your website to HTTPS. Requests to http://localhost (or http://127.*.*.*, http://[::1]) are not blocked by Mixed Content when initiated from secure contexts.

Accessing Private IP Addresses

Upgrading the initiator website to HTTPS alone is insufficient. Mixed Content prevents secure contexts from making plain text HTTP requests. Solutions include:

• Upgrade Both Ends to HTTPS
• Use WebTransport
• Reverse the Embedding Relationship

1. Upgrade Both Ends to HTTPS

For intranet contexts where you control DNS resolution:

• Register a public domain name (e.g., intranet.example).
• Obtain a TLS certificate for this domain.
• Configure private DNS to resolve intranet.example to the server's private IP.
• Configure your private server to use the TLS certificate.

2. Use WebTransport

WebTransport allows secure connections to private devices using certificate pinning, bypassing the need for a valid TLS certificate. It requires a minimal WebTransport server and can be combined with a service worker to proxy HTTP requests.

3. Reverse Embedding

If the target server cannot run HTTPS, serve a skeleton app from the private server that fetches subresources from a public server (CDN). This makes requests same-origin.

Future Plans: Beyond Chrome 117

Restricting private network requests to secure contexts is the initial step. Chrome aims to fully implement the PNA specification, including:

• Restricting localhost access from private websites.
• Implementing CORS preflight requests.
• Restricting navigation fetches.

Stay informed for further updates as Chrome continues to enhance network security.