WebRTC leaks, browser by browser
WebRTC collects the addresses your machine can be reached on so browsers can connect peers directly, and any script can read them without a permission prompt. Firefox has a real switch to disable it. Chromium browsers do not, so an extension is the only reliable control.
4 min read
WebRTC exists so browsers can carry voice and video without a plugin. To connect two peers directly it has to discover every address each of them can be reached on, which it does by enumerating local interfaces and by asking a STUN server what public address the connection appears to come from.
Any script on any page can start that process and read the result. There is no permission prompt, because the prompt is attached to the camera and microphone rather than to the address discovery.
Why a VPN does not automatically fix it
A VPN changes where traffic exits. It does not change what the browser knows about the machine's network interfaces. If a real interface still exists and is reachable, WebRTC can still describe it.
Whether it does depends on the platform, the browser and how the tunnel is configured — which is why the answer varies and why testing is the only reliable way to know. Run the WebRTC leak test rather than reasoning about it.
Reading a result
Addresses ending in .local. Not a leak. Chromium and Firefox replace local
network addresses with a random mDNS hostname that is meaningless outside your
own network. Seeing these means the protection is working.
Private addresses in 10.x, 172.16–31.x or 192.168.x. Minor. They exist
on millions of home networks simultaneously and cannot be routed to from
outside. They add a small fingerprinting signal and identify nothing on their
own.
A public address that is the VPN's. Expected. That is the address everything else sees too.
A public address that is not the VPN's. The finding that matters. Your real address has been disclosed to any script that asked.
Firefox
The only browser with a genuine switch. In about:config:
media.peerconnection.enabled = false
That disables WebRTC entirely, which breaks browser-based calls. There is no partial setting that keeps calls working and hides addresses, because the address discovery is how calls work.
Firefox also honours media.peerconnection.ice.default_address_only, which
limits candidate gathering to the default route and reduces exposure without
disabling the API.
Chrome, Edge, Brave and other Chromium browsers
No user-facing setting. The flags that once existed were removed, and the policy-based controls are aimed at managed deployments rather than individuals.
The practical options:
- uBlock Origin, which has a "Prevent WebRTC from leaking local IP addresses" option in its settings.
- A VPN browser extension that blocks or constrains the API. This is a real capability an extension has and a system VPN does not, and it is one of the better reasons to run both.
- Brave has its own WebRTC policy control under shields settings, which is more granular than plain Chromium.
Safari
Safari gathers fewer candidates by default and does not expose local addresses to a page that has not been granted media access. It is the most conservative of the major browsers here, and it still discloses the public address a STUN server sees.
There is no user setting; the behaviour is what it is.
Mobile
The same engines behave the same way. On iOS every browser uses WebKit, so
Safari's behaviour applies broadly. On Android, Chrome has no setting and
Firefox retains about:config on some builds.
Mobile is also where the exposure is least significant, because the address is usually a carrier-NAT address shared with many subscribers.
What actually to do
- Test first with the WebRTC leak test.
- If a public address that is not the VPN's appears, fix it.
- On Firefox, use the preference. Elsewhere, use an extension — the Firefox extension and its Chromium counterpart both constrain the API alongside proxying the browser.
- Retest. Do not assume an extension worked because it is installed.
Keep it in proportion
WebRTC is worth closing and it is not the largest hole in most people's setup. It discloses an address to a page that specifically looks for it. Cookies, accounts and browser fingerprinting identify people far more reliably and far more often, and none of those are affected by any of the settings above.
Why the API is built this way
It is worth knowing that this is not a bug anyone forgot to fix. Connecting two browsers directly, through two different home routers, requires both ends to discover and exchange every address they might be reachable on. That process is called ICE, and enumerating candidates is the entire mechanism.
The IETF documented the privacy problem explicitly in RFC 8828 and specified modes browsers should offer, including one that gathers only the default route's address. The mDNS replacement of local addresses came out of the same work. So the exposure has been narrowed deliberately over several years rather than left alone — what remains is the public address, which is the part a peer connection genuinely cannot work without.
The one case where it really matters
Someone using a VPN to appear in a different country, on a site that checks. The site reads the WebRTC-reported address, compares it with the connection address, and sees a mismatch that no amount of tunnel configuration explains.
For everyone else the practical exposure is one more identifier handed to a page that was already collecting a dozen.
