How to Configure Private Network Access (PNA) Preflight Protections in Google Chrome

Public Internet websites frequently embed malicious scripts attempting Cross-Site Request Forgery (CSRF) or port-scanning against devices located on a user’s private local area network (such as http://192.168.1.1 or http://localhost:8080). Because the browser executes inside the user’s trusted local perimeter, public web origins could historically reconfigure home routers, query development servers, or extract credentials from IoT hardware. Google Chrome’s Private Network Access (PNA) specification eliminates this vector by requiring web applications on less-private IP spaces to send explicit CORS preflight requests before communicating with more-private IP targets.

Understanding Private Network Access (PNA) IP Address Spaces

Google Chrome categorizes all network destinations into three hierarchical IP address spaces:

• public: Globally routable public IP addresses on the public Internet.
• private: Non-routable RFC 1918 subnets (such as 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and link-local addresses.
• local: The loopback interface (127.0.0.1 / localhost).
• The Security Rule: A request originating from a less-private space (e.g. public) attempting to access a more-private space (e.g. private or local) must pass a dedicated PNA preflight check.

Configuring Web Servers and Local APIs for PNA Preflights

When Chrome dispatches a PNA preflight, it includes the request header Access-Control-Request-Private-Network: true. Target intranet servers or local microservices must explicitly approve the connection:

# Nginx configuration for local intranet API or development server
location /api/ {
    if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Allow-Origin' 'https://app.example.com' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
        add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization' always;
        add_header 'Access-Control-Allow-Private-Network' 'true' always;
        add_header 'Content-Length' 0;
        add_header 'Content-Type' 'text/plain charset=UTF-8';
        return 204;
    }

    add_header 'Access-Control-Allow-Origin' 'https://app.example.com' always;
    add_header 'Access-Control-Allow-Private-Network' 'true' always;
    proxy_pass http://127.0.0.1:3000;
}

Auditing PNA Violations in Chrome DevTools

To inspect and troubleshoot Private Network Access blocking in Google Chrome:

1. Open Google Chrome and navigate to the public web application.
2. Open Chrome DevTools by pressing Ctrl + Shift + I (or Option + Command + I on macOS).
3. Select the Network tab.
4. Trigger the local request. If the intranet endpoint omits the required PNA header, Chrome blocks the connection with:

   net::ERR_BLOCKED_BY_PRIVATE_NETWORK_ACCESS_CHECKS

5. Switch to the Issues tab in DevTools. Chrome identifies the target IP address space transition (e.g. public -> private) and details missing CORS response headers.

Ensuring Secure Context Requirements

Google Chrome strictly mandates that Private Network Access requests can only be initiated from Secure Contexts (https://). Attempting to access private endpoints from insecure public origins (http://) results in an immediate block without dispatching a preflight.