What Is a WebRTC Leak? Test, Mechanics, Detection & Prevention

A WebRTC IP exposure (or WebRTC leak) occurs when a browser’s Interactive Connectivity Establishment (ICE) stack gathers network candidates or performs connectivity checks that reveal an IP address or network path outside the user’s intended proxy, VPN, or privacy boundary. While standard HTTP page requests follow configured application proxies, native WebRTC implementations can open separate network sockets to discover direct transport paths.

WebRTC is not an inherent browser vulnerability; it is a W3C/IETF standard designed for real-time peer-to-peer audio, video, and data communication. Privacy exposures arise when a browser’s native ICE agent creates direct UDP sockets on uncaptured network interfaces, disclosing private local topology or public ISP-facing addresses to STUN servers and web applications.

1. How WebRTC ICE Candidate Gathering Works

Establishing a real-time WebRTC connection requires discovering valid network endpoints through Interactive Connectivity Establishment (ICE). The execution workflow consists of distinct operational steps:

1. PeerConnection Creation: A web application instantiates an RTCPeerConnection object, optionally passing an RTCConfiguration object containing STUN or TURN servers. By specification, the default iceServers list is empty.
2. Candidate Gathering: The browser’s native ICE agent enumerates available network interfaces and protocol handlers to gather potential endpoints called candidates.
3. STUN Transactions: If the application configures a STUN server, the browser sends STUN Binding requests to learn the public-facing transport address and port allocated by NAT devices.
4. TURN Relays: If a TURN server is configured, the browser allocates a relay endpoint to proxy media traffic when direct peer connections fail.
5. Signaling & Connectivity Checks: Discovered candidates are exposed to JavaScript, exchanged via application signaling, and validated through ICE connectivity checks.

WebRTC Candidate Types

Different candidate types represent distinct network layers and carry different privacy implications:

Technical Correction on Default STUN Servers: The Chromium browser engine does not have a universal, hardcoded default STUN server (such as stun.l.google.com). Per the W3C WebRTC specification, the default iceServers list is empty. STUN endpoints are explicitly supplied by the web application initiating the connection.

2. Why Application Proxies May Fail to Capture WebRTC Traffic

Most browser proxy extensions and settings operate at the application layer, directing HTTP, HTTPS, and WebSocket traffic through specified proxy targets. However, native WebRTC components operate within the browser’s lower-level networking stack, which may create direct UDP sockets independently of the tab’s proxy rules.

Application Proxies vs. Full-Tunnel VPNs

• Browser Application Proxies: HTTP and HTTPS proxies generally do not support arbitrary UDP datagram forwarding. When a browser uses an HTTP proxy but direct internet access remains available on the host machine, WebRTC ICE checks can open direct UDP sockets outside the proxy, causing STUN requests to leak the real ISP public address.
• SOCKS5 Proxies: While the SOCKS5 protocol defines UDP forwarding via UDP ASSOCIATE (RFC 1928), many commercial proxy providers and browser implementations do not support or utilize UDP association. When UDP proxying is unavailable, WebRTC must be configured to prohibit non-proxied UDP and fall back to TCP/TLS relays.
• Full-Tunnel VPNs: Unlike application proxies, a properly configured full-tunnel VPN installs operating-system network routes or virtual adapters that capture all system IP traffic. WebRTC sockets that follow system routing tables naturally pass through the VPN tunnel. Leaks occur primarily under split-tunneling, multi-interface gathering, IPv4/IPv6 route discrepancies, or kill-switch failures.

Browser Extension Capabilities

While standard extensions cannot intercept raw native UDP datagrams like HTTP requests, Chrome provides enterprise and extension APIs through chrome.privacy.IPHandlingPolicy. Policies such as disable_non_proxied_udp or default_public_interface_only allow extensions to restrict WebRTC socket creation without acting as packet-level UDP proxies.

3. Modern mDNS Address Obfuscation

To prevent web scripts from harvesting local private IP addresses (e.g., 192.168.1.50), modern Chromium and Firefox builds implement Multicast DNS (mDNS) host candidate obfuscation.

• How It Works: Instead of inserting a numerical private IP into a host candidate, the browser generates a temporary UUID hostname ending in .local (e.g., a4b8c2d1-3f4a.local). The numerical address is never exposed to JavaScript.
• What It Protects: mDNS protects local network topology by hiding numerical private host candidates.
• What It Does NOT Protect: mDNS does not obfuscate public server-reflexive candidates learned through STUN. If a STUN request leaves over an uncaptured network path, the resulting public IP address remains exposed to the web application.

4. Disabling, Obfuscating, and Controlling WebRTC

Managing WebRTC privacy risks requires choosing an approach that balances identity security with web application compatibility:

Engineering Note on Candidate Substitution: Simply rewriting candidate text strings in JavaScript or SDP offers incomplete protection. The endpoint advertised in an ICE candidate must correspond to an actual, reachable network socket capable of completing ICE connectivity checks and routing media. Effective prevention requires managing both candidate text and underlying socket transport.

5. WebRTC Management in Gologin Architecture

Gologin’s modified browser engine (Orbita) controls WebRTC at the native C++ networking layer rather than relying on extension-level overrides. This ensures that candidate generation, SDP data, getStats() telemetry, and media sockets remain mutually consistent.

• Off Mode: Disables the WebRTC API entirely for profiles that do not require audio/video communications.
• Altered / Controlled Mode: Governs native socket creation to ensure WebRTC traffic aligns with the profile’s assigned proxy boundary. When proxying over protocols that do not carry UDP, Orbita restricts non-proxied sockets and utilizes supported TCP/TLS fallback or TURN relays to maintain connectivity without direct exposure.
• Real Mode: Passes through local system WebRTC behavior, intended for profiles running on matching hardware and unproxied networks.

FAQ: WebRTC Leaks & Testing

1. What is the difference between a WebRTC leak and a DNS leak?

A DNS leak involves domain name resolution bypassing a proxy/VPN to query an unintended DNS resolver. A WebRTC leak occurs when WebRTC ICE candidate gathering opens direct sockets to STUN/TURN servers, revealing a public IP address or local network interface. They involve completely different protocols and socket layers.

2. Does a VPN prevent WebRTC leaks?

A properly configured full-tunnel VPN generally routes all system socket traffic—including WebRTC UDP—through the encrypted tunnel. WebRTC leaks on VPNs usually stem from split-tunneling configurations, multi-interface enumeration, IPv6 routing gaps, or browser-specific interface selection policies.

3. How do I interpret WebRTC leak test results?

When using public leak-testing tools like BrowserLeaks (browserleaks.com/webrtc) or CreepJS:

• If the Public / Server-Reflexive (srflx) row displays your assigned proxy/VPN IP, your connection is properly protected.
• If the Public / Server-Reflexive row displays your real ISP IP address, a WebRTC leak is occurring.
• If the Local / Host row displays a .local hostname, mDNS obfuscation is active.