WebRTC IP Leak Protection in Modern Browsers

WebRTC (Web Real-Time Communication) enables seamless peer-to-peer voice, video, and data sharing directly within web browsers. However, its default connection mechanism historically introduced a major privacy vulnerability by exposing users’ local and public IP addresses to websites without their consent. Modern web browsers have successfully mitigated this security flaw through a combination of Multicast DNS (mDNS) anonymization, strict routing policies, and user permission requirements.

The Vulnerability: Why WebRTC Exposed IP Addresses

To establish a direct connection between two browsers, WebRTC uses the Interactive Connectivity Establishment (ICE) protocol. This protocol gathers “ICE candidates,” which are potential network pathways—including local LAN IP addresses (e.g., 192.168.1.50) and public WAN IP addresses. Originally, any website could execute a simple JavaScript command to query these candidates, allowing malicious trackers to harvest local IPs and identify users even if they were using a VPN.

1. mDNS Anonymization of Local IPs

The primary defense mechanism implemented by modern browsers (including Google Chrome, Mozilla Firefox, Apple Safari, and Microsoft Edge) is Multicast DNS (mDNS) candidate masking.

Instead of exposing raw local IP addresses to the web page, the browser generates a dynamically created, cryptographically secure Universally Unique Identifier (UUID) ending in .local (for example, 3a5b6c7d-8e9f-0a1b-2c3d-4e5f6g7h8i9j.local). The browser registers this temporary hostname on the local network. When the WebRTC connection is initiated, the website only sees the UUID, while the browser resolves the connection locally. This prevents the website from mapping the user’s internal network topology.

2. Strict ICE Candidate Routing Policies

Browsers now restrict how and when public and private IP addresses are gathered. The World Wide Web Consortium (W3C) WebRTC security guidelines outline four main IP handling policies:

• Default Route Only: The browser only uses the default routing path (the network interface used for normal web traffic). This prevents the browser from scanning secondary network interfaces to find hidden IP addresses.
• Default Route and Public IPs: Only the default route and public-facing IP addresses are shared.
• Default Route and Authorized Private IPs: Private IPs are only shared if the user has explicitly authorized access (e.g., by granting microphone or camera permissions).
• All Interfaces (Legacy): Exposes all interfaces; this is largely deprecated or restricted in modern browsers.

By defaulting to restrictive policies, browsers ensure that a user’s local network remains hidden during standard web browsing.

3. Respecting VPN and Proxy Settings

Historically, WebRTC could bypass system-level VPNs by directly querying the hardware network adapters. Modern browsers have patched this routing leak. WebRTC connections are now strictly bound to the active proxy or VPN tunnel configured in the browser or operating system. If a VPN is active, WebRTC traffic travels through the encrypted tunnel, ensuring that only the VPN’s public IP address is exposed to the peer, rather than the user’s real ISP-assigned IP.

4. Permission-Gated Gathering

Modern browsers treat WebRTC access as a privileged action. Websites cannot aggressively harvest WebRTC connection candidates unless the user has actively interacted with a media prompt. For example, local IP gathering is completely blocked until the user grants permission to use their camera or microphone. This prevents background tracking scripts on arbitrary websites from abusing WebRTC.