How to Configure Local Network Access Permissions in Google Chrome

Modern malicious web campaigns frequently target internal enterprise and home networks through Cross-Site Request Forgery (CSRF) attacks directed at private IP ranges—such as domestic routers, IoT appliances, and internal corporate microservices. To eliminate this attack vector, Google Chrome introduces the Local Network Access (LNA) specification (formerly Private Network Access). Under LNA, public websites cannot freely initiate subresource requests or fetch calls to private or loopback IP addresses without explicit CORS preflight checks and user authorization.

Understanding Chrome Local Network Access Architecture

The Local Network Access specification divides network address spaces into three tiered IP address categories:

• Public IP Space: Globally routable public internet addresses (e.g., standard external web servers).
• Private IP Space: RFC 1918 private subnets (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and carrier-grade NAT blocks.
• Local / Loopback IP Space: The host loopback address (127.0.0.1 or ::1).
• Security Boundary Hierarchy: Less secure public origins are strictly prohibited from probing more private origins unless the target internal endpoint explicitly responds to an Access-Control-Request-Private-Network preflight header with Access-Control-Allow-Private-Network: true.

Configuring Local Network Permissions in Chrome Settings

Users and developers can manage which sites are granted permission to interact with local hardware:

1. Open Google Chrome, click the three-dot menu, and select Settings.
2. Navigate to Privacy and security > Site settings.
3. Scroll down to the Permissions section and select Additional permissions.
4. Click on Local network access.
5. Select your default enforcement mode:
   • Sites can ask to access your local network (Recommended default).
   • Don’t allow sites to access your local network (Strict isolation mode).
6. Under Customized behaviors, manually add trusted developer origins (e.g., https://staging.digitash.com) to the allowlist.

Debugging LNA Preflight Blocks in Chrome DevTools

When a web application fails to communicate with a local IoT device, inspect the network preflight in DevTools:

1. Press Ctrl + Shift + I (or Option + Command + I on macOS) to launch DevTools.
2. Switch to the Network tab and reproduce the connection request.
3. Filter requests by Fetch/XHR.
4. Locate preflight OPTIONS requests flagged in red with an ERR_FAILED status.
5. Inspect the Headers tab:
   • Verify whether Chrome sent Access-Control-Request-Private-Network: true.
   • Confirm whether the local device server failed to return the corresponding Access-Control-Allow-Private-Network: true header.
6. Review the Issues tab in DevTools for structured guidance on Local Network Access policy violations.

Configuring Enterprise Policy Exclusions via Windows Registry

In enterprise corporate environments hosting legacy internal dashboards that cannot be quickly refactored with modern CORS preflight handlers, administrators can bypass LNA blocks via Group Policy:

# Registry key for Chrome enterprise policies
# HKEY_LOCAL_MACHINESOFTWAREPoliciesGoogleChromeInsecurePrivateNetworkRequestsAllowedForUrls

# Configure allowlisted origin patterns via PowerShell
$regPath = "HKLM:\SOFTWARE\Policies\Google\Chrome\InsecurePrivateNetworkRequestsAllowedForUrls"
if (-not (Test-Path $regPath)) {
    New-Item -Path $regPath -Force | Out-Null
}

Set-ItemProperty -Path $regPath -Name "1" -Value "https://internal-portal.digitash.corp"

Securing Internal Endpoints for Compliance

To ensure long-term compatibility, internal firmware and microservice developers should implement compliant preflight response headers on local servers, guaranteeing secure communication without requiring browser policy bypasses.