Skip to content
Glossary

WebRTC leak

A WebRTC leak is the disclosure of a network address by the browser's real-time communication stack.

A WebRTC leak is the disclosure of a network address by the browser’s real-time communication stack, which gathers candidate addresses on its own rather than through the HTTP path your proxy controls. The page never has to establish a call; gathering the candidates is enough to reveal them to JavaScript.

#Why the proxy does not catch it

Candidate gathering uses UDP, and RFC 8828 states plainly that HTTP proxies and most SOCKS proxies do not carry UDP. A browser configured with an HTTP proxy can therefore send media and connectivity checks by a route that never touches it, unless the implementation forces the traffic through the proxy or disables UDP.

#The four defined behaviours

RFC 8828 names four modes, which is the clearest way to describe what a given browser is doing.

Mode What is exposed
1 — enumerate all addresses Every interface. Requires user consent
2 — default route plus local addresses The default route, plus private addresses on that interface
3 — default route only Only addresses discovered by STUN or TURN on the default route
4 — force proxy Media follows the proxy; UDP is disabled if the proxy cannot carry it

The document recommends mode 2 where consent has not been given. Which mode a particular browser build applies, and under which flags, is a question for that build — test it rather than assume it.

#Checking your own exposure

Enumerate the candidates the way a page would, then compare the addresses against the address your exit node presents over HTTP. Any candidate that is neither the exit address nor an obfuscated hostname is visible to any page that asks.

If you drive a headless browser, treat this as part of the harness rather than a one-off check, because a browser update can change the behaviour without changing anything you wrote.

#Commonly confused with

A DNS leak discloses the hostname you are visiting to a resolver operator. A WebRTC leak discloses your addresses to the page. Different layer, different audience, different test — and fixing one does nothing for the other.

Frequently asked questions

Can a website read my real address through WebRTC without asking permission?
It can ask the stack to gather candidates, which happens without a media-device prompt. What that yields depends on the browser's address-handling mode. RFC 8828 requires consent before all interfaces are enumerated, and recommends a restricted default, but the details vary by build and must be tested.
Does routing my browser through a proxy stop WebRTC leaks?
Not reliably. RFC 8828 notes that HTTP proxies and most SOCKS proxies cannot carry UDP, so connectivity checks may bypass the proxy entirely unless the browser is set to force media through it or to disable UDP when it cannot.
Is disabling WebRTC the right fix?
It removes the leak and also removes any real-time functionality the target site uses. A site that expects the API to exist can notice its absence, which is itself a signal. Restricting address handling to a stricter mode is usually the better trade than deleting the interface.

Sources

  1. RFC 8828: WebRTC IP address handling requirements, the four modes
  2. W3C WebRTC: the browser API that gathers and exposes candidates

Related terms