Fuite WebRTC : ce que c'est et comment l'éviter

Une fuite WebRTC, c'est votre navigateur qui transmet votre véritable adresse IP à un site web pendant que vous pensez être caché derrière un VPN. Ce n'est pas un bug de votre VPN et ce n'est pas un logiciel malveillant. C'est WebRTC qui fait exactement ce pour quoi il a été conçu : trouver le chemin réseau le plus rapide possible entre deux navigateurs, ce qui suppose de découvrir d'abord votre véritable adresse IP.

Qu'est-ce qu'une fuite WebRTC

WebRTC (Web Real-Time Communication) est l'API du navigateur derrière les appels vidéo, le chat vocal et le transfert de fichiers pair à pair qui fonctionnent sans plugin. Jitsi, Google Meet, le vocal de Discord et la plupart des outils d'appel vidéo dans le navigateur l'utilisent.

Pour connecter deux navigateurs directement au lieu de relayer chaque paquet par un serveur, WebRTC doit connaître la véritable adresse IP de chaque côté. Il l'obtient grâce à STUN (Session Traversal Utilities for NAT), une requête légère qui demande à un serveur « quelle est mon IP publique vue de l'extérieur de mon routeur ? ». Cette requête passe par la pile réseau propre au navigateur, et non par le tunnel que le client de votre VPN a mis en place pour le reste de votre trafic. Si votre VPN ne l'intercepte pas explicitement, la réponse STUN revient avec votre véritable IP, et n'importe quelle page exécutant du JavaScript WebRTC peut la lire.

Comment la fuite se produit réellement

1. Une page charge du code WebRTC (un widget d'appel vidéo, un script de fingerprinting d'une régie publicitaire, tout ce qui appelle RTCPeerConnection).
2. Le navigateur envoie une requête STUN pour découvrir son IP publique dans le cadre de la collecte des candidats ICE.
3. Cette requête sort par la pile réseau du système d'exploitation, là où, dans la plupart des configurations VPN, le tunnel devrait l'intercepter, mais souvent ne le fait pas.
4. Le JavaScript de la page lit directement les candidats IP renvoyés, sans aller-retour serveur, et dispose désormais de votre véritable adresse.

C'est aussi pour cela que la solution n'est pas aussi simple que « bloquer WebRTC ». STUN, TURN et ICE sont le mécanisme même qui rend les appels vidéo pair à pair rapides, et le même processus de collecte des candidats documenté par MDN pour créer des applications WebRTC est celui qui fait fuir votre IP par effet de bord. Notre comparatif STUN vs TURN vs ICE et notre guide de l'architecture WebRTC expliquent comment fonctionne cette négociation si vous voulez la mécanique en détail.

Ce qui est réellement exposé

Le risque concret est le recoupement, pas le vol de données. Si un site ou un annonceur parvient une fois à relier votre session VPN à votre véritable IP, il peut potentiellement associer votre navigation « anonyme » à votre identité ou à votre localisation réelles lors de visites ultérieures.

Comment tester une fuite WebRTC

Connectez votre VPN, puis ouvrez browserleaks.com/webrtc ou ipleak.net. Les deux listent toutes les adresses IP que la pile WebRTC de votre navigateur est prête à communiquer. Comparez-les à l'IP de votre VPN (vérifiez-la séparément sur n'importe quelle page « quelle est mon IP » avec le VPN activé).

Si vous préférez l'observer vous-même plutôt que de vous fier à un site tiers, ouvrez les DevTools (F12), allez dans l'onglet Network et chargez l'une des pages de test ci-dessus avec les filtres WebSocket/other désactivés. Vous verrez partir la requête STUN et revenir les IP candidates dans la réponse, les mêmes données que le site de test se contente de mettre en forme.

Vous pouvez aussi faire la vérification sans site tiers : ouvrez notre testeur ICE WebRTC avec le VPN activé, choisissez le préréglage STUN et collectez les candidats. Si un candidat server reflexive affiche votre véritable IP publique au lieu de celle du VPN, c'est la fuite.

Corriger une fuite IP WebRTC selon le navigateur

Comme un interrupteur qui coupe complètement WebRTC casse les appels vidéo légitimes, une extension de navigateur qui restreint le routage de WebRTC au lieu de désactiver toute l'API est la solution la plus pratique pour la plupart des gens. Chrome expose une API de confidentialité qui permet à une extension de régler webRTCIPHandlingPolicy sur disable_non_proxied_udp, ce qui oblige WebRTC à passer par l'interface proxy ou VPN configurée au lieu de sortir directement. WebRTC Leak Prevent est une extension actuelle et open source basée précisément sur cette API.

Quelle que soit la solution choisie, refaites ensuite le test de la section précédente. Les mises à jour du navigateur désactivent les extensions plus souvent qu'on ne le pense.

Le rôle de votre VPN

Tous les VPN ne gèrent pas cela de la même façon, et les arguments marketing (« chiffrement de niveau militaire », « anonymat total ») ne disent rien sur WebRTC en particulier. Avant de compter sur un VPN pour couvrir ce point, cherchez :

• Une mention explicite de la protection contre les fuites WebRTC dans la documentation du VPN, pas seulement une protection contre les fuites DNS ou un kill switch (ce sont des mécanismes différents)
• Une extension de navigateur du même éditeur, car le blocage des fuites WebRTC est généralement mis en œuvre au niveau de l'extension, et non dans le client VPN du système d'exploitation
• Des résultats de tests indépendants, pas seulement les affirmations de l'éditeur

Vérifiez ensuite vous-même avec le test précédent, sur le navigateur et l'appareil que vous utilisez au quotidien. Un VPN qui bloque les fuites WebRTC sur Chrome pour ordinateur ne fait pas forcément de même dans son application mobile.

Si vous préférez ne pas dépendre de la parole d'un éditeur de VPN tiers pour tout cela, la solution est de faire tourner le vôtre. Notre comparatif des VPN auto-hébergés couvre des installations OpenVPN, WireGuard et Headscale dans lesquelles vous contrôlez la configuration du client de bout en bout.

Si vous développez avec WebRTC

Si c'est vous qui faites tourner l'infrastructure de visioconférence, et non pas seulement l'utilisateur, la question des fuites s'inverse : vous voulez une découverte d'IP précise pour que les appels se connectent en pair à pair au lieu d'être relayés par un serveur TURN à chaque session. La question de confidentialité devient alors ce que fait votre propre code côté client des IP candidates qu'il collecte, et si vous les journalisez quelque part où vous ne devriez pas. Les déploiements auto-hébergés (par exemple Jitsi derrière votre propre instance coturn) vous donnent sur ce flux de données une visibilité qu'un outil SaaS hébergé n'offre pas.

Les adresses IP sont des données personnelles au sens du RGPD et de réglementations similaires : si votre application sert des utilisateurs dans l'UE, journaliser les IP candidates brutes des sessions WebRTC est une décision à prendre délibérément plutôt que par défaut. Consultez nos notes sur les déploiements WebRTC conformes au RGPD et nos bonnes pratiques de sécurité pour Jitsi Meet si c'est vous qui exploitez l'infrastructure et pas seulement un utilisateur.

STUN vs TURN vs ICE: WebRTC NAT Traversal Explained

STUN vs TURN vs ICE explained plainly: what each one actually does, why WebRTC calls fail behind NAT, and when you need your own TURN server.

By Binuka Ranatunga • Meetrix.io