Connection Allowlist Demo 3: WebRTC Address Discovery

WebRTC open — this page can learn your public IP

The channel that leaves no trace

Not everything that reaches the network looks like a request.

⚠️ No list is set. Press the button and this page will tell you your own public IP address. Watch the Network tab while you do it — nothing appears there, because WebRTC does not use HTTP.

💡 Open DevTools → Network tab first. The contrast between what the tab shows and what the page learns is the point.

Your address is only rendered back into this page. It is not sent anywhere, stored, or logged. The lookup uses Google's public STUN server, the same one most WebRTC applications default to.

Why this matters

WebRTC exists for calls and peer-to-peer data, but any script on the page can open a peer connection, and the address discovery that makes peer-to-peer work also reveals the visitor's real public IP — through a VPN in some configurations, and without touching the HTTP stack that your monitoring watches.

Chrome hides local addresses behind an mDNS .local name to limit this. The server-reflexive address, the public one, is not hidden.

A Connection Allowlist refuses WebRTC unless you write webrtc=allow. If your site does not make calls, you close the channel by deploying a list at all — and if it does, you opt back in deliberately.

Reading the reports

A refused WebRTC connection has no hostname to report, so it appears in the Connection column of your Report URI account as the literal value webrtc rather than a URL. That is the browser telling you a peer connection was refused, not a malformed report.

WebSockets, WebTransport, DNS prefetch and navigations are all evaluated against the same list for the same reason: a destination should not be reachable simply because the code chose a different way to get there. Demo 4 covers redirects, the remaining case.

← Demo 2

1 2 3 4

Demo 4 →