WebRTC-lekken
WebRTC-lektest: wat een browsergesprek over je IP-adres verraadt
Onderdeel van: Is VoIP veilig? Wat een browsergesprek beschermt en wat het blootgeeft
In het kort
Een WebRTC-lektest toont elk IP-adres dat je browser via WebRTC aan een webpagina geeft, zodat je er een ziet die je wilde verbergen, meestal het adres van je internetprovider terwijl er een VPN aanstaat [1]. Bij een browsergesprek naar een telefoonnummer ziet de beldienst je IP-adres, niet degene die je belt; die krijgt een nummerweergave [2]. De test is een van de controles op privacy en veiligheid die ik aanraad voordat je via de browser belt.
Belangrijkste feiten
- Volgens de WebRTC-regels van de IETF kan WebRTC bij een VPN met split tunneling naast het adres van de VPN ook het publieke adres van je internetprovider ontdekken [1]. Gecontroleerd op .
- Bij mijn lokale controle in Chrome 156 zag een pagina zonder toestemming voor de microfoon mijn computer alleen als een willekeurige .local-naam; met toegestane microfoon kreeg ze mijn echte lokale adres [3][1]. Gecontroleerd op .
- Messenger zegt dat 1-op-1-gesprekken je IP-adres delen met het apparaat van de ander [4]; de WhatsApp-instelling IP-adres beschermen in gesprekken stuurt gesprekken in plaats daarvan via de eigen servers [5]. Gecontroleerd op .
Wat is een WebRTC-lek?
Vóór een WebRTC-gesprek verzamelt de browser mogelijke netwerkroutes, ICE-kandidaten genoemd, en geeft die aan de webpagina om door te sturen naar de andere kant. Elke kandidaat bevat een IP-adres, of een willekeurige .local-naam in plaats van een verborgen lokaal adres. Een gewone website ziet alleen het publieke adres waar je verzoek vandaan kwam; via WebRTC kan een pagina meer te weten komen [1]. Een lek is elk adres in die lijst dat je niet wilde delen.
Hoe de rest van een gesprek reist, lees je in WebRTC, SIP en het telefoonnet; voor lekken telt alleen de lijst met kandidaten. MDN merkt op dat de adressen daarin altijd zichtbaar zijn voor de pagina [6].
| Type kandidaat | Adres dat het toont | Privacyrisico |
|---|---|---|
| host | Het adres van je apparaat op het lokale netwerk, of een willekeurige naam op .local als de browser het verbergt [7][3] | Lager dan bij een publiek adres, maar de IETF noemt privé-IPv4-adressen een vrij belangrijk aanknopingspunt voor fingerprinting [1] |
| srflx (server reflexive) | Het publieke adres dat je router of VPN aan een STUN-server laat zien [7] | Hoog als het het adres van je provider is terwijl er een VPN aanstaat [1] |
| relay | Een adres op een TURN-server die de audio en video doorstuurt [7] | Laag: de andere kant ziet het adres van de relay, niet het jouwe [6]; de beheerder van de relay ziet jou nog wel |
De IETF noemt het VPN-geval het belangrijkste, omdat sommige mensen een VPN gebruiken om anoniem te blijven [1]. De andere twee gevallen zijn je privéadres en een proxy die de controles van WebRTC omzeilen, waardoor je echte publieke adres zichtbaar wordt [1].
Geeft een browsergesprek je IP-adres prijs?
Aan de beldienst wel: elke website ziet je publieke adres [1], en een gesprek voegt daar een mediaverbinding met de servers van de dienst aan toe. Aan iemand die je op een vaste of mobiele lijn belt niet: het gesprek verlaat het internet bij de gateway van de aanbieder [8], en het telefoonnet geeft het nummer van de beller door, geen IP-adres [2]. Gesprekken van app naar app kunnen twee apparaten rechtstreeks met elkaar verbinden.
| Soort gesprek | De dienst | Degene die je belt |
|---|---|---|
| Browser naar een telefoonnummer (Google Voice, TwinPhone, Yolla) | Ja: de dienst verzorgt de mediaverbinding | Nee: die ziet een nummerweergave [2] |
| Gratis webbellers (Call2Friends, Globfone) | Ja: Call2Friends beperkt gratis gesprekken per IP-adres, en het privacybeleid van Globfone noemt IP-adressen bij de technische gegevens en logs die het verwerkt [9][10] | Nee: die ziet een nummerweergave |
| Messenger, 1-op-1-gesprek | Ja | Ja: Meta zegt dat je IP wordt gedeeld met het andere apparaat [4] |
| Ja | Kan, tenzij IP-adres beschermen in gesprekken aanstaat; groepsgesprekken lopen altijd via een relay [5] | |
| Telegram | Ja | Kan: volgens de aankondiging van Telegram uit 2017 gaan gesprekken waar mogelijk peer-to-peer [11] |
Bij gesprekken naar echte nummers gaat het erom wat de dienst te weten komt en bewaart; wat degene die je belt wél ziet, staat in welk nummer verschijnt als je via de browser belt.
Zo doe je een WebRTC-lektest
Een lektestpagina doet wat een webbeller vóór een gesprek doet: ze opent een WebRTC-verbinding, vraagt een STUN-server welk publiek adres die ziet, en toont elke kandidaat naast het adres dat de pagina via gewoon HTTP ziet. Doe de test in elke browser waarmee je belt, eerst met je VPN uit en daarna met je VPN aan.
- VPN uit: open een lektestpagina, zoals de WebRTC Leak Test van BrowserLeaks. “Your Remote IP” bovenaan en “Public IP Address” onder “Your WebRTC IP” horen overeen te komen.
- VPN aan: laad de pagina opnieuw. “Your Remote IP” hoort nu het adres van de VPN te tonen.
- Staat het adres van je provider nog in het WebRTC-gedeelte, dan gaat WebRTC om de tunnel heen [1].
- Een lokale vermelding die op .local eindigt, betekent dat het adres verborgen is [3]; een kaal adres dat begint met 192.168. of 10. is dat niet.
- Biedt de pagina een microfoontest aan, sta die dan toe en test opnieuw: een webbeller heeft toegang tot de microfoon nodig, en die toestemming kan meer adressen vrijgeven [1]. Trek de toestemming daarna weer in via de site-instellingen [12].
Wat er in Chrome veranderde toen de microfoon was toegestaan
Op laadde ik een lokale testpagina in Chrome 156 op een Mac, zonder STUN-server, zodat er geen adres naar een externe server ging. Zonder toestemming voor de microfoon zag de pagina één host-kandidaat met een willekeurige naam die op .local eindigde [3]. Met toegestane microfoon kreeg ze mijn echte lokale IPv4-adres.
Dat volgt de standaard, die de volledige adreslijst alleen met toestemming vrijgeeft, zoals toestemming voor de microfoon [1]; WebKit, de engine van Safari, beschreef in 2017 dezelfde regel [13]. Een webbeller die je toestemming geeft, kan dus je lokale adres zien: een kleiner risico dan je publieke adres [1].
Browserinstellingen die WebRTC-lekken beperken
Brave documenteert een WebRTC-IP-instelling voor gebruikers. Google documenteert de instellingen van Chrome voor extensies en beheerders, en Microsoft die van Edge als beheerdersbeleid. Firefox verbergt lokale adressen standaard en heeft een uitschakelaar in about:config. Eén regel geldt overal: wie WebRTC uitzet, legt ook webbellers stil, want WebRTC draagt het gesprek [14].
| Browser | Instelling | Wat het verandert | Effect op browsergesprekken |
|---|---|---|---|
| Brave | WebRTC IP handling policy in de privacyinstellingen, volgens de wiki van Brave (laatst bewerkt in 2018) [15] | Default Public Interface Only geeft geen lokale adressen prijs [15] | Audio en video kunnen terugvallen op een relayserver [1] |
| Chrome | Extensies kunnen een WebRTC IP handling policy instellen [16]; beheerders kunnen het beleid WebRtcIPHandling instellen [17] | Afhankelijk van de waarde worden privéadressen niet meer gebruikt of gaan audio en video alleen via een proxy [17] | Waarden die alles via een proxy sturen, kunnen audio naar TCP verplaatsen, wat volgens de IETF de kwaliteit verlaagt [1] |
| Edge | Beheerdersbeleid WebRtcLocalhostIpHandling [18] | Twee van de waarden stoppen met het prijsgeven van het lokale IP-adres [18] | Zoals in Chrome |
| Firefox | Lokale adressen standaard verborgen [19]; media.peerconnection.enabled in about:config [20] | Zet je die voorkeur op false, dan gaat WebRTC uit | Webbellers werken niet meer |
| Safari | Ingebouwde regel | Pagina's zonder toegang tot microfoon of camera krijgen geen host-adressen, zoals WebKit het in 2017 beschreef [13] | Geen |
Wat een VPN verandert aan browsergesprekken
Een VPN die al het verkeer door de tunnel stuurt, WebRTC inbegrepen, laat de beldienst het adres van de VPN zien in plaats van het jouwe. Bij een VPN met split tunneling kan WebRTC ook het adres van je provider vinden [1], vandaar de lektest met de VPN aan. Een VPN heeft ook bijwerkingen voor bellen.
- Sommige diensten beperken VPN's: volgens de voorwaarden van TextNow mag het het gebruik ervan begrenzen of beperken [21].
- Sommige gratis webbellers rantsoeneren gratis gesprekken per IP-adres, zoals Call2Friends doet [9], dus via een VPN deel je dat tegoed misschien met andere gebruikers van hetzelfde uitgangsadres.
- Dwing je audio en video via een proxy die geen UDP aankan, dan verhuist de audio naar TCP, wat volgens de IETF de mediakwaliteit verlaagt [1].
- De dienst ziet nog steeds je account en je gespreksgegevens; Google bijvoorbeeld kan de nummers, het tijdstip en de duur van gesprekken vastleggen [22].
Zo houd je je IP-adres privé tijdens gesprekken
Kies de oplossing die bij het gesprek past. Bij gesprekken naar telefoonnummers krijgt degene die je belt je IP niet, dus kies een dienst die je het toevertrouwt en controleer je VPN. Bij gesprekken van app naar app kan het andere apparaat rechtstreeks met het jouwe verbinden, dus gebruik de relay-instelling van de app als die er is.
- Browsergesprekken: doe de lektest met de VPN aan; kies in Brave Default Public Interface Only [15].
- Microfoon: geef webbellers die je maar één keer gebruikt toestemming met “Deze keer toestaan” [12]; bij mijn controle in Chrome kon een pagina met die toestemming het lokale adres zien.
- WhatsApp: zet IP-adres beschermen in gesprekken aan. De hulppagina behandelt Android, iOS en Mac, niet het web, en waarschuwt dat gesprekken via een relay wat kwaliteit kunnen verliezen [5].
Veelgestelde vragen
Wat is een WebRTC-lektest?
Een WebRTC-lektest is een webpagina die de verbindingsopbouw van een browsergesprek uitvoert en elk IP-adres toont dat je browser aanbiedt, naast het adres dat de pagina via gewoon HTTP ziet. Staat het adres van je provider in die lijst terwijl er een VPN aanstaat, dan gaat WebRTC om de tunnel heen [1]; een willekeurige .local-naam betekent dat je lokale adres verborgen is [3].
Kan degene die ik via mijn browser bel mijn IP-adres zien?
Nee, niet bij een gesprek naar een vaste of mobiele lijn. De aanbieder zet de audio uit je browser bij de eigen gateway om in een telefoongesprek [23], en het telefoonnet geeft het nummer van de beller door, geen IP-adres [2]. Gesprekken van app naar app zijn anders: Messenger zegt dat 1-op-1-gesprekken je IP delen met het apparaat van de ander [4].
Houdt een VPN WebRTC-lekken tegen?
Een VPN die al het verkeer, WebRTC inbegrepen, door de tunnel stuurt wel. Een VPN met split tunneling misschien niet, omdat WebRTC naast het adres van de VPN ook het publieke adres van je provider kan ontdekken [1]. De enige manier om het zeker te weten is een lektest met de VPN verbonden, in elke browser die je gebruikt, en opnieuw na updates.
Is een lek van je lokale IP-adres gevaarlijk?
Minder dan een lek van je publieke adres. Een privéadres zoals 192.168.1.20 zegt niet waar je bent, maar de IETF noemt privé-IPv4-adressen een vrij belangrijk aanknopingspunt voor fingerprinting, waarmee normale en privésessies op één apparaat aan elkaar te koppelen zijn [1]. Firefox verbergt lokale adressen standaard [19], Safari verbergt ze voor pagina's zonder toegang tot microfoon of camera [13], en Chrome deed dat bij mijn controle ook.
Houdt incognito of privénavigatie WebRTC-lekken tegen?
Nee. De IETF merkt op dat een privéadres dat via WebRTC uitlekt kan werken als kenmerk dat een site vertelt dat een normaal venster en een privévenster op hetzelfde apparaat draaien [1], dus de privémodus alleen verbergt het niet. Gebruik de browserinstellingen hierboven en doe daarna ook een lektest in een privévenster.
Werken extensies tegen WebRTC-lekken?
Deels. In Chrome kan een extensie de WebRTC IP handling policy van de browser instellen, wat Google omschrijft als een afweging tussen mediaprestaties en hoeveel informatie over lokale adressen zichtbaar wordt [16]. Afhankelijk van de waarde verbergt dat lokale adressen of dwingt het audio en video via een proxy, waardoor de audio naar TCP kan verhuizen en de kwaliteit kan dalen [1]. Doe na het installeren een lektest om de verandering te bevestigen.
Hoe zet ik WebRTC uit in Firefox?
Typ about:config in de adresbalk, zoek naar media.peerconnection.enabled en zet die op false. De broncode van Mozilla beschrijft die voorkeur als de schakelaar voor RTCPeerConnection, en uitzetten ontneemt pagina's ook de toegang tot de microfoon-API [20]. Daarna werkt geen enkele webbeller meer, dus de meeste bellers zijn beter af met de standaardinstelling van Firefox, die lokale adressen al verbergt [19].
Hoe voorkom ik WebRTC-lekken in Chrome?
Via een extensie of een beleidsregel, want voor die twee documenteert Google de adresinstellingen van WebRTC in Chrome. Een extensie kan het IP-beleid van WebRTC instellen [16], en beheerders kunnen WebRtcIPHandling instellen, waarvan de waarde default_public_interface_only voorkomt dat WebRTC privéadressen gebruikt [17]. Bij mijn controle in Chrome zag een pagina zonder microfoontoestemming al alleen een willekeurige .local-naam [3]. Achter een vpn is de echte oplossing een tunnel die al het verkeer doorgeeft [1]. Alles wat WebRTC helemaal blokkeert, stopt ook browsergesprekken [14].
Kan een website zonder te vragen mijn IP-adres zien via WebRTC?
Je openbare adres wel, maar dat zien websites sowieso: Safari bijvoorbeeld geeft pagina's zonder microfoontoegang alleen adressen die een website al kon verzamelen [13]. Het addertje is een proxy in de browser. Als directe internettoegang is toegestaan, kunnen de STUN-controles van WebRTC de proxy omzeilen en je echte openbare adres prijsgeven [1]. Lokale adressen zijn beter beschermd: de standaard koppelt de volledige lijst aan toestemming zoals voor de microfoon [1], en bij mijn controle in Chrome zag een pagina zonder die toestemming alleen een willekeurige .local-naam [3].
Vraag AI naar dit onderzoek
Elke knop opent de assistent in een nieuw tabblad en vraagt hem deze pagina samen te vatten, met een link ernaar als bron.
Bronnen
- RFC 8828: WebRTC IP Address Handling Requirements · IETF (RFC Editor) · gecontroleerd op 1 november 2026
- 47 CFR 64.1601 -- Delivery requirements and privacy restrictions | eCFR · US Code of Federal Regulations (eCFR) · gecontroleerd op 1 november 2026
- Using Multicast DNS to protect privacy when exposing ICE candidates (draft-ietf-mmusic-mdns-ice-candidates) · IETF (Internet-Draft, work in progress) · gecontroleerd op 1 november 2026
- Voice call someone or a group on Messenger - Messenger Help Center (Computer) · gecontroleerd op 1 november 2026
- How to protect your IP address on WhatsApp calls | WhatsApp Help Center · WhatsApp · gecontroleerd op 1 november 2026
- RTCIceCandidate: address property - Web APIs | MDN · MDN Web Docs (Mozilla) · gecontroleerd op 1 november 2026
- RTCIceCandidate: type property - Web APIs | MDN · MDN Web Docs (Mozilla) · gecontroleerd op 1 november 2026
- Make calls | Sonetel help · gecontroleerd op 1 november 2026
- Free call | Call2Friends - Online call · gecontroleerd op 1 november 2026
- Privacy Policy | Globfone · gecontroleerd op 1 november 2026
- Voice Calls: Secure, Crystal-Clear, AI-Powered | Telegram Blog (30 March 2017) · Telegram · gecontroleerd op 1 november 2026
- Use your camera and microphone in Chrome - Computer - Google Chrome Help · Google · gecontroleerd op 1 november 2026
- A Closer Look Into WebRTC | WebKit (3 July 2017) · WebKit (Apple) · gecontroleerd op 1 november 2026
- WebRTC API - Web APIs | MDN · MDN Web Docs (Mozilla) · gecontroleerd op 1 november 2026
- WebRTC Custom Settings · brave/brave-browser Wiki · Brave Software (official GitHub wiki) · gecontroleerd op 1 november 2026
- chrome.privacy | API | Chrome for Developers · Google (Chrome for Developers) · gecontroleerd op 1 november 2026
- Chrome Enterprise policy list: WebRtcIPHandling (WebRTC IP handling) · Google (Chrome Enterprise) · gecontroleerd op 1 november 2026
- Microsoft Edge Browser Policy Documentation WebRtcLocalhostIpHandling | Microsoft Learn · Microsoft · gecontroleerd op 1 november 2026
- Firefox source: modules/libpref/init/all.js (mozilla-firefox/firefox) · Mozilla (official Firefox source repository) · gecontroleerd op 1 november 2026
- Firefox source: modules/libpref/init/StaticPrefList.yaml (mozilla-firefox/firefox) · Mozilla (official Firefox source repository) · gecontroleerd op 1 november 2026
- Terms of Use – TextNow · gecontroleerd op 1 november 2026
- Privacy Policy – Privacy & Terms – Google · Google · gecontroleerd op 1 november 2026
- Call From Your Browser Without a SIM Card - TwinPhone · gecontroleerd op 1 november 2026