Fuites WebRTC : comment votre vraie IP échappe à un proxy, et comment les tester et les corriger

Vous configurez un proxy, ouvrez un outil de recherche d’IP, et il affiche l’IP du proxy. Terminé ? Pas toujours. Une page peut encore trouver votre vraie IP via WebRTC, une fonction du navigateur qui ignore par conception les paramètres de proxy de votre navigateur. Si vous utilisez des proxys résidentiels pour voir un site comme le ferait un visiteur local, une fuite WebRTC peut l’annuler sans aucun signe visible.

Ce guide explique comment fonctionne la fuite, comment la tester en deux minutes et comment la fermer dans Chrome, Firefox et les navigateurs automatisés.

Comment la fuite se produit

WebRTC permet aux navigateurs de passer des appels et d’échanger des données directement entre eux. Pour cela, chaque navigateur collecte des « candidats ICE » : des adresses où il peut être joint. Une étape consiste à demander à un serveur STUN, via UDP, « de quelle adresse publique me voyez-vous arriver ? ». La réponse est placée dans un candidat que le JavaScript de la page peut lire.

Le problème est le chemin que prend cette question. Un proxy HTTP typique ne transporte que vos requêtes web, pas l’UDP. La requête STUN sort donc par votre propre connexion, et la réponse est votre vraie IP publique. La RFC 8828, la norme de l’IETF sur la gestion des adresses par WebRTC, le dit sans détour : les vérifications STUN peuvent contourner un proxy et révéler l’IP publique d’un client si l’accès direct à Internet est autorisé. Elle recommande aussi de ne pas envoyer le trafic WebRTC par des proxys par défaut, en raison de la qualité des appels.

Deux détails comptent :

• Les adresses locales sont désormais en grande partie masquées. Chrome et Firefox remplacent votre adresse de réseau privé par un nom .local aléatoire pour la plupart des pages. Dans Firefox, il s’agit du paramètre media.peerconnection.ice.obfuscate_host_addresses, activé par défaut. Votre IP publique est le vrai risque.
• La page n’a besoin d’aucune autorisation. La collecte des candidats ne demande pas l’accès à la caméra ni au microphone, donc il n’y a aucune invite.

Testez en deux minutes

Vous n’avez pas besoin d’un site de test tiers. Ouvrez la page qui vous intéresse, ou n’importe quelle page, avec votre proxy activé, ouvrez la console de développement (F12) et collez ceci :

const pc = new RTCPeerConnection({ iceServers: [{ urls: "stun:stun.l.google.com:19302" }] });
pc.createDataChannel("t");
pc.onicecandidate = (e) => e.candidate && console.log(e.candidate.candidate);
pc.createOffer().then((o) => pc.setLocalDescription(o));

Repérez les lignes qui contiennent typ srflx. L’adresse de cette ligne est l’IP publique que le serveur STUN a vue.

• Si elle correspond à votre IP personnelle ou professionnelle, WebRTC fuit.
• Si elle correspond à l’IP du proxy, ou s’il n’y a aucune ligne srflx, tout va bien.
• Les lignes avec typ host et un nom .local sont votre adresse locale masquée, et elles sont normales.

Comparez ensuite avec un outil de recherche d’IP tel que IP Info dans le même navigateur. Il doit afficher l’IP et la localisation du proxy. Si l’outil affiche le proxy mais que la ligne srflx affiche la vôtre, le proxy fonctionne et WebRTC le contourne.

Corriger dans Chrome

Le plus simple : utiliser une extension qui s’en charge. L’extension de navigateur Shifter active par défaut la protection contre les fuites WebRTC tant que vous êtes connecté. En coulisses, les extensions Chrome contrôlent cela via le paramètre de confidentialité webRTCIPHandlingPolicy. Si une autre extension contrôle déjà WebRTC, une seule des deux peut l’emporter, et l’extension Shifter vous prévient quand sa protection n’est pas active. Supprimez ou désactivez l’autre.

Ordinateurs gérés : Chrome propose une politique d’entreprise, WebRtcIPHandling, avec quatre valeurs :

Valeur	Ce que WebRTC utilise
default	Toutes les interfaces réseau disponibles
default_public_and_private_interfaces	L’interface orientée public, adresses privées autorisées
default_public_interface_only	L’interface orientée public uniquement, sans adresses privées
disable_non_proxied_udp	TCP via le proxy ; UDP seulement si le proxy le prend en charge

Seule disable_non_proxied_udp empêche la fuite de l’IP publique derrière un proxy. Les deux valeurs « interface publique » interrogent encore le serveur STUN par votre propre connexion.

Corriger dans Firefox

L’extension Shifter s’en charge aussi dans Firefox. Pour le faire à la main, ouvrez about:config et définissez :

• media.peerconnection.ice.proxy_only_if_behind_proxy sur true : WebRTC n’utilise le proxy que lorsqu’un proxy est configuré. C’est la correction ciblée.
• media.peerconnection.ice.default_address_only sur true : seule la route par défaut est utilisée. Cela masque les adresses locales supplémentaires, mais n’empêche pas à lui seul la fuite de l’IP publique.
• media.peerconnection.enabled sur false : désactive entièrement WebRTC. C’est l’option la plus radicale, et elle casse les appels dans ce navigateur.

Relancez ensuite le test dans la console : la ligne srflx doit avoir disparu ou afficher l’IP du proxy.

Corriger dans les navigateurs automatisés

Playwright, Puppeteer et Selenium lancent un vrai navigateur, ils fuient donc de la même manière. Pour Chromium, lancez-le avec :

--force-webrtc-ip-handling-policy=disable_non_proxied_udp

Pour Firefox, définissez les mêmes préférences about:config dans le profil que lance votre framework. Exécutez ensuite le test de console ci-dessus depuis votre script et vérifiez le résultat srflx dans le cadre de vos contrôles de configuration. Notre guide sur les proxys résidentiels dans Selenium et Playwright montre où placer ces options.

WebRTC n’est pas la seule fuite

Fermez les failles voisines tant que vous y êtes :

• DNS. Les résolutions de noms peuvent contourner le proxy et se faire depuis votre propre réseau. Notre guide sur la prévention des fuites DNS présente socks5h et la façon de vérifier.
• IPv6. Si votre chemin proxy est uniquement IPv4, un navigateur qui dispose aussi d’IPv6 peut l’utiliser pour certaines requêtes.
• Fuseau horaire et langue. Ils ne révèlent pas votre IP, mais ils peuvent contredire la localisation de votre proxy.

En résumé

Une fuite WebRTC se produit parce que le navigateur demande votre adresse à un serveur STUN via UDP, et que la plupart des proxys ne transportent que le trafic web. Testez-la avec l’extrait de console : si l’adresse srflx est la vôtre, la page peut aussi la voir. Activez la protection contre les fuites dans l’extension Shifter, ou définissez disable_non_proxied_udp dans Chrome et proxy_only_if_behind_proxy dans Firefox, puis testez à nouveau.