Test de fuite WebRTC

Par La rédaction de Mon-Adresse-IP.net·Publié le 22 mai 2026·Mis à jour le 21 août 2026·

Le WebRTC permet à deux navigateurs de se parler directement, sans serveur intermédiaire. Pour y parvenir, il doit dresser la liste des adresses IP par lesquelles votre machine est joignable : y compris, parfois, celle qu'un VPN était censé masquer. Ce test s'exécute dans votre navigateur et n'envoie rien à nos serveurs ; il doit en revanche interroger un serveur STUN public tiers pour découvrir votre adresse publique, comme expliqué plus bas. Rien d'autre n'envoyer à nos serveurs, et cette page explique comment interpréter chaque ligne du résultat.

Qu'est-ce que le WebRTC et pourquoi il existe

WebRTC signifie Web Real-Time Communication. C'est un ensemble d'interfaces de programmation standardisées par le W3C et l'IETF qui permettent à une page web de capturer un microphone ou une caméra, puis d'échanger ce flux, ainsi que des données arbitraires, avec un autre navigateur, en temps réel et de préférence sans passer par un serveur relais.

Avant son arrivée, la visioconférence dans un navigateur imposait un greffon propriétaire, avec les problèmes de sécurité et de compatibilité que l'on sait. Aujourd'hui, la plupart des services d'appel vidéo accessibles par une simple URL, les outils de support à distance qui affichent votre écran dans un onglet, les jeux multijoueurs à faible latence et certains transferts de fichiers de navigateur à navigateur reposent sur cette technologie. Elle est active par défaut dans tous les navigateurs modernes, sur ordinateur comme sur mobile.

Il faut donc poser les choses clairement : le WebRTC n'est pas un bug ni une porte dérobée. C'est une fonctionnalité qui fait exactement ce pour quoi elle a été conçue. Le problème de vie privée naît d'une collision entre deux objectifs légitimes : la connexion directe, qui exige de connaître les adresses réelles des participants, et l'anonymisation par tunnel, qui vise précisément à les cacher. Aucune des deux n'est fautive ; c'est leur combinaison mal configurée qui pose problème.

Pourquoi le WebRTC révèle des adresses IP

Imaginez deux personnes qui veulent s'appeler. Chacune se trouve derrière une box qui pratique la traduction d'adresses réseau (NAT) : sur le réseau domestique, l'ordinateur porte une adresse privée du type 192.168.1.28, totalement inutilisable depuis l'extérieur, tandis que la box expose une seule adresse publique partagée par tous les appareils du foyer. Si le premier ordinateur envoie « joins-moi sur 192.168.1.28 », le second n'ira nulle part : cette adresse désigne un appareil de son propre réseau, ou rien du tout.

Pour résoudre ce problème, le WebRTC s'appuie sur un mécanisme baptisé ICE (Interactive Connectivity Establishment, décrit par le RFC 8445). Le principe est simple : chaque participant dresse la liste exhaustive des chemins par lesquels on pourrait le joindre, appelés candidats, les envoie à l'autre, puis les deux testent systématiquement toutes les combinaisons jusqu'à en trouver une qui fonctionne. Trois familles de candidats nous intéressent ici :

• Les candidats host : les adresses portées directement par les interfaces de la machine : Wi-Fi, Ethernet, adresse IPv6 globale, éventuellement adaptateur virtuel d'un VPN.
• Les candidats server reflexive (srflx) : l'adresse publique telle qu'elle est vue de l'extérieur. Pour la découvrir, le navigateur envoie un petit paquet à un serveur STUN (RFC 8489), dont l'unique rôle est de répondre : « voici l'adresse et le port par lesquels ta requête m'est parvenue ». C'est cette réponse qui révèle l'adresse publique réellement utilisée par le trafic.
• Les candidats relay : une adresse louée sur un serveur TURN, utilisée en dernier recours quand aucune connexion directe n'est possible. Elle ne révèle rien de vous, mais coûte de la bande passante à l'opérateur du service.

Le point décisif est celui-ci : la découverte STUN se fait en UDP, en dehors du flux HTTPS de la page. Si votre tunnel VPN n'intercepte pas ce trafic (parce qu'il ne route que le TCP, parce qu'il ignore l'IPv6, ou parce qu'il s'agit d'une simple extension de navigateur qui ne fait que du proxy HTTP), alors le paquet part par votre connexion normale et le serveur STUN répond avec votre véritable adresse. La page peut la lire immédiatement, sans autorisation particulière et sans que vous ayez rien à cliquer.

Comment lire les résultats du test

Le test collecte les candidats ICE générés par votre navigateur et en extrait toutes les adresses. Selon votre configuration, vous verrez apparaître plusieurs types de valeurs, dont la signification est très différente. C'est le point que la plupart des tests de fuite passent sous silence, alors qu'il conditionne toute l'interprétation.

Le cas particulier des identifiants .local

Il y a quelques années, n'importe quelle page web pouvait lire l'adresse privée exacte de votre ordinateur. C'était peu grave en soi (une adresse comme 192.168.1.28 n'est pas unique au monde et ne permet pas de vous identifier), mais cela renseignait sur la structure de votre réseau et, surtout, cela offrait un signal supplémentaire aux régies publicitaires, capables de reconnaître deux visiteurs différents partageant la même adresse publique.

Les navigateurs ont donc adopté une contre-mesure décrite par le RFC 8828 : au lieu de publier l'adresse locale, le navigateur enregistre un nom aléatoire dans le système multicast DNS de votre réseau, du type 9b4c1f7e-3a11-4f60-9c2e-8a2d5f0b1c33.local, et ne transmet que ce nom. Vos voisins de réseau savent le résoudre (c'est ce qui permet à l'appel de fonctionner entre deux machines du même bureau), mais un site distant n'en tire strictement rien. L'identifiant est régénéré et cloisonné par origine, ce qui empêche de vous suivre d'un site à l'autre.

Concrètement : si le test n'affiche que des .local dans la partie « adresses locales », votre navigateur est à jour et applique correctement cette protection. Une nuance mérite d'être connue : sur les navigateurs dérivés de Chromium, l'anonymisation est levée pour les sites auxquels vous avez déjà accordé l'accès au micro ou à la caméra, puisque l'appel réel a besoin des vraies adresses. Un site de visioconférence que vous utilisez régulièrement voit donc davantage de choses qu'un site quelconque : une raison de plus de ne donner ces autorisations qu'aux services que vous utilisez vraiment.

Y a-t-il vraiment fuite ?

C'est la question que la plupart des pages sur le sujet évitent soigneusement, parce que la réponse honnête est décevante : dans la majorité des cas, non.

Si vous ne faites transiter votre connexion par aucun tunnel, l'adresse publique remontée par le WebRTC est celle de votre box, c'est-à-dire exactement celle que ce site affiche déjà en haut de page et que voit chaque serveur que vous contactez. Il n'y a rien à « fuir » : cette adresse est nécessaire au fonctionnement d'Internet, elle figure dans les journaux de tous les sites que vous visitez, au même titre que les en-têtes HTTP que votre navigateur transmet spontanément. Le test se contente alors de confirmer une situation normale.

La fuite au sens strict correspond à un écart. Elle existe quand :

1. Un tunnel est actif VPN, proxy système ou réseau anonymisant, censé faire apparaître une autre adresse à votre place.
2. Le test remonte une adresse publique différente de celle que ce site affiche : typiquement l'adresse réelle de votre fournisseur d'accès, ou une adresse IPv6 native alors que le tunnel n'annonce qu'une IPv4.
3. Cette adresse permet de vous relier à votre abonnement : elle est associée à votre ligne chez Orange, Free, SFR ou Bouygues, et non à l'infrastructure du fournisseur de tunnel.

Deux faux positifs classiques méritent d'être signalés. Le premier concerne les abonnés en CGNAT : l'adresse publique remontée est partagée entre de nombreux clients de l'opérateur, souvent sur les offres mobiles et fibre d'entrée de gamme. Elle reste une donnée à caractère personnel, mais elle vous identifie beaucoup moins précisément qu'une adresse dédiée. Le second concerne les VPN dits « à double saut » ou les configurations d'entreprise : l'adresse remontée peut différer de celle du site sans être la vôtre pour autant. Dans le doute, vérifiez à qui appartient l'adresse trouvée avec notre outil de recherche d'IP : si l'organisation correspond à votre fournisseur d'accès grand public, la fuite est réelle.

Que faire en cas de fuite réelle

Les solutions ne se valent pas. Voici les mesures classées de la plus efficace à la plus contraignante, avec leurs contreparties réelles.

1. Corriger la cause : le traitement de l'IPv6 par le tunnel

C'est de loin l'origine la plus fréquente en France, où l'IPv6 est largement déployé chez les principaux opérateurs. Si votre tunnel ne transporte que l'IPv4 pendant que votre box continue de fournir une connectivité IPv6 native, une part de votre trafic (variable, mais qui peut être importante), échappe à la protection, et le WebRTC le montre immédiatement. Deux configurations acceptables existent : un service qui achemine véritablement l'IPv6 dans le tunnel, ou un service qui bloque totalement l'IPv6 pendant la connexion afin de forcer le repli sur l'IPv4 protégée. Les protocoles modernes gèrent tous l'IPv6 sur le plan technique ; c'est l'implémentation du client qui fait la différence. Notre guide des VPN détaille les points à vérifier avant de s'engager.

2. Activer le coupe-circuit (kill switch)

Cette fonction bloque tout trafic sortant qui n'emprunte pas le tunnel, y compris les paquets UDP du WebRTC et l'IPv6 quand elle n'est pas prise en charge. C'est la protection la plus robuste car elle agit au niveau du système, avant que le navigateur n'ait son mot à dire. Contrepartie : en cas de coupure du VPN, vous perdez purement et simplement Internet jusqu'à la reconnexion, ce qui est précisément l'effet recherché.

3. Restreindre ou désactiver le WebRTC dans le navigateur

Mesure efficace mais brutale, détaillée dans la section suivante. Elle traite le symptôme et non la cause : votre trafic ordinaire continuera de fuir par d'autres canaux si le tunnel est mal configuré. Elle a du sens sur un profil dédié à la navigation, beaucoup moins sur le poste avec lequel vous participez à des réunions.

4. Cloisonner avec un profil ou un navigateur dédié

Approche souvent plus confortable : un navigateur A, sans WebRTC et utilisé derrière le tunnel, et un navigateur B, normal, pour la visioconférence et les services qui vous connaissent déjà. Le cloisonnement limite aussi la corrélation entre vos activités, ce que ne fait aucun réglage isolé. C'est le principe que l'on retrouve poussé à l'extrême dans le navigateur Tor.

Pourquoi les extensions « anti-WebRTC » sont un remède imparfait

Désactiver le WebRTC selon le navigateur

Les possibilités varient fortement d'un navigateur à l'autre. Voici l'état réel des options, sans promesse excessive.

Après chaque modification, relancez le test en haut de cette page, puis vérifiez également l'adresse vue par nos autres outils : un réglage peut résoudre la fuite WebRTC sans corriger la fuite DNS, et inversement. La méthode que nous suivons pour ces vérifications est décrite dans notre page de méthodologie.

WebRTC et empreinte du navigateur

La fuite d'adresse n'est pas le seul apport du WebRTC au pistage. L'interface expose aussi la liste des périphériques média disponibles sur votre machine. Sans autorisation, un site n'obtient ni le nom ni l'identifiant de vos appareils, mais il apprend combien vous avez d'entrées audio, de sorties audio et de caméras. Un ordinateur portable avec un casque USB branché, un micro externe et une webcam supplémentaire présente une combinaison sensiblement plus rare qu'une machine sortie d'usine.

S'y ajoutent les capacités déclarées de votre pile média : codecs pris en charge, extensions d'en-tête, ordre exact dans lequel ces éléments sont annoncés. Cette liste varie avec le navigateur, sa version, le système d'exploitation et parfois les pilotes installés. Prise isolément, chacune de ces valeurs est banale ; combinées, elles contribuent à un identifiant stable qui n'a besoin d'aucun cookie pour vous suivre.

Vous pouvez mesurer concrètement l'effet de ces signaux avec notre outil Empreinte de mon navigateur, qui montre ce que votre configuration révèle réellement, et comprendre les contre-mesures possibles dans notre guide sur l'empreinte de navigateur. Une conclusion s'impose souvent : masquer son adresse IP améliore la situation, mais ne suffit pas à devenir indistinct. Notre dossier sur les moyens de masquer son adresse IP replace chaque outil devant le risque qu'il traite réellement, et notre guide sur les adresses publiques et privées précise ce que chaque type d'adresse dit vraiment de vous.

Questions fréquentes