v147 · shipped · security · webtransport
Local network access restrictions for WebTransport
Chrome 147 extends Local Network Access (LNA) protections to WebTransport connections. Public websites now need explicit user permission before opening a WebTransport session to local or private IP addresses. This mirrors the same protections already in place for HTTP subresource fetches and WebSocket connections.
localhost, 192.168.x.x, 10.x.x.x, etc.) now trigger a permission prompt in Chrome 147. Existing apps that relied on silent WebTransport connections to local services will stop working until users grant permission.
at a glance
| Shipped in | Chrome 147 (desktop, Android) |
|---|---|
| Status | Enabled by default |
| Flag | chrome://flags/#local-network-access-check-webtransport |
| Finch feature | LocalNetworkAccessChecksWebTransport |
| Spec | WICG Local Network Access spec |
| ChromeStatus | 5126430912544768 — Local network access restrictions for WebTransport |
Shipped-versus-proposed disagreement, both sides reported rather than resolved: this page records the feature as shipped
in Chrome 147 with the Local Network Access check enabled by default, while the ChromeStatus record for feature
5126430912544768 still reads “Proposed” with accurate_as_of 2026-03-24 (fetched 2026-10-06).
why it exists
WebTransport provides low-latency, bidirectional communication between a page and a server using QUIC. Like WebSocket, it can target local network addresses — making it a potential vector for cross-origin attacks on private devices. A malicious public website could silently open a WebTransport session to https://192.168.1.1 and interact with a home router or IoT device. Chrome's LNA framework had already restricted plain HTTP fetches and WebSocket connections to private addresses; Chrome 147 applies the same permission-based gate to WebTransport. Note that WebTransport is already restricted to secure contexts, removing mixed-content concerns.
what changes
Opening a WebTransport session from a public origin to a local/private address now requires:
- The page must be served over HTTPS (already required by WebTransport itself).
- The user must grant the Local Network Access permission when prompted.
WebTransport is not supported in WebView for the same reasons that other LNA-governed speculation rules prerendering is unsupported in WebView, so this restriction does not affect WebView.
// A public-origin page opening a WebTransport session to a device on the local network.
// Chrome 147 now shows the Local Network Access permission prompt before connecting.
const transport = new WebTransport("https://192.168.1.1:4433/session");
transport.closed
.then(() => console.log("Session closed."))
.catch((err) => console.error("Connection failed:", err));
Affected address ranges
| Address range | Examples |
|---|---|
| Loopback | 127.0.0.1, localhost, ::1 |
| Private (RFC 1918) | 10.x.x.x, 172.16–31.x.x, 192.168.x.x |
| Link-local | 169.254.x.x, fe80::/10 |
browser support
| Browser | Support |
|---|---|
| Chrome 147+ (desktop, Android) | Enabled by default |
| Firefox | No position |
| Safari | No position |