Cybersecurity glossary
What is Private Network Access (PNA)?
Learn what Private Network Access (PNA) is, how browsers restrict public websites from reaching private IPs and localhost, preflight requirements, and how developers should design local-device integrations safely.
Definition
Private Network Access (PNA) is a browser security policy—formerly known as CORS-RFC1918—that restricts websites on public networks from making requests to private, local, or loopback addresses unless the target explicitly opts in through CORS and, when required, a dedicated preflight.
Why Private Network Access matters
A visitor’s browser is a powerful network client sitting behind their firewall. Before PNA, a compromised or malicious public webpage could probe 192.168.x.x addresses, hit unauthenticated admin UIs on routers, or call http://127.0.0.1 services on the user’s machine.
Private Network Access (PNA) treats requests from the public web into private address space as especially dangerous. Browsers now require explicit opt-in from the target before those cross-origin calls proceed—closing a gap that CORS alone did not address.
How PNA works
Public site requests a private target
JavaScript on a public HTTPS origin tries to reach a loopback, link-local, or RFC 1918 address.
Browser classifies the destination
The request is flagged as a private network access attempt based on resolved IP space.
PNA preflight may run
An OPTIONS request includes Access-Control-Request-Private-Network: true.
Target opts in explicitly
The response must include Access-Control-Allow-Private-Network: true plus normal CORS headers.
Browser allows or blocks
Without opt-in the request fails in the browser even if the local service would have answered.
Address spaces PNA protects
Loopback
127.0.0.0/8 and ::1—local dev servers, databases, and admin tools on the user’s machine.
Private RFC 1918
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16—typical home and office LANs.
Link-local
169.254.0.0/16 and related ranges—devices without DHCP assignments.
Local domain names
Names resolving to private space (for example *.local) fall under the same policy intent.
Secure context requirement
Public callers are expected to be secure contexts (HTTPS) when accessing private targets.
Corporate intranet
Internal-only apps on private IPs gain protection from drive-by browser probing.
Developer and operator scenarios
| Scenario | Typical PNA behavior | Recommended action |
|---|---|---|
| SaaS page calls user's localhost API | Blocked unless localhost responds with PNA + CORS opt-in | Use a local agent, extension, or native helper—not raw browser fetch |
| IoT device web UI on 192.168.x.x | Public sites cannot probe it cross-origin without opt-in | Keep admin UIs authenticated; avoid global Allow-Private-Network |
| Local dev with frontend on localhost:3000 | Same-origin or properly configured cross-origin local calls may work | Set CORS and PNA headers on the API during development |
| Enterprise app on internal DNS | Extra friction for public-origin JavaScript reaching intranet hosts | Prefer VPN or SSO-protected same-site deployments |
Security checklist
- Never expose unauthenticated admin interfaces on private IPs reachable from user browsers.
- Do not set Access-Control-Allow-Private-Network: true on services that do not need public-web access.
- Pair PNA opt-in with strict CORS origin allowlists—not wildcards on sensitive devices.
- Assume attackers will still reach local services via DNS rebinding or non-browser clients; harden services themselves.
- Prefer same-origin or first-party hosted integration patterns over public-to-local fetch.
- Audit IoT and router firmware for default credentials on LAN interfaces.
- Monitor browser console for PNA failures when shipping local-device pairing features.
- Document secure alternatives (native apps, browser extensions, mDNS with user consent) for hardware vendors.
Limits and pitfalls
PNA protects browser users, not your server’s outbound SSRF surface. A vulnerable backend that fetches user-supplied URLs can still reach internal networks regardless of PNA.
Local services that blindly add Access-Control-Allow-Private-Network: true for convenience recreate the risk PNA was meant to reduce. Opt-in should be deliberate and paired with authentication.
Browser rollout and deprecation timelines evolve. Teams shipping hardware or localhost assistants should test against current Chrome guidance and plan for stricter enforcement rather than permissive workarounds.
The practical takeaway
Private Network Access (PNA) stops public websites from using visitors’ browsers as a bridge into home, office, and loopback networks without explicit target opt-in.
Treat local and private IPs as sensitive attack surface, avoid broadcasting permissive PNA headers, and design integrations that do not depend on arbitrary public-to-local cross-origin fetches.
Related security terms
Cross-Origin Resource Sharing (CORS)
PNA builds on CORS with extra checks when the target is on a private or local network.
Preflight Request
PNA may require an additional preflight before reaching loopback or RFC 1918 targets.
Same-Origin Policy (SOP)
The broader isolation model PNA extends for cross-origin traffic into private address space.
DNS Rebinding
An attack class PNA helps mitigate when public sites probe local services.
Frequently asked questions
What is Private Network Access in simple terms?
PNA stops a normal website on the internet from silently talking to your router, printer, or localhost services unless those devices or proxies explicitly allow it through special browser checks.
Why did browsers add PNA?
Malicious pages could abuse visitors’ browsers as a bridge into home and office networks—scanning internal IPs, exploiting admin panels, or hitting unauthenticated local APIs. PNA closes that path.
What is Access-Control-Allow-Private-Network?
It is a response header local or private-network services can send to opt in to cross-origin access from public websites after the browser’s PNA preflight succeeds.
Does PNA block all localhost development?
Not necessarily. Local development workflows may still work when targets respond correctly or when both sides are treated as secure contexts, but cross-origin public-to-local calls need explicit opt-in.
How is PNA different from CORS?
CORS controls whether JavaScript may read cross-origin responses. PNA adds a gate when the destination IP is private, local, or loopback—even before normal CORS rules fully apply.
Can server-side code bypass PNA?
Yes. PNA is enforced by browsers for web pages. Backend servers and native apps are not limited the same way; design local integrations with that threat model in mind.
References
Explore authoritative guidance and frameworks related to private network access (pna).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.