Test de fuite WebRTC : comment vérifier (et corriger) la faille qui expose ta vraie IP

Tu te connectes à un VPN, l'appli affiche « protégé », et tu supposes que ta vraie adresse IP est cachée. Pour l'essentiel de ton trafic, c'est le cas. Mais il existe une exception discrète, intégrée à ton navigateur, qui peut livrer ta vraie IP directement à n'importe quel site que tu visites — et ton VPN ne t'avertira pas.

Cette exception, c'est WebRTC. C'est une technologie de navigateur conçue pour l'audio et la vidéo en temps réel, et elle fonctionne si bien qu'elle est activée par défaut presque partout. Le mécanisme même qui te permet de passer un appel vidéo sans rien installer peut aussi révéler l'adresse IP que ton VPN était censé masquer.

Ce guide explique ce qu'est réellement une fuite WebRTC, pourquoi elle échappe au tunnel VPN, comment la tester en moins d'une minute, et comment la corriger sur chaque grand navigateur — avec, à chaque fois, l'inconvénient honnête de la solution.

Ce qu'est WebRTC — et pourquoi il peut révéler ton IP

WebRTC (Web Real-Time Communication) est une API intégrée aux navigateurs modernes qui permet aux pages web d'échanger de l'audio, de la vidéo et des données directement entre utilisateurs, en pair-à-pair, sans extension. C'est elle qui alimente les appels vidéo dans le navigateur, le chat vocal et certains outils de partage de fichiers.

Pour connecter deux personnes qui sont toutes deux derrière une box, WebRTC doit découvrir l'adresse publique à laquelle chaque appareil est joignable. Il s'appuie pour cela sur des serveurs STUN et sur le framework ICE (Interactive Connectivity Establishment). En clair : ton navigateur demande à un serveur STUN « à quoi ressemble mon adresse vue de l'extérieur ? », et la réponse revient avec ton IP.

Voilà le piège. Cette découverte STUN/ICE peut énumérer toutes les adresses réseau que ton appareil connaît — y compris ton IP locale et, surtout, ta vraie IP publique — et elle peut le faire par un chemin qui contourne le tunnel VPN. Le VPN réachemine ton trafic normal, mais la requête WebRTC peut le court-circuiter, si bien que l'IP qu'elle rapporte est celle que ton VPN était censé cacher. Le site n'a jamais eu besoin de demander la permission à ton VPN : c'est le navigateur qui a livré l'information de lui-même.

Ce n'est pas un bug propre à un VPN en particulier. C'est une conséquence de la façon dont WebRTC a été conçu pour trouver la route la plus directe entre pairs — et ces routes directes sont précisément ce qu'un VPN cherche à empêcher.

Quels navigateurs sont concernés

WebRTC est activé par défaut sur la plupart des navigateurs modernes parce que les appels en temps réel en dépendent. Le risque de fuite existe donc partout :

• Chrome — WebRTC activé par défaut ; se contrôle surtout via des extensions ou des stratégies.
• Firefox — WebRTC activé par défaut, mais il expose un réglage direct dans about:config.
• Edge — basé sur Chromium, se comporte comme Chrome.
• Brave — basé sur Chromium mais propose un réglage dédié de gestion d'IP WebRTC dans ses options de confidentialité.
• Safari — prend en charge WebRTC ; son comportement et ses contrôles diffèrent de la famille Chromium.

La gravité et les correctifs disponibles varient selon le navigateur, c'est pourquoi tester ta propre configuration compte plus que de supposer « mon navigateur va bien ».

Comment tester une fuite WebRTC

Tester est le seul moyen de connaître ton exposition réelle, et ça prend moins d'une minute :

1. Connecte-toi à ton VPN et vérifie que l'appli indique que tu es protégé. Note l'IP de sortie que ton VPN affirme utiliser (la plupart des applis VPN l'affichent).
2. Lance un test de fuite. Le plus rapide est notre propre test de fuite IP et WebRTC — il s'exécute entièrement dans ton navigateur et montre ce que ton IP, ton DNS et WebRTC exposent réellement, sans rien enregistrer.
3. Compare les IP. Regarde l'adresse IP rapportée par WebRTC. Si elle correspond à l'IP de sortie de ton VPN, tout va bien. Si elle affiche ta vraie IP publique (celle de ton FAI), ou si ta vraie IP apparaît à côté de l'IP du VPN, c'est une fuite.

Une vérification simple : note d'abord ta vraie IP avec le VPN éteint, puis allume le VPN et re-teste. Si WebRTC fait toujours remonter cette même vraie IP, c'est que le tunnel est contourné.

Comment corriger une fuite WebRTC

Il existe trois solutions honnêtes, et la bonne dépend de si tu passes parfois des appels dans le navigateur.

Désactiver complètement WebRTC (Firefox)

Firefox est le cas le plus simple parce qu'il offre un interrupteur direct :

1. Tape about:config dans la barre d'adresse et accepte l'avertissement.
2. Cherche media.peerconnection.enabled.
3. Mets-le sur false.

WebRTC est désormais désactivé dans ce navigateur. C'est le correctif le plus complet — mais il cassera tout site qui s'appuie sur WebRTC pour les appels (voir le compromis plus bas).

Restreindre WebRTC plutôt que le supprimer (Brave)

Brave te permet de garder WebRTC fonctionnel tout en l'empêchant de fuiter. Dans les réglages de Brave, sous confidentialité/sécurité, règle la politique de gestion d'IP WebRTC sur « disable non-proxied UDP ». Cela force WebRTC à passer par ton chemin proxy/VPN au lieu de prendre un raccourci UDP direct, ce qui l'empêche d'exposer ta vraie IP derrière le VPN.

Utiliser une extension (Chrome, Edge et autres)

Les navigateurs Chromium comme Chrome et Edge n'exposent pas de réglage natif ; la solution pratique est donc une extension. uBlock Origin inclut dans ses réglages une option appelée « Empêcher WebRTC de divulguer les adresses IP locales » — active-la. Il existe aussi des extensions dédiées qui contrôlent WebRTC, mais utiliser un outil que tu as déjà (comme uBlock Origin) limite le nombre d'extensions.

Choisir un VPN qui s'en charge pour toi

Certaines applis VPN intègrent une protection anti-fuite WebRTC, qui impose le tunnel au niveau du système ou de l'appli plutôt que de dépendre des réglages du navigateur. Si tu ne veux pas bricoler avec about:config ou des extensions, un VPN avec une protection auditée est l'option la moins coûteuse en effort. Quel que soit ton choix, relance le test de fuite ensuite — une protection que tu n'as pas vérifiée n'est qu'un espoir.

Le compromis honnête

Désactiver WebRTC n'est pas gratuit. WebRTC est la technologie derrière les appels dans le navigateur, donc le couper peut casser des outils comme Google Meet, Discord en version web et d'autres applis de visioconférence. C'est le vrai coût, et il faut le dire clairement.

Si tu dépends des appels dans le navigateur, tu as deux options raisonnables : restreindre WebRTC (l'approche « disable non-proxied UDP » à la Brave, qui garde les appels fonctionnels tout en les faisant passer par ton VPN), ou garder un profil de navigateur séparé avec WebRTC activé que tu n'utilises que pour les appels, pendant que ta navigation quotidienne tourne dans un profil durci avec WebRTC désactivé. Dans les deux cas, l'objectif est le même : stopper la fuite sans perdre les fonctions que tu utilises vraiment.

Après correction : vérifie, ne suppose pas

L'habitude la plus importante est de re-tester après chaque changement. Une mise à jour du navigateur, un nouveau profil, une extension réinstallée ou un serveur VPN changé peuvent tous modifier ton exposition. Connecte le VPN, ouvre un test de fuite, et confirme que WebRTC rapporte l'IP du VPN — pas la tienne.

Si tu veux creuser les fuites connexes qui mettent en échec un VPN, la fuite DNS est l'autre grande coupable : ton trafic passe par le tunnel mais tes requêtes DNS, elles, n'y passent pas. La même discipline de test s'applique.

Cet article explique des comportements de navigateur documentés et vérifiables (about:config de Firefox, politique de gestion d'IP WebRTC de Brave, option anti-fuite d'uBlock Origin). Les réglages et l'emplacement des menus changent d'une version à l'autre — vérifie le nom exact des options dans ton navigateur. VPNSmith publie ce contenu à des fins éducatives.