Aller au contenu
iseeu.cc
FR – Langue : Français

Test de fuite WebRTC

Vérifiez si votre navigateur révèle via WebRTC une adresse IP que votre VPN ou votre proxy est censé masquer. Le test s'exécute dans votre navigateur et se termine en général en quelques secondes (il attend huit secondes au maximum).

Résultat

Test en cours… nous demandons à un serveur STUN quelle adresse il voit

    Adresses comparées

    Votre connexion (HTTP)
    IP publique via WebRTC
    Serveur STUN utilisé

    Candidats ICE produits par votre navigateur

    TypeAdresseCatégorieProtocole

    En bref

    Une fuite WebRTC signifie que n'importe quelle page peut lire via WebRTC, sans demande d'autorisation, une adresse IP publique différente de celle qu'utilise votre connexion, par exemple votre adresse réelle alors que le VPN est actif. Ce test envoie une requête STUN à stun.cloudflare.com:3478, attend jusqu'à 8 secondes et compare chaque adresse publique reçue avec celle que voit le serveur ; la RFC 8828 décrit ce que les navigateurs doivent ou non révéler par ce biais.

    Comment c'est obtenu

    La page crée une RTCPeerConnection avec un serveur STUN et un canal de données, ce qui amène le navigateur à rassembler des candidats ICE (RFC 8445). Les candidats host portent des adresses locales, que les navigateurs actuels remplacent le plus souvent par un nom .local aléatoire ; les candidats server-reflexive (srflx) portent l'adresse publique vue par le serveur STUN (RFC 8489). Chaque adresse publique est comparée à l'adresse de votre requête HTTP ; deux adresses IPv6 comptent comme le même réseau quand leurs 64 premiers bits sont identiques.

    Exemple

    Un utilisateur de VPN se connecte via 198.51.100.7, et la réponse STUN contient 203.0.113.25. Les deux sont en IPv4 et elles diffèrent : le résultat est donc Fuite : WebRTC révèle une autre IP publique, et 203.0.113.25 est probablement l'adresse que le VPN devait masquer. Si la réponse avait été 198.51.100.7, le résultat aurait été l'absence de fuite ; s'il s'était agi d'une adresse IPv6 sur une connexion arrivée en IPv4, la page indique que WebRTC révèle aussi votre adresse IPv6, ce qui est normal sur une ligne double pile (IPv4 et IPv6) sans VPN. (Les deux adresses sont des adresses de documentation tirées de la RFC 5737.)

    Limites

    • Le test ne couvre que ce navigateur et ce profil ; d'autres navigateurs du même appareil peuvent se comporter différemment.
    • Si l'UDP vers le port STUN est bloqué ou si le réseau est lent, le résultat est marqué comme non concluant, et non comme sûr.
    • Il ne teste ni les fuites DNS ni le trafic des autres applications.

    Sources

    Sources vérifiées le . Page mise à jour le .

    Ce qu'est une fuite WebRTC

    WebRTC est la technologie du navigateur qui permet les appels vidéo, le partage d'écran et le transfert de fichiers de pair à pair sur des sites comme Google Meet et Discord. Pour relier directement deux personnes, le navigateur doit découvrir toutes les adresses auxquelles on peut le joindre. Pour cela, il envoie une toute petite requête à un serveur STUN, qui répond avec l'adresse publique d'où il a vu arriver cette requête. Le navigateur transmet ensuite ces adresses, appelées candidats ICE, au JavaScript de la page web.

    C'est utile pour les appels, et c'est un problème pour la vie privée. N'importe quelle page peut lancer ce processus en silence, sans demande d'autorisation, sans caméra ni micro. Si la requête STUN quitte votre ordinateur en dehors du tunnel de votre VPN, la page apprend l'adresse que vous a attribuée votre fournisseur d'accès, et non celle qu'affiche votre VPN. C'est cela, une fuite WebRTC : le site voit deux adresses, et l'une d'elles est justement celle que vous cherchiez à cacher.

    Mode d'emploi

    1. Activez votre VPN ou votre proxy comme d'habitude quand vous naviguez, puis ouvrez cette page.
    2. Attendez le cadre de résultat en haut. Le test démarre tout seul, et la ligne Test en cours est remplacée par un verdict d'une ligne accompagné d'une brève explication.
    3. Dans Adresses comparées, mettez la ligne Votre connexion (HTTP) en regard de la ligne IP publique via WebRTC. La ligne Serveur STUN utilisé indique quel serveur a répondu à votre navigateur.
    4. Parcourez le tableau des candidats ICE. Type indique d'où vient chaque candidat (host désigne votre appareil, srflx ce qu'a vu le serveur STUN, relay un serveur TURN), et Catégorie précise si l'adresse est publique, sur votre réseau local, derrière le NAT de l'opérateur ou masquée derrière un nom .local.
    5. Après avoir changé un réglage du navigateur ou une extension, cliquez sur Relancer le test. Si vous avez activé ou coupé le VPN lui-même, rechargez plutôt la page : l'adresse HTTP n'est lue qu'une fois, au chargement de la page.

    Faites un premier essai VPN coupé et notez l'adresse que vous donne votre FAI. C'est cette adresse qui ne doit jamais apparaître une fois le tunnel actif.

    Cas d'usage

    • Évaluer un VPN avant de lui faire confiance. Tunnel actif, l'adresse publique WebRTC doit correspondre à l'adresse HTTP ou être totalement absente. Une adresse différente de la même famille, c'est le résultat qui doit vous faire réagir.
    • Vérifier une extension proxy. Les extensions proxy des navigateurs font passer les requêtes ordinaires des pages, mais la requête STUN circule en UDP et peut sortir directement par votre FAI, sauf si le navigateur a pour consigne de la bloquer.
    • Repérer une faille côté IPv6. Certaines configurations VPN font passer l'IPv4 dans le tunnel et laissent l'IPv6 de côté. Le verdict indique alors que WebRTC révèle aussi votre adresse IPv6.
    • Contrôler une stratégie de navigateur gérée. Les équipes informatiques qui restreignent WebRTC sur les ordinateurs portables de l'entreprise peuvent ouvrir la page sur une machine de test et vérifier que le tableau des candidats ne montre que ce que la stratégie doit autoriser.
    • Déboguer une application WebRTC sur un réseau verrouillé. Si le tableau liste des candidats host mais aucun srflx, l'UDP vers le serveur STUN sur le port 3478 est probablement bloqué, et les appels sur ce réseau auront besoin d'un relais TURN.

    Comment fonctionne ce test

    1. Votre navigateur charge cette page par votre connexion habituelle : notre serveur voit donc une adresse publique, affichée plus haut sous Votre connexion (HTTP).
    2. La page crée une connexion WebRTC qui n'appelle jamais personne et demande au serveur STUN public de Cloudflare (stun.cloudflare.com) quelle adresse il voit.
    3. Nous listons chaque candidat produit par votre navigateur et comparons les candidats publics avec l'adresse HTTP. Tout se passe dans votre navigateur ; rien ne nous est renvoyé.

    Lire le résultat

    • Aucune fuite : WebRTC indique la même adresse publique que votre connexion, ou aucune. Si vous utilisez un VPN, il couvre bien WebRTC.
    • Fuite : WebRTC indique une autre adresse publique du même type (IPv4 contre IPv4). VPN activé, cette seconde adresse est presque toujours votre adresse réelle.
    • Autre protocole exposé : vous êtes connecté en IPv6 et WebRTC montre aussi une adresse IPv4, ou l'inverse. Sur une connexion domestique ordinaire, les deux vous appartiennent. Avec un VPN qui ne fait passer qu'un protocole dans le tunnel, l'autre fuit.
    • Adresse locale visible : une adresse 192.168.x.x ou 10.x.x.x signifie que votre navigateur partage l'adresse de votre appareil sur le réseau domestique. Les versions actuelles de Chrome, Edge, Firefox et Safari la masquent par défaut derrière un nom .local aléatoire.

    Comment empêcher une fuite WebRTC

    • Utilisez l'application de votre VPN, pas seulement son extension de navigateur. Un VPN au niveau du système fait passer le trafic STUN dans le tunnel ; une extension proxy, souvent non.
    • Activez la protection contre les fuites WebRTC dans l'application ou l'extension de votre VPN, si elle en propose une.
    • Firefox : ouvrez about:config et passez media.peerconnection.enabled à false pour couper complètement WebRTC, ou laissez-le actif et comptez sur le VPN.
    • Chrome et Edge : il n'existe pas d'interrupteur intégré ; utilisez une extension réputée qui règle la politique de gestion des adresses IP de WebRTC sur « Disable non-proxied UDP » (désactiver l'UDP qui ne passe pas par le proxy).
    • Brave : Paramètres → Confidentialité et sécurité → Politique de gestion des adresses IP WebRTC → « Désactiver l'UDP pas en proxy ».
    • Safari : les fuites sont rares, car Safari restreint les candidats ICE par défaut.

    Après chaque modification, relancez le test. N'oubliez pas que couper WebRTC empêche les appels depuis le navigateur : mieux vaut corriger le VPN que désactiver la fonction.

    Ce que ce test ne peut pas vous dire

    Un résultat propre ne concerne que WebRTC. Vos requêtes DNS, le fuseau horaire et la langue de votre navigateur, ainsi que votre empreinte, passent par des canaux distincts ; la page d'accueil vérifie si le fuseau horaire et la langue concordent avec votre IP, et le test d'empreinte couvre le reste. Nous ne proposons pas de test de fuite DNS, car il faudrait pour cela un serveur DNS dédié, et nous préférons ne pas faire semblant.

    Questions fréquentes

    Qu'est-ce qu'une fuite WebRTC ?

    Une fuite WebRTC se produit quand un site web se sert de la fonction de communication en temps réel de votre navigateur pour découvrir une adresse IP que votre VPN ou votre proxy devait masquer. La page demande à un serveur STUN quelle adresse il voit, et le navigateur transmet la réponse au JavaScript de la page.

    Une fuite WebRTC veut-elle dire que mon VPN ne fonctionne pas ?

    Pas forcément. La plupart des bonnes applications VPN font passer le trafic WebRTC dans le tunnel. Une fuite signifie en général que le VPN ne couvre qu'une partie de votre trafic, comme un proxy sous forme d'extension de navigateur, ou qu'il fait passer l'IPv4 dans le tunnel, mais pas l'IPv6.

    Faut-il désactiver WebRTC ?

    Seulement si vous ne passez pas d'appels depuis le navigateur. Les appels vidéo sur Google Meet, Discord, Teams et les sites du même genre ont besoin de WebRTC. Mieux vaut commencer par la protection WebRTC de votre VPN, ou par un réglage du navigateur qui limite les adresses que WebRTC peut partager.

    Pourquoi le test affiche-t-il une adresse en .local ?

    Les navigateurs récents remplacent l'adresse de votre appareil sur le réseau local par un nom aléatoire qui se termine par .local, généré avec mDNS. C'est une protection de la vie privée, pas une fuite.

    Ce test enregistre-t-il mon adresse IP ?

    Non. La comparaison se fait dans votre navigateur. La seule requête envoyée à notre serveur récupère l'IP qu'il voit, et elle n'est pas journalisée.

    Pourquoi le test ne trouve-t-il aucune IP publique ?

    Un pare-feu, un réglage du navigateur, une extension ou votre VPN a bloqué la requête STUN. Pour la confidentialité de WebRTC, c'est le meilleur résultat possible.

    Ce test vérifie un seul canal de fuite, au moment où vous le lancez. Les résultats dépendent de votre navigateur, de vos extensions et de votre réseau, et peuvent changer dès que l'un d'eux change. Ce n'est pas un audit de sécurité de votre VPN.

    Voir tous les outils