Qu'est-ce qu'une fuite WebRTC ?
Le WebRTC est la technologie qui permet aux navigateurs d'échanger de l'audio, de la vidéo et des données entre visiteurs. Pour établir le contact, il découvre les adresses IP des deux côtés, y compris dans votre réseau local et votre adresse publique.
Normalement, ces adresses ne servent qu'à votre propre connexion. On parle de fuite lorsqu'un site web utilise WebRTC pour découvrir votre adresse réelle alors que vous croyez naviguer derrière un VPN ou un proxy : le tunnel est contourné, et l'adresse révélée peut être celle de votre fournisseur d'accès. C'est le sens courant de la fuite WebRTC, et elle suppose qu'un site exploite volontairement cette interface.
WebRTC n'est pas un mouchard en soi : le navigateur masque les adresses locales derrière des noms mDNS aléatoires, et votre accord est requis pour l'accès à la caméra ou au microphone. La vérification ci-dessous montre ce que votre navigateur expose.
Comment fonctionne ce test ?
Le test se déroule entièrement dans cette page, à partir de trois sources distinctes :
- Une connexion WebRTC vers le serveur STUN public de Cloudflare (stun.cloudflare.com) recueille les adresses candidates que votre navigateur propose.
- Les points de terminaison Cloudflare (1.1.1.1, one.one.one.one) et le trace de l'edge indiquent l'adresse IPv4 et IPv6 réellement vue par Internet.
- Les API de votre navigateur fournissent le fuseau horaire et les langues, comparés à la localisation approximative calculée par le site.
Les adresses WebRTC publiques sont ensuite comparées aux adresses HTTP. Si elles correspondent, la connexion est cohérente ; si une adresse inconnue apparaît, elle est signalée comme fuite potentielle. Aucune adresse n'est envoyée à notre serveur : la comparaison et l'affichage restent locaux.
Comment corriger une fuite
Selon le navigateur, la protection contre les fuites WebRTC se règle différemment.
- Chrome et Edge : les réglages usuels n'offrent pas de case à cocher pour désactiver WebRTC. On peut appliquer une politique d'entreprise relative à WebRTC, utiliser un client VPN disposant d'une protection contre les fuites, ou bloquer WebRTC avec une extension de confiance.
- Firefox : ouvrez about:config, recherchez media.peerconnection.enabled et passez la valeur à false. Pour ne bloquer que certains sites, préférez la permission par site.
- Safari : aucun réglage dédié ne désactive WebRTC ; le navigateur protège les adresses locales par mDNS, mais l'adresse publique peut rester visible. Gardez-le à jour et utilisez un VPN doté d'une protection contre les fuites.
- Brave : ouvrez brave://settings/privacy et réglez la politique WebRTC sur l'option la plus stricte (Disable non-proxied UDP).
- Clients VPN : activez si possible la protection contre les fuites (kill switch, protection WebRTC/IPv6) et vérifiez que le tunnel couvre IPv4 et IPv6.
Après chaque changement, relancez le test : une protection active ici s'applique aussi aux autres sites, puisque la fuite vient du navigateur et non de cette page.
Les fuites IPv6
Un VPN qui ne prend en charge qu'IPv4 peut laisser passer IPv6 à côté du tunnel. Votre adresse IPv4 devient celle du serveur VPN, mais l'adresse IPv6 reste celle de votre fournisseur : les sites compatibles vous voient alors avec deux adresses issues de deux réseaux différents.
Cette page détecte ce cas de deux façons : elle affiche séparément les adresses IPv4 et IPv6, et compare leurs réseaux (ASN). Si l'une appartient à votre opérateur et l'autre au VPN, un signalement IPv6 apparaît. Pour corriger la situation, désactivez IPv6 sur l'interface réseau du système ou choisissez un service qui fait passer IPv6 dans le tunnel ; le test ne doit alors jamais montrer deux réseaux distincts.
Les fuites DNS
Une fuite DNS se produit quand vos requêtes de noms sortent par le résolveur de votre fournisseur plutôt que par celui du tunnel : votre adresse IP reste cachée, mais les noms de domaine que vous consultez restent visibles pour l'opérateur. Certains VPN gèrent ce point en imposant leur propre résolveur.
IPVitals ne teste pas les fuites DNS pour l'instant : une vérification fiable demande de générer des sous-domaines uniques et d'observer quel résolveur les reçoit, une opération que nous préférons ne pas déclencher depuis une page publique. Cette page explique donc le principe sans le mesurer. Pour contrôler votre configuration, utilisez l'outil de diagnostic de votre opérateur ou examinez le résolveur configuré dans votre système.
Fuseau horaire et langue
Cette partie compare deux repères : d'un côté le fuseau horaire de votre navigateur et la langue qu'il annonce, de l'autre la localisation approximative et le pays calculés à partir de votre adresse IP.
Un écart n'est pas toujours un problème : un voyage, un VPN vers un autre pays, une adresse enregistrée ailleurs qu'à son lieu d'usage ou une langue étrangère choisie volontairement produisent des écarts normaux. Un décalage net et persistant peut toutefois indiquer qu'une partie de votre trafic ne passe pas par le tunnel, ou qu'un réglage du système contredit votre connexion. L'information est donc présentée comme une indication, à interpréter avec le reste du résultat.
Questions fréquentes
Qu'est-ce qu'une fuite WebRTC ?
C'est l'exposition, par l'interface WebRTC du navigateur, de votre adresse IP réelle à un site web alors que ce trafic devrait passer par un VPN ou un proxy. Le site peut ainsi apprendre l'adresse de votre fournisseur malgré le tunnel.
Mes adresses sont-elles envoyées quelque part pendant le test ?
Non. Les adresses candidates sont observées dans votre navigateur et comparées localement ; seule la localisation approximative passe par l'interface /api/geo du site, qui ne conserve rien. Le test ne constitue aucun profil.
Pourquoi une adresse locale apparaît-elle parmi les candidates ?
Le navigateur utilise des noms mDNS aléatoires pour masquer les adresses locales aux sites web. Si une adresse privée apparaît en clair, par exemple 192.168.x.x, ce masquage est peut-être désactivé. C'est une exposition locale, moins grave qu'une adresse publique inattendue, mais elle mérite un coup d'œil.
Le test détecte-t-il les fuites DNS ?
Non, pas pour l'instant, et la page le dit clairement. Nous expliquons ce type de fuite sans le mesurer, car un test fiable demanderait de générer des sous-domaines uniques et d'observer les requêtes côté serveur.
Le test fonctionne-t-il pendant que j'utilise un VPN ?
Oui, c'est même son usage principal. Si le VPN est correctement configuré, aucune adresse inattendue n'apparaît. Une adresse publique différente accompagnée d'un fuseau horaire identique est bon signe ; une adresse d'opérateur à côté d'une adresse VPN peut au contraire indiquer une fuite IPv6.
Pourquoi mon fuseau horaire ne correspond-il pas à mon adresse IP ?
Voyage, VPN vers un autre pays, changement d'heure mal pris en compte, adresse enregistrée dans une autre région : les raisons sont nombreuses. L'écart devient intéressant s'il est important et persiste à chaque test.