Thème

Outils populaires

Test de fuite WebRTC

WebRTC peut donner à un site des adresses que votre navigateur n'enverrait pas autrement — y compris celle qui se trouve derrière votre VPN. Ce test interroge trois serveurs STUN gérés par Cloudflare et Google, montre chaque adresse revenue et ce qu'elle est, et les compare à l'adresse qu'un site voit déjà. Quand il ne peut pas tester quelque chose, il le dit au lieu de vous montrer une coche verte.

Exécuté dans votre navigateur avec les serveurs STUN de Cloudflare et Google · rien n'est conservé · types de candidats selon la RFC 8445

Lancez-le une fois avec votre VPN désactivé et une fois avec votre VPN activé. La différence est la réponse.

Votre navigateur demande à trois serveurs STUN, gérés par Cloudflare et Google, quelle adresse ils voient. Aucune adresse trouvée par WebRTC ne nous est envoyée.

Ce qu'un site voit de toute façonIPv4IPv6Recherche de votre connexion…
Toutes les adresses produites par WebRTC

  1. Chaque adresse produite par WebRTC apparaît ici, une ligne par adresse, à mesure que les serveurs STUN répondent.

Aucune adresse trouvée par WebRTC ne nous est envoyée. Votre navigateur interroge lui-même les serveurs STUN, comme le fait tout appel vidéo. Pour montrer ce qu'un site voit, la page demande vos adresses et leurs réseaux à ipify.org et à notre propre serveur, comme le fait le test de fuite DNS.

Qu'est-ce qu'une fuite WebRTC ?

WebRTC est la fonction du navigateur qui fait marcher les appels vidéo. Pour relier directement deux personnes, elle rassemble toutes les adresses auxquelles votre machine peut être jointe et les propose à la page — y compris des adresses que votre navigateur n'enverrait jamais dans une requête ordinaire.

Cette collecte des candidats ICE est définie dans la RFC 8445. Votre navigateur liste les adresses de vos propres interfaces réseau, puis demande à un serveur STUN « de quelle adresse me voyez-vous arriver ? » et ajoute celle-là aussi. N'importe quelle page sur Internet peut lancer cela avec quelques lignes de JavaScript et lire chaque candidat à son arrivée, sans aucune demande d'autorisation — c'est voulu, car un appel doit fonctionner sans.

Elle devient une fuite quand l'une de ces adresses est quelque chose que vous cachiez. Un VPN change la route que prennent les requêtes de votre navigateur, mais WebRTC peut interroger le système d'exploitation sur toutes les interfaces : sur une machine dont la connexion physique est toujours active, la vraie adresse peut donc apparaître à côté de celle du VPN. Rien ne s'est mal passé : la fonction fait exactement ce pour quoi elle a été conçue.

Ce que n'importe quelle page peut lancerune collecte, étape par étape

VOTRE APPAREILINTERNETVotre routeur (NAT)Le script de la pageVotre navigateurServeur STUNstun.cloudflare.comnew RTCPeerConnection()aucune demande d'autorisationliste chaque interface réseau192.168.1.20 → 8b7f4e2a-….localde quelle adresse me voyez-vous arriver ?192.168.1.20:54400203.0.113.7:54400203.0.113.7:54400l'adresse qu'il a vuechaque candidat, à son arrivéeonicecandidateVOTRE APPAREILINTERNETLe script de la pageVotre navigateurServeur STUNnew RTCPeerConnection()aucune demande d'autorisationliste chaque interface réseau192.168.1.20 → 8b7f4e2a-….localde quelle adresse me voyez-vous arriver ?192.168.1.20203.0.113.7203.0.113.7:54400l'adresse qu'il a vuechaque candidat, à son arrivéeonicecandidateVotre routeur (NAT)

Le script complet

const pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.cloudflare.com:3478" }],
});
pc.createDataChannel("");
pc.onicecandidate = (e) => e.candidate && console.log(e.candidate.candidate);
await pc.setLocalDescription(await pc.createOffer());

Ce qu'il a affiché

candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0candidate:1467250027 1 udp 1686052607 203.0.113.7 54400 typ srflx raddr 0.0.0.0 rport 9 generation 0

Ce qu'est chaque ligne

  • hostSur cette machine8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.localMasquée par votre navigateur
  • srflxVue par un serveur STUN203.0.113.7Routable sur Internet
Une collecte sur une connexion domestique, avec des adresses de documentation. L'adresse privée ne quitte jamais le navigateur telle quelle ; le serveur STUN voit le côté public du routeur, pas la machine, et les deux réponses vont au script qui les a demandées.
Résultat du test de fuite WebRTC : chaque candidat ICE avec son type, la nature de chaque adresse et le verdictRésultat du test de fuite WebRTC : chaque candidat ICE avec son type, la nature de chaque adresse et le verdictLe verdictFuite, Aucune fuite ou — en toute honnêteté — Non testé, avec la raison.Chaque adresseAvec son type de candidat, car un candidat hôte ne signifie pas la même chose qu'un candidat réflexif.Ce qu'elle estPrivée, NAT opérateur, un tunnel ou routable. Seule une adresse routable peut être une fuite.Les serveursChaque serveur STUN sur sa propre ligne. Un serveur qui n'a rien dit, c'est un test qui n'a pas eu lieu.Ce qu'un site voitLes adresses que votre navigateur envoie de toute façon, auxquelles les adresses WebRTC sont comparées.
Un test : ce que chaque serveur STUN a répondu, chaque adresse exposée par WebRTC, de quel type d'adresse il s'agit et si c'est une adresse que le site voit déjà. Sélectionnez un numéro pour voir ce que montre chaque partie.

Comment vérifier s'il y a une fuite WebRTC

Lancez le test ci-dessus. Il collecte des candidats auprès de trois serveurs STUN, détermine ce qu'est chaque adresse et compare les adresses routables à celle qu'un site voit déjà.

Trois résultats sont possibles, et non deux. Aucune fuite signifie que chaque adresse routable produite par WebRTC est une adresse que le site a déjà. Fuite signifie qu'au moins une ne l'est pas — ou qu'une adresse de votre propre machine a été offerte directement. Non testé signifie que WebRTC est désactivé ou bloqué, ou qu'aucun serveur STUN n'a répondu, et c'est le résultat que la plupart des outils transforment discrètement en réussite.

Faites-le deux fois si vous utilisez un VPN : une fois désactivé pour voir vos adresses ordinaires, une fois activé. C'est le second passage qui compte, et la différence entre les deux est la réponse. La page garde le premier résultat pour que vous puissiez comparer sans rien noter.

Trois résultats, pas deuxce que chacun signifie

  1. Aucune fuite

    Chaque adresse routable produite par WebRTC est une adresse qu'un site a déjà.

    WebRTC a donné

    • 198.51.100.23Vue par un serveur STUNDéjà vue par les sites
    • 8b7f4e2a-….localSur cette machineMasquée par votre navigateur

    Un site voit

    198.51.100.23
  2. Fuite

    Au moins une adresse n'est pas de celles que le site a déjà, ou une adresse de votre propre machine a été offerte directement.

    WebRTC a donné

    • 198.51.100.23Vue par un serveur STUNDéjà vue par les sites
    • 2001:db8:4a1f:7c00::1cSur cette machineNon vue par les sites

    Un site voit

    198.51.100.23
  3. Non testé

    WebRTC est désactivé ou bloqué, ou aucun serveur STUN n'a répondu. Rien n'a été mesuré.

    stun.cloudflare.comPas de réponse

    stun.l.google.comPas de réponse

    Ce que la plupart des outils affichent iciAucune fuite

Faites-le deux fois

VPN désactivé

WebRTC a donné203.0.113.7

Un site voit203.0.113.7

Aucune fuite

VPN activé

WebRTC a donné198.51.100.23203.0.113.7

Un site voit198.51.100.23

Toujours là avec le VPN activé

Fuite
Chaque résultat avec un test qui le produit. VPN désactivé, l'adresse de WebRTC et celle du site sont les mêmes ; VPN activé, elles devraient changer toutes les deux, et celle qui reste est la réponse.

Un VPN empêche-t-il une fuite WebRTC ?

Pas à lui seul. Un VPN change la destination de votre trafic ; WebRTC peut demander à votre système d'exploitation quelles interfaces existent, et l'interface physique est généralement toujours là.

La description de l'IETF elle-même est précise : « si le client tente de masquer sa position physique au moyen d'un réseau privé virtuel (VPN), et que le VPN et le système d'exploitation local prennent en charge le routage sur plusieurs interfaces, WebRTC peut découvrir non seulement l'adresse publique du VPN, mais aussi l'adresse publique du FAI sur laquelle le VPN fonctionne ». Les deux adresses sont proposées, et une page qui les cherche peut lire les deux.

Certains clients VPN comblent la brèche en faisant passer tout le trafic au niveau du système d'exploitation, ou en fournissant une extension de navigateur qui restreint WebRTC. Les deux fonctionnent, et les deux sont à vérifier plutôt qu'à supposer — c'est à cela que sert cette page. Un VPN dont la propre page de test de fuite dit que vous êtes protégé n'est pas une preuve indépendante.

Un VPN activé, le Wi-Fi toujours actifdeux interfaces, deux réponses

Votre portableVPN10.64.0.2Wi-Fi192.168.1.20TUNNEL VPNServeur VPN198.51.100.23Site webvotre navigationServeur STUNRouteur (NAT)Votre FAI203.0.113.7WebRTC interroge par les deuxVotre portableVPN10.64.0.2Wi-Fi192.168.1.20TUNNEL VPNServeur VPN198.51.100.23Routeur (NAT)Votre FAI203.0.113.7votre navigationSite webServeur STUNWebRTC interroge par les deux

Ce que la page reçoit

  • 198.51.100.23srflxVue par un serveur STUNpar le VPNDéjà vue par les sites
  • 203.0.113.7srflxVue par un serveur STUNpar le Wi-Fi, hors du tunnelNon vue par les sites

RFC 8828

Ce qui comble la brèche

  • Le routage au niveau du systèmeRien ne sort hors du tunnel, donc un serveur STUN ne peut voir que l'adresse du VPN.
  • L'extension de navigateur du VPNElle restreint WebRTC dans le navigateur, si bien que l'autre interface n'est jamais interrogée.
  • Puis vérifiez, ne supposez pasLancez ce test avec le VPN activé. La page de test de fuite d'un VPN n'est pas une preuve indépendante.
Le cas que décrit l'IETF dans la RFC 8828 : le VPN et le système d'exploitation routent sur plus d'une interface, donc WebRTC trouve l'adresse publique du VPN et, en dessous, l'adresse du fournisseur.

Hôte, réflexif serveur et relais : quel candidat est lequel ?

Un candidat hôte est une adresse sur votre propre machine. Un candidat réflexif serveur est ce qu'un serveur STUN a vu — le côté public de votre NAT. Un candidat relais est l'adresse d'un serveur TURN, pas la vôtre.

La distinction compte, et la plupart des tests de fuite l'ignorent. Un candidat réflexif serveur portant votre IPv4 publique n'apprend généralement rien de neuf : c'est la même adresse que le site obtient par la connexion que vous établissez déjà. Un candidat hôte portant une adresse routable est autre chose — c'est une adresse sur la machine elle-même, offerte directement à la page. Elle identifie cette machine, pas seulement le routeur de votre foyer, et elle change quand le réseau change.

La page affiche le type à côté de chaque adresse, avec le transport, le port et l'adresse liée qu'indique un candidat réflexif. Un candidat relais est l'adresse propre du serveur TURN et ne révèle rien sur vous ; ce test n'utilise aucun serveur TURN, donc s'il en apparaît un, c'est que quelque chose d'autre sur la page l'a configuré.

Un candidat, champ par champtel qu'une page le reçoit

  1. candidate:1467250027Fondation
  2. 1Composant
  3. udpTransport
  4. 1686052607Priorité
  5. 203.0.113.7Adresse
  6. 54400Port
  7. typ srflxType
  8. raddr 0.0.0.0 rport 9Adresse liée
  9. generation 0Extension

Remplacée par 0.0.0.0, port 9, là où les adresses locales sont masquées

Les quatre types

  • typ hostSur cette machine

    Une adresse sur l'une de vos propres interfaces réseau.

    Une adresse privée est masquée. Une adresse routable, c'est l'appareil lui-même : le constat le plus grave.

    Le plus grave s'il est routable

  • typ srflxVue par un serveur STUN

    Le côté public de votre routeur, tel qu'un serveur STUN l'a vu.

    Généralement l'adresse qu'un site a déjà grâce à votre connexion.

    Rarement une nouvelle

  • typ prflxVue par l'autre côté

    Le côté public de votre routeur, tel que l'autre bout d'un appel l'a vu.

    Trouvé seulement pendant la connexion à l'autre côté, donc un test sans appel n'en voit jamais.

    Seulement pendant un appel

  • typ relayL'adresse propre d'un serveur relais

    L'adresse d'un serveur TURN, qui relaie le trafic pour vous.

    L'adresse du serveur, pas la vôtre. Ce test n'utilise aucun serveur TURN : s'il y en a un ici, c'est autre chose qui l'a configuré.

    Rien sur vous

L'adresse du candidat est comparée à ce qu'un site voit ; son type dit la gravité d'une différence. Définitions tirées de la RFC 8445, section 4.

Qu'est-ce qu'une adresse mDNS en .local, et me protège-t-elle ?

Les navigateurs modernes remplacent vos adresses privées par un nom aléatoire se terminant par .local avant de les proposer à une page. Cela fonctionne — pour les adresses privées. Cela n'a jamais été conçu pour cacher une adresse publique.

Chrome le fait par défaut depuis la version 76, et Firefox a media.peerconnection.ice.obfuscate_host_addresses réglé sur true : au lieu de 192.168.1.20, une page reçoit quelque chose comme 8b7f4e2a-….local, qui ne signifie rien pour personne en dehors de votre réseau. Safari va plus loin : tant qu'un site n'a pas l'autorisation d'utiliser la caméra ou le micro, il ne propose aucun candidat hôte. Le test ci-dessus reconnaît ces noms aléatoires et les présente comme la protection qui fonctionne, pas comme un constat.

L'Internet-Draft de l'IETF qui le définit est explicite sur ce qu'il ne fait pas : « une adresse déjà exposée à Internet n'a pas besoin d'être protégée par mDNS, car le serveur web peut l'observer trivialement ». Un candidat réflexif serveur porte donc toujours votre IPv4 publique et — c'est ce qui surprend — une machine dotée d'une adresse IPv6 routable peut toujours proposer cette adresse comme candidat hôte. Il reste une faille à connaître : Chrome désactive la protection pour tout site qui a déjà l'autorisation d'utiliser la caméra ou le micro, si bien qu'un site d'appel vidéo que vous avez déjà utilisé voit vos vraies adresses locales.

Ce que remplace le nom .localet ce qu'il laisse tel quel

Ce qu'a votre navigateur

candidate:3442447574 1 udp 2122260223 192.168.1.20 54400 typ host generation 0

Ce que la page reçoit

candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0

Ce que fait chaque navigateur par défaut

  • ChromeDepuis la version 76, août 2019
  • Firefoxmedia.peerconnection.ice.obfuscate_host_addresses = true
  • SafariAucun candidat hôte tant qu'un site n'a pas l'autorisation caméra ou micro

Le mécanisme est un Internet-Draft de l'IETF, révisé pour la dernière fois en décembre 2021 et jamais publié comme RFC. draft-ietf-mmusic-mdns-ice-candidates-03

Une adresse que WebRTC pourrait proposerMasquée ?
192.168.1.20Votre IPv4 privée, comme candidat hôteMasquéeRemplacée par un nom aléatoire : la page n'apprend rien sur votre réseau.
203.0.113.7Votre IPv4 publique, comme candidat du serveur STUNVisibleDéjà publique, donc elle reste. Seule l'adresse liée est effacée.
2001:db8:4a1f:7c00::1cUne IPv6 routable, comme candidat hôteVisiblePublique elle aussi, le masquage n'a donc jamais été prévu pour la couvrir.
2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07Une adresse IPv6 temporairePeut être visibleL'Internet-Draft permet à un navigateur de la laisser non masquée, par choix.
192.168.1.20Toute adresse locale, sur un site autorisé à utiliser la caméra ou le microMasquage désactivéChrome y désactive le masquage : le site voit vos vraies adresses locales.
Le masquage cache ce que seul votre propre réseau sait. Ce qu'un site pourrait voir de toute façon, il le laisse tel quel : à dessein, pas par erreur.

Pourquoi l'IPv6 est la fuite qui reste

Une adresse IPv6 globale appartient à une seule machine plutôt qu'à un foyer derrière un NAT, et mDNS la laisse délibérément tranquille. C'est ce que WebRTC fournit encore de plus identifiant.

Avec l'IPv4, le NAT de votre routeur domestique place tout derrière une seule adresse, si bien qu'un candidat réflexif serveur apprend à une page à peu près ce que lui dit déjà votre connexion ordinaire. L'IPv6 n'a pas de NAT : chaque appareil a sa propre adresse routable, et un candidat hôte qui la porte désigne l'appareil, pas la ligne. Si votre VPN ne transporte que l'IPv4 — c'est le cas de beaucoup —, cette adresse IPv6 est en plus entièrement hors du tunnel.

Les extensions de confidentialité aident, car une adresse IPv6 temporaire change régulièrement. Elles ne la cachent pas pour autant : l'Internet-Draft sur mDNS dit que de telles adresses peuvent être laissées non masquées. Le test ci-dessus classe un candidat hôte IPv6 routable comme le constat le plus grave qu'il puisse faire, et le test IPv6 vous dira si votre connexion a l'IPv6 tout court.

Qui une adresse désigneles trois mêmes appareils, deux fois

RouteurIPv4, derrière un NATIPv6, sans NAT
Portable192.168.1.202001:db8:4a1f:7c00::1c
Téléphone192.168.1.212001:db8:4a1f:7c00::2b
TV192.168.1.222001:db8:4a1f:7c00::3d
Routeur203.0.113.7Une adresse pour toute la ligneUne adresse par appareil

Une adresse IPv6 globale, en deux moitiés

2001:db8:4a1f:7c00Préfixe réseau : votre ligne /64:8d3:5e2f:a41c:9b07ID d'interface : cet appareil

  • Stable2001:db8:4a1f:7c00::1c
  • Temporaire : change2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07

Un VPN qui ne transporte que l'IPv4

  • IPv4198.51.100.23Dans le tunnel
  • IPv62001:db8:4a1f:7c00::1cHors du tunnel
Derrière le NAT IPv4, un foyer partage une adresse ; en IPv6, chaque appareil a la sienne, et un candidat hôte la propose directement. Le test considère un candidat hôte IPv6 routable comme le constat le plus grave.

Comment arrêter une fuite WebRTC dans chaque navigateur

Firefox a des préférences qui fonctionnent. Edge a une stratégie d'entreprise. Safari restreint déjà les candidats. Les extensions de navigateur qu'on recommande encore ne servent plus à rien.

Dans Firefox, about:config → media.peerconnection.ice.default_address_only n'envoie qu'une adresse au lieu de toutes, et media.peerconnection.ice.relay_only limite la collecte aux candidats relais, ce qui casse les appels directs mais cache tout le reste. Les deux sont désactivés par défaut ; le masquage mDNS des adresses privées (media.peerconnection.ice.obfuscate_host_addresses) est déjà activé. Dans Edge, la stratégie WebRtcLocalIpsAllowedUrls contrôle quels sites peuvent voir les adresses locales ; la documentation de Microsoft elle-même note qu'ajouter un site « affaiblit la protection ». Chrome n'a aucun réglage équivalent pour un utilisateur ordinaire. Safari est le plus strict sans rien demander : sans autorisation caméra ou micro, WebKit ne propose que des candidats réflexifs serveur et relais, et aucun candidat hôte.

Deux conseils encore très répandus sont morts. L'option « Prevent WebRTC from leaking local IP addresses » d'uBlock Origin a été supprimée dans la version 1.38, avec la note qu'elle n'est « plus nécessaire dans les navigateurs modernes, sauf pour Firefox pour Android ». Et l'extension WebRTC Network Limiter de Google, toujours présente dans la boutique, ne peut pas fonctionner : les extensions Manifest V2 sont désactivées pour tous les utilisateurs de Chrome depuis Chrome 138, en juillet 2025. Si une page vous dit d'installer l'une ou l'autre, cette page n'a pas été mise à jour depuis des années.

Ce que propose chaque navigateurvérifié dans la documentation de chaque éditeur

  • FirefoxDes préférences qui fonctionnent

    about:config

    • media.peerconnection.ice.obfuscate_host_addressesPar défaut trueMasque les adresses privées. Déjà activé.
    • media.peerconnection.ice.default_address_onlyPar défaut falseÀ régler sur trueN'envoie qu'une adresse au lieu de toutes.
    • media.peerconnection.ice.relay_onlyPar défaut falseÀ régler sur trueCandidats relais seulement. Cache le plus, et casse les appels directs.

  • EdgeStratégie d'entreprise

    WebRtcLocalIpsAllowedUrls

    Liste les sites autorisés à voir les adresses locales.

    Non configurée : les adresses locales restent masquées.

    Note de Microsoft elle-même : ajouter un site affaiblit la protection.

    Windows et macOS, version 80 et suivantes

  • ChromeAucun réglage

    Aucun réglage pour un utilisateur ordinaire.

    Adresses privées masquées par défaut depuis la version 76.

    Pas sur un site autorisé à utiliser la caméra ou le micro.

  • SafariStrict par défaut

    Sans autorisation caméra ou micro, seulement des candidats serveur STUN et relais.

    Aucun candidat hôte.

Des conseils qui ne marchent plus

  • Prevent WebRTC from leaking local IP addresses

    uBlock Origin

    Supprimée dans la version 1.38

    Plus nécessaire dans les navigateurs modernes, selon uBlock Origin, sauf sur Firefox pour Android.

  • WebRTC Network Limiter

    Google · Chrome Web Store

    Toujours listée, ne peut pas fonctionner

    Les extensions Manifest V2 sont désactivées pour tous les utilisateurs de Chrome depuis Chrome 138, en juillet 2025.

La documentation de chaque éditeur, lue le jour où cette page a été vérifiée. Une page qui vous dit encore d'installer l'une des deux dernières n'a pas été mise à jour depuis des années.

Fuite WebRTC, fuite DNS et fuite d'IP : quelle différence ?

Ce sont trois façons différentes de contourner un VPN. Une fuite WebRTC montre une adresse ; une fuite DNS montre qui répond à vos recherches ; une fuite d'IP est le cas simple où votre trafic n'est jamais entré dans le tunnel.

Une fuite WebRTC concerne les adresses que votre navigateur fournit de lui-même par une fonction conçue pour les fournir. Une fuite DNS concerne le résolveur qui répond à vos recherches : votre trafic peut passer par le VPN pendant que vos recherches vont toujours au résolveur de votre fournisseur, ce qui lui apprend chaque site que vous visitez. Notre test de fuite DNS le vérifie avec notre propre serveur de noms, et voit ainsi exactement quels résolveurs ont demandé.

Une fuite d'IP au sens général, c'est l'adresse qu'un site voit tout simplement, que vous pouvez vérifier sur Quelle est mon IP ou Quel est mon FAI. Lancez les trois ensemble après tout changement de VPN : ils échouent indépendamment, et un résultat propre sur l'un ne dit rien des autres.

Trois façons de contourner un VPNchacune échoue de son côté

VousTUNNEL VPNPar le tunnelFuite d'IP · votre traficLe site web203.0.113.7Fuite DNS · vos recherchesLe résolveur de votre FAI203.0.113.53Fuite WebRTC · vos adressesLe script de la page203.0.113.7VousTUNNEL VPNPar le tunnelFuite d'IPvotre traficLe site web203.0.113.7Fuite DNSvos recherchesLe résolveur de votre FAI203.0.113.53Fuite WebRTCvos adressesLe script de la page203.0.113.7

  • Fuite d'IP

    Ce qui fuitL'adresse que porte chaque requête

    Qui l'apprendChaque site que vous visitez

    À vérifier avecQuelle Est Mon IPQuel Est Mon FAI

  • Fuite DNS

    Ce qui fuitQuel résolveur répond à vos recherches

    Qui l'apprendVotre fournisseur, pour chaque site recherché

    À vérifier avecTest de fuite DNS

  • Fuite WebRTC

    Ce qui fuitLes adresses que votre navigateur propose à une page

    Qui l'apprendToute page qui le demande, sans autorisation

    À vérifier avecTest de fuite WebRTC

Elles échouent indépendamment : un résultat propre sur l'une ne dit rien des deux autres. Lancez les trois après tout changement de votre VPN.

Pourquoi ce test interroge plus d'un serveur STUN

Parce que « aucune adresse n'est revenue » et « aucune adresse n'existe » se ressemblent, et qu'une seule des deux est une bonne nouvelle.

Un pare-feu d'entreprise, un VPN restrictif ou un réseau qui bloque l'UDP peut empêcher un serveur STUN de répondre. Un test qui interroge un seul fournisseur et ne voit rien n'a rien appris — pourtant, la réponse habituelle est d'afficher une coche verte. Celui-ci interroge le point d'accès STUN documenté de Cloudflare et celui de Google, rend compte de chacun séparément et affiche « Non testé » quand aucun n'a répondu.

Le choix des serveurs est délibéré. Cloudflare publie stun.cloudflare.com:3478 dans le cadre d'un produit, il y a donc des conditions à lire. Le stun.l.google.com:19302 de Google n'est documenté que comme valeur par défaut du propre validateur WebRTC de Google, sans conditions publiées : il sert donc de second avis plutôt que de source unique. Celui de Twilio exige des identifiants, et Mozilla ne documente aucun serveur STUN public, même si on en cite souvent un.

Serveurs STUN publicset ceux que ce test interroge

  • CloudflareInterrogé

    stun.cloudflare.com:3478

    Un point d'accès documenté, intégré à un produit, avec des conditions à lire.

  • GoogleInterrogé, comme second avis

    stun.l.google.com:19302

    Documenté seulement comme valeur par défaut du propre validateur WebRTC de Google. Aucune condition publiée.

  • TwilioNon interrogé

    global.stun.twilio.com:3478

    Exige des identifiants obtenus par l'API de Twilio : pas ouvert à toutes les pages.

  • MozillaNon interrogé

    Aucun serveur public

    Ne documente aucun serveur STUN public. Firefox n'est livré avec aucun serveur ICE par défaut.

Quand un serveur ne dit rien

CloudflareGoogle
A réponduA réponduLe résultat tient
A réponduMuetLe résultat tient ; le serveur muet est nommé
MuetA réponduLe résultat tient ; le serveur muet est nommé
MuetMuetNon testé
Deux opérateurs, interrogés séparément. Un serveur muet est nommé et le résultat tient ; quand aucun ne répond, rien n'a été mesuré, et le test le dit au lieu d'afficher une réussite.

Mon adresse IP est-elle une donnée personnelle ?

Dans l'UE, une adresse IP dynamique est une donnée à caractère personnel pour l'exploitant d'un site qui pourrait vous identifier avec l'aide des informations que détient le fournisseur d'accès. La Cour de justice l'a jugé en 2016.

L'affaire est Breyer, C-582/14, jugée le 19 octobre 2016, et le communiqué de presse de la Cour la résume ainsi : « L'adresse de protocole internet dynamique d'un visiteur constitue, pour l'exploitant du site, une donnée à caractère personnel, lorsque cet exploitant dispose de moyens légaux lui permettant de faire identifier le visiteur concerné grâce aux informations supplémentaires dont dispose le fournisseur d'accès à Internet du visiteur. » Le même communiqué note qu'un site peut avoir un intérêt légitime à en conserver une partie pour se défendre contre des attaques.

C'est toute la raison pour laquelle cette page fait son travail dans votre navigateur. Les candidats ICE sont collectés par votre navigateur, comparés dans votre navigateur et affichés pour vous ; aucune adresse trouvée par WebRTC ne nous est envoyée, il n'y a donc rien que nous puissions conserver, transmettre ou perdre. Vous pouvez surveiller l'onglet Réseau des outils de développement pendant le test.

L'arrêt BreyerCour de justice de l'Union européenne

C-582/14Breyer v Bundesrepublik Deutschland19 octobre 2016

  1. L'exploitant du siteune adresse et une heure, tirées de ses journaux203.0.113.7 · 14:02:37
  2. les moyens légaux de l'obtenir
  3. Le fournisseur d'accès à Internetqui utilisait cette adresse à ce moment-là203.0.113.7 · 14:02:37 →
  4. Une donnée personnelle, pour cet exploitant

Le communiqué de presse de la Cour : un site peut avoir un intérêt légitime à en conserver une partie pour se défendre contre des attaques.

Sur cette page

Votre navigateur

  1. Collecte
  2. Classe
  3. Compare
  4. Affiche
  • Voient votre adresse publique, comme pour tout appel
  • dnsrobot.netAucun candidat n'est envoyé
Affaire C-582/14, Breyer. Une adresse IP dynamique est une donnée personnelle pour l'exploitant d'un site qui a les moyens légaux de vous identifier grâce aux registres du fournisseur. Cette page garde les candidats dans votre navigateur.

Test de fuite WebRTC : questions et réponses

Qu'est-ce qu'une fuite WebRTC ?

WebRTC est la fonction du navigateur qui fait marcher les appels vidéo. Pour relier directement deux personnes, elle rassemble toutes les adresses auxquelles votre machine peut être jointe et les propose à la page, sans aucune demande d'autorisation. Cela devient une fuite quand l'une de ces adresses est une adresse que vous cachiez — typiquement votre vraie adresse alors qu'un VPN est actif, parce que WebRTC peut interroger toutes les interfaces réseau et pas seulement celle qu'utilise votre navigation.

Comment tester une fuite WebRTC ?

Lancez le test sur cette page. Il interroge trois serveurs STUN de deux opérateurs, liste chaque adresse produite par WebRTC avec sa nature, et compare les adresses routables à celle qu'un site voit déjà. Si vous utilisez un VPN, lancez-le une fois avec le VPN désactivé et une fois activé : la différence entre les deux tests est la réponse.

Un VPN empêche-t-il une fuite WebRTC ?

Pas à lui seul. Un VPN change la destination de votre trafic, mais WebRTC peut demander au système d'exploitation quelles interfaces existent, et la connexion physique en fait généralement toujours partie. Le texte de l'IETF lui-même dit que WebRTC peut découvrir « non seulement l'adresse publique du VPN, mais aussi l'adresse publique du FAI sur laquelle le VPN fonctionne ». Certains clients VPN comblent la brèche ; ce test vous dit si le vôtre l'a fait.

Que signifie une adresse .local dans les résultats ?

C'est mDNS, et c'est une bonne nouvelle. Les navigateurs modernes remplacent vos adresses privées par un nom aléatoire se terminant par .local avant de les proposer à une page, si bien qu'un site n'en apprend rien sur votre réseau domestique. Chrome le fait depuis la version 76 et Firefox fait de même ; Safari va plus loin et ne propose aucun candidat hôte tant qu'un site n'a pas l'autorisation d'utiliser la caméra ou le micro. Le test les présente comme la protection qui fonctionne plutôt que comme un constat.

Si mDNS cache mon IP locale, suis-je en sécurité ?

En partie. mDNS a été conçu pour cacher les adresses privées et explicitement pas une adresse déjà publique — l'Internet-Draft de l'IETF qui le définit le dit. Votre IPv4 publique apparaît toujours comme candidat réflexif serveur, et une machine dotée d'une adresse IPv6 routable peut toujours proposer cette adresse directement. Chrome désactive aussi la protection pour tout site qui a déjà l'autorisation d'utiliser la caméra ou le micro.

Pourquoi le test affiche-t-il parfois « Non testé » ?

Parce que c'est la vérité. Si WebRTC est désactivé, bloqué par une extension ou une stratégie, ou si aucun serveur STUN n'a répondu — un pare-feu, un VPN restrictif, un réseau qui bloque l'UDP —, alors rien n'a été mesuré. La plupart des outils affichent une coche verte dans cette situation, ce qui est la chose la plus trompeuse qu'un test de fuite puisse faire. Celui-ci dit ce qui s'est passé et nomme les serveurs restés muets.

Comment désactiver WebRTC dans Firefox ?

Les préférences documentées de Firefox restreignent WebRTC plutôt qu'elles ne le désactivent. Dans about:config, media.peerconnection.ice.default_address_only n'envoie qu'une adresse au lieu de toutes, et media.peerconnection.ice.relay_only limite la collecte aux candidats relais : c'est ce qui cache le plus, mais cela casse les appels directs. Le masquage des adresses privées, media.peerconnection.ice.obfuscate_host_addresses, est déjà activé par défaut. Relancez le test après chaque changement pour voir ce qu'il vous a apporté.

Comment empêcher les fuites WebRTC dans Chrome ?

Chrome ne propose aucun réglage pour cela à un utilisateur ordinaire ; le masquage mDNS des adresses privées est activé par défaut, et c'est la protection dont vous disposez. Edge, qui partage le moteur de Chrome, a la stratégie d'entreprise WebRtcLocalIpsAllowedUrls. Les extensions encore très recommandées ne fonctionnent pas : uBlock Origin a supprimé son option WebRTC dans la version 1.38, et le WebRTC Network Limiter de Google ne peut plus fonctionner depuis que Manifest V2 a été désactivé dans Chrome 138.

Quelle est la différence entre un candidat hôte et un candidat réflexif serveur ?

Un candidat hôte est une adresse sur votre propre machine. Un candidat réflexif serveur est ce qu'un serveur STUN a vu — le côté public de votre NAT, qui est généralement l'adresse que le site a déjà grâce à votre connexion. Un candidat hôte routable est le constat le plus grave, car c'est une adresse sur l'appareil lui-même, et en IPv6 elle identifie l'appareil plutôt que le foyer.

Une fuite WebRTC, est-ce la même chose qu'une fuite DNS ?

Non. Une fuite WebRTC révèle une adresse ; une fuite DNS révèle quel résolveur répond à vos recherches, ce qui apprend à votre fournisseur chaque site que vous visitez, même quand le trafic lui-même passe par le VPN. Elles échouent indépendamment, donc un résultat propre sur l'une ne dit rien de l'autre. Lancez aussi notre test de fuite DNS après tout changement de VPN.

Ce test envoie-t-il mon adresse IP quelque part ?

Seulement là où n'importe quel site la verrait. Votre navigateur contacte les serveurs STUN, comme tout appel vidéo : c'est le test. Pour savoir ce qu'un site voit, la page demande vos adresses et leurs réseaux à ipify.org et à notre propre serveur, comme le fait le test de fuite DNS. Les adresses trouvées par WebRTC restent dans votre navigateur : aucune ne nous est envoyée. Observez l'onglet Réseau des outils de développement pendant que le test tourne.

Mon adresse IP est-elle une donnée personnelle en droit de l'UE ?

Pour l'exploitant d'un site dans l'UE, une adresse IP dynamique est une donnée à caractère personnel lorsque cet exploitant dispose de moyens légaux de vous identifier grâce aux informations que détient le fournisseur d'accès à Internet. C'est la décision de la Cour de justice dans l'affaire Breyer, C-582/14, d'octobre 2016. C'est l'une des raisons pour lesquelles cette page garde la partie WebRTC du test dans votre navigateur plutôt que sur l'un de nos serveurs.

Il vous manque quelque chose ?Suggérez une fonction ou un nouvel outil

Outils associés