Can a website reach your localhost? This is one of the most nuanced security boundaries in modern browsers. The answer depends on whether you're using HTTP or WebSockets, which browser you're on, and what origin your site is served from. Here's the complete 2025 picture.
🌐 The Problem: Why Browsers Restrict Localhost Access
When a public website (e.g., https://example.com) makes a request to http://localhost:3000, it is crossing a security boundary — from a public network to the user's private/local network. This enables a class of attacks called CSRF on local services — attackers can trick your browser into sending commands to your local router, development server, or any locally-running service.
The W3C specification Private Network Access (PNA) — formerly known as CORS-RFC1918 — was designed to address this. Chrome began enforcing it in Chrome 94 (2021) and the rules have been evolving ever since.
📡 Option 1: HTTP Fetch/XHR to Localhost
| Browser | HTTPS site → localhost HTTP | HTTP site → localhost HTTP | Status |
|---|---|---|---|
| Chrome 94+ | ⚠️ PNA preflight required — server must respond with Access-Control-Allow-Private-Network: true | 🚫 Blocked (Mixed Content + PNA) | Enforced |
| Firefox 120+ | ⚠️ Mixed Content blocks plain HTTP — https:// site cannot fetch http://localhost | ✅ Generally allowed (no PNA) | No PNA |
| Edge (Chromium) | ⚠️ Same as Chrome — PNA enforced since Edge 94 | 🚫 Blocked (Mixed Content) | Enforced |
| Safari | 🚫 Blocks as Mixed Content (stricter than spec — forbids even localhost) | 🚫 Blocked | Strictest |
🔌 Option 2: WebSocket to Localhost
WebSockets have a more nuanced history. The good news: ws://localhost connections from HTTPS pages are not blocked by Mixed Content in Chrome/Edge (unlike http://localhost fetch). The bad news: PNA preflights now apply to WebSocket too.
| Browser | ws:// from HTTPS page | wss:// from HTTPS page | Notes |
|---|---|---|---|
| Chrome 94+ | ⚠️ PNA preflight required via HTTP OPTIONS before WS upgrade | ✅ Works (if CORS allows) | PNA applies since Chrome 107 |
| Firefox | ✅ Allowed — Firefox does not implement PNA for WebSockets | ✅ Works | No PNA, no Mixed Content block for ws:// |
| Edge | ⚠️ Same as Chrome | ✅ Works | Chromium-based, same PNA rules |
| Safari | 🚫 Blocks as Mixed Content (even ws://) | ✅ Works | WebKit blocks non-secure WS from secure context |
🛡️ Private Network Access (PNA) — Deep Dive
PNA is the Chrome/Edge specification that governs this. Here is exactly what happens when a Chrome page tries to reach localhost:
// 1. Browser sends a PNA preflight HTTP OPTIONS request first: OPTIONS /api HTTP/1.1 Host: localhost:3000 Access-Control-Request-Method: GET Access-Control-Request-Private-Network: true ← PNA header Origin: https://example.com // 2. Local server MUST respond with: HTTP/1.1 200 OK Access-Control-Allow-Origin: https://example.com Access-Control-Allow-Private-Network: true ← Without this, blocked! // 3. Only then is the actual request sent
If the local server doesn't respond correctly to the preflight, Chrome blocks the request with a console error: "The request client is not a secure context and the resource is in a more-private address space."
⚙️ All Options for Websites Calling Localhost
✅ Option A: Serve Both Sides over HTTPS
Run local dev server with a self-signed cert + add it to your trust store, or use a tool like mkcert. Works everywhere but requires setup per machine.
✅ Option B: Add PNA Response Headers
Add Access-Control-Allow-Private-Network: true to your local server responses. Works for Chrome/Edge from HTTPS origins.
✅ Option C: Use WebTransport
Chrome's recommended long-term alternative. Uses QUIC+TLS with certificate pinning. Allows bypassing PNA restrictions for secure peer-to-peer connections.
⚠️ Option D: Host App on localhost (Reverse Embed)
Serve the web app from the local server itself (not from a public domain). Then all calls are same-origin — PNA and Mixed Content don't apply.
⚠️ Option E: Chrome Enterprise Policy
For managed Chrome deployments, InsecurePrivateNetworkRequestsAllowed policy can bypass PNA. Not suitable for public-facing web apps.
✅ Option F: Use HTTP (not HTTPS) for your public page
An HTTP origin can reach localhost without PNA (Firefox) or Mixed Content restrictions. Not recommended for production — gives up HTTPS security.
📋 Current Browser Support Summary (2025)
| Feature | Chrome | Firefox | Edge | Safari |
|---|---|---|---|---|
| HTTP to localhost from HTTPS | ⚠️ PNA + Mixed Content | 🚫 Mixed Content | ⚠️ PNA + Mixed Content | 🚫 Blocked |
| HTTP to localhost from HTTP | ⚠️ PNA preflight | ✅ Allowed | ⚠️ PNA preflight | ✅ Allowed |
| ws:// to localhost from HTTPS | ⚠️ PNA preflight | ✅ Allowed | ⚠️ PNA preflight | 🚫 Mixed Content |
| wss:// to localhost from HTTPS | ✅ CORS only | ✅ CORS only | ✅ CORS only | ✅ CORS only |
| Private Network Access Spec | ✅ Implemented (Ch 94) | 🔲 Not implemented | ✅ Implemented | 🔲 Not implemented |
Written by Alex R. | Coding with Alex | Tags: Web Security, Private Network Access, WebSockets, localhost, Chrome, Firefox