WebRTC IP Leak Prevention: Protect Your Real IP Address

Introduction

WebRTC (Web Real-Time Communication) enables peer-to-peer connections for video calls, file sharing, and real-time data transfer. To establish these connections, WebRTC uses the ICE (Interactive Connectivity Establishment) protocol, which discovers all available network paths, including your real IP address.

This means that even when browsing through a proxy or VPN, a website can use WebRTC to discover your actual IP address. For browser automation, this is a critical leak vector.

How WebRTC Leaks Happen

When a website creates an RTCPeerConnection, the browser automatically begins gathering ICE candidates. These candidates represent possible network paths:

• Host candidates - Your local IP addresses (including private IPs like 192.168.x.x)
• Server-reflexive (srflx) candidates - Your public IP as seen by a STUN server
• Relay candidates - IP addresses of TURN relay servers

const pc = new RTCPeerConnection({
  iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
});

pc.createDataChannel('');
pc.createOffer().then(offer => pc.setLocalDescription(offer));

pc.onicecandidate = (event) => {
  if (event.candidate) {
    // This reveals the user's real IP, bypassing any proxy
    console.log(event.candidate.candidate);
  }
};

The server-reflexive candidate contains your real public IP address, gathered through a STUN request that travels outside the proxy tunnel.

Why This Is Dangerous

WebRTC leaks are particularly dangerous because:

• They bypass proxies - STUN requests use UDP, which many proxy configurations do not tunnel
• They are silent - No user prompt or permission is required
• They reveal local network topology - Private IP addresses expose your network setup
• They are widely tested - Major detection systems check for WebRTC/proxy IP mismatches

Detection in Practice

Detection systems compare the IP address from the HTTP connection with the IP discovered through WebRTC. If they differ, it is a strong signal that the user is using a proxy, which alone may trigger additional scrutiny or blocking.

How BotCloud Prevents WebRTC Leaks

BotCloud configures WebRTC at the engine level to prevent IP leaks:

• ICE candidate filtering - Host and server-reflexive candidates that would reveal your real IP are controlled
• STUN request routing - When using a proxy, STUN requests are routed through the proxy tunnel
• Consistent IP presentation - The IP address visible through WebRTC matches the proxy IP
• No disabled APIs - WebRTC remains fully functional for sites that require it, but without leaking

This is different from simply disabling WebRTC (which is detectable) or blocking ICE candidates (which breaks WebRTC-dependent functionality). BotCloud maintains full WebRTC capability while ensuring IP consistency.

Verification

Test WebRTC leak prevention:

const page = await browser.newPage();
await page.goto('https://browserleaks.com/webrtc');
// All displayed IPs should match the proxy IP, not your real IP

Best Practices

1. Always verify WebRTC behavior when using proxies - A proxy without WebRTC leak prevention provides incomplete protection
2. Use SOCKS5H proxies to ensure UDP traffic is also tunneled
3. Test with multiple leak detection tools - browserleaks.com/webrtc, ipleak.net
4. Check both IPv4 and IPv6 - WebRTC can leak IPv6 addresses even when IPv4 is properly proxied