Most developers know about IP addresses, but WebRTC introduces a subtler privacy problem: your local network IP address can leak even when you're using a VPN.
This isn't just a theoretical concern — it's one of the fingerprinting vectors that makes multi-account detection possible.
The WebRTC IP Leak Problem
WebRTC (Web Real-Time Communication) was designed for peer-to-peer connections like video calls. To establish these connections, browsers need to discover local network interfaces.
The problem: browsers expose this information through JavaScript APIs, and it happens even when you're behind a VPN.
Basic Detection Code
// This reveals local IPs even behind a VPN
async function getLocalIPs() {
const ips = [];
const pc = new RTCPeerConnection({
iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
});
pc.createDataChannel('');
await pc.createOffer().then(offer => pc.setLocalDescription(offer));
return new Promise(resolve => {
pc.onicecandidate = event => {
if (!event.candidate) {
resolve(ips);
return;
}
const ip = event.candidate.candidate.match(
/([0-9]{1,3}(.[0-9]{1,3}){3}|[a-f0-9]{1,4}(:[a-f0-9]{1,4}){7})/
);
if (ip && !ips.includes(ip[0])) {
ips.push(ip[0]);
}
};
});
}
getLocalIPs().then(ips => console.log('Local IPs:', ips));
What This Reveals
Running this code typically exposes:
-
192.168.x.x— your router's local subnet -
10.x.x.x— VPN tunnel interface (if active) -
172.16.x.x— Docker or VM network interfaces - IPv6 addresses that may include a hardware-derived component
Why This Matters for Fingerprinting
The local IP address creates a stable, session-persistent identifier:
- Your home router assigns you the same local IP every time (DHCP lease)
- This persists across browser restarts and private browsing
- VPNs don't mask local IPs — they add another interface
For multi-account detection systems, local IPs are particularly useful because:
- They correlate accounts even when external IPs differ (VPN rotation)
- They're harder for users to rotate than external IPs
- They reveal network topology (home vs. office vs. server)
The Fingerprinting Combination
WebRTC leaks become most powerful when combined with other signals:
External IP: 45.123.x.x (VPN exit node - changes)
Local IP: 192.168.1.105 (home router - STABLE)
Canvas hash: a7f3c2... (GPU - STABLE)
Font list: [fonts unique to this machine] (STABLE)
The local IP + Canvas hash combination creates a highly stable device fingerprint that persists even through VPN rotation.
Testing Your WebRTC Exposure
Check these tools:
- BrowserLeaks.com/webrtc — shows all exposed IPs
- IPLeak.net — WebRTC section
- DevTools > Console — run the code above yourself
Mitigation Options
Browser-Level Controls
Firefox has a hidden setting:
about:config → media.peerconnection.enabled → false
Chrome has no built-in block, but some extensions attempt to intercept WebRTC API calls.
The Limitation of Extensions
Most WebRTC-blocking extensions work by intercepting JavaScript calls. This approach has two problems:
- Detectable: The absence of WebRTC functionality (or its consistent blocking pattern) is itself a fingerprint signal
- Incomplete: Some WebRTC paths bypass JavaScript-level interception
Profile-Level Isolation
The most robust approach is ensuring each browser profile has a different local IP exposure. This requires either:
- Running each profile in a separate network namespace (complex)
- Using a browser that randomizes or controls WebRTC responses at the engine level
Conclusion
WebRTC fingerprinting is one of those vulnerabilities that's easy to miss because it operates below the "obvious" tracking layer (cookies, external IP). Understanding it is essential for anyone building privacy-conscious applications or managing multiple browser-based accounts.
The key insight: a VPN changes your visible IP address, but it doesn't change your local network fingerprint.
At FireKey, we handle WebRTC fingerprint isolation at the browser engine level — each profile gets a controlled local IP response that doesn't leak your real network topology. Free open beta.
Top comments (0)