Désactiver WebRTC dans Firefox : la méthode, et les réglages plus doux qui suffisent souvent

Pour désactiver WebRTC dans Firefox, ouvrez about:config, cherchez media.peerconnection.enabled et passez la valeur à false. La procédure tient en moins d'une minute. La vraie question est de savoir si vous avez besoin de cette coupure totale : Firefox propose trois préférences plus fines qui retirent les adresses qui posent problème tout en laissant les appels vidéo utilisables. Ce guide présente les deux voies, puis la manière de vérifier ce que votre navigateur expose réellement.

Désactiver WebRTC dans Firefox, étape par étape

Les étapes suivent l'article d'assistance de Mozilla sur l'éditeur de configuration (les libellés ci-dessous sont ceux de la version anglaise, votre Firefox les affiche dans sa langue).

1. Saisissez about:config dans la barre d'adresse et validez.
2. Une page d'avertissement peut s'afficher. Cliquez sur le bouton qui accepte le risque et poursuit (Accept the Risk and Continue).
3. Dans le champ de recherche de préférence, saisissez media.peerconnection.enabled.
4. Double-cliquez sur la ligne, ou cliquez sur son bouton de bascule (Toggle). La valeur passe de true à false et la ligne s'affiche en gras.

Il n'y a rien à enregistrer, et l'article de Mozilla ne mentionne aucun redémarrage obligatoire. Rechargez simplement les onglets déjà ouverts pour que leurs scripts repartent avec le nouveau réglage.

Pour revenir en arrière, retrouvez la même ligne et cliquez sur le bouton de réinitialisation (Reset). Mozilla précise que seules les préférences modifiées, celles en gras, peuvent être réinitialisées.

Ce que fait réellement cet interrupteur

La page de Mozilla sur la confidentialité de WebRTC résume media.peerconnection.enabled en une ligne : la préférence active ou désactive la possibilité de créer des objets RTCPeerConnection. Sa valeur par défaut est true, sur cette page comme dans le code source de Firefox consulté le 7 octobre 2026.

RTCPeerConnection est l'objet qu'une page web utilise pour établir une connexion directe entre deux navigateurs. Avant de se connecter, il rassemble une liste d'adresses réseau, les candidats ICE, que le JavaScript de la page peut lire. C'est l'origine de l'expression « fuite WebRTC ». La RFC 8828, le standard de l'IETF sur la gestion des adresses IP par WebRTC, décrit le cas qui concerne le plus les utilisateurs de VPN : quand le VPN et le système d'exploitation autorisent le routage sur plusieurs interfaces, WebRTC peut découvrir non seulement l'adresse publique du VPN, mais aussi l'adresse publique du fournisseur d'accès par laquelle passe le VPN.

Avec la préférence à false, le tableau comparatif de la page de Mozilla est sans nuance : aucun candidat local, aucun candidat externe, aucun candidat relais. Rien n'est collecté, puisque l'objet ne peut plus être créé.

Le prix à payer est tout aussi net. Tous les sites qui dépendent d'une connexion pair à pair cessent de fonctionner dans ce profil Firefox : les appels passés dans un onglet, le partage d'écran pendant ces appels, les applications web qui envoient des fichiers ou des données de jeu d'un navigateur à l'autre. Les pages classiques, le streaming vidéo et les téléchargements n'en dépendent pas.

Les réglages plus doux : garder les appels, retirer les adresses

Si vous passez encore des appels dans Firefox, la même page de Mozilla liste des préférences qui choisissent quels candidats sont collectés au lieu de les interdire tous. Elles se trouvent toutes dans about:config et se modifient exactement comme l'interrupteur principal.

Trois précisions de cette page méritent d'être lues avant de choisir.

default_address_only est le réglage pensé pour les VPN. Mozilla indique que l'adresse externe collectée est celle de l'interface par défaut et ajoute, entre parenthèses, que pour un VPN il s'agit du point de sortie du VPN. Autrement dit, quand le tunnel porte la route par défaut, l'adresse qui se trouve derrière n'est plus proposée. Le coût annoncé : si votre routeur ne gère pas le « hairpinning », un appel entre deux appareils du même réseau domestique passe par un serveur TURN externe.

no_host traite l'adresse locale. Il retire de la liste les adresses du type 192.168.x.x, le deuxième sujet d'inquiétude de la RFC 8828, qui y voit une surface d'empreinte numérique. Mettre default_address_only et no_host à true revient à peu près à ce que la RFC appelle le « Mode 3 », route par défaut uniquement.

relay_only est l'option stricte qui conserve les appels. Chaque appel transite alors par un serveur relais. La note de Mozilla est franche sur la limite : cela ne cache pas votre adresse externe au serveur TURN lui-même, et si le site ne fournit aucun serveur TURN, aucun candidat n'est produit et l'appel échoue.

Une autre ligne du code source de Firefox est utile à connaître : media.peerconnection.ice.obfuscate_host_addresses vaut true par défaut dans le fichier général de préférences (all.js). C'est le mécanisme qui fait apparaître une adresse locale sous la forme d'un nom aléatoire terminé par .local plutôt que sous forme de nombre.

Quel réglage pour quelle situation

• Vous ne passez jamais d'appel dans Firefox. Utilisez l'interrupteur principal. C'est le seul réglage dont le résultat vide est garanti, et vous ne perdez rien que vous utilisiez.
• Vous utilisez un VPN et passez parfois un appel dans le navigateur. Mettez default_address_only et no_host à true. Des candidats sont toujours collectés, donc les appels peuvent continuer de fonctionner, et ils suivent la route que prend déjà votre trafic.
• Vous avez besoin des appels et votre interlocuteur ne doit connaître aucune de vos adresses. relay_only est l'option documentée, avec les réserves ci-dessus.
• Vous utilisez Firefox sur Android. Les noms des préférences sont les mêmes. Tout dépend de l'accès à about:config dans votre version : saisissez-le dans la barre d'adresse pour le savoir. Si la page ne s'ouvre pas, cette méthode n'est pas disponible sur cette version.

Comment contrôler le résultat

Modifier une préférence ne prouve rien en soi. Regardez ce que le navigateur transmet, avant et après.

1. Connectez votre VPN comme d'habitude.
2. Ouvrez le test de fuite WebRTC de ce site et lancez-le. Il fonctionne dans le navigateur : il ouvre une connexion pair à pair vers un serveur STUN public et liste chaque adresse trouvée dans les candidats, classée locale, publique ou masquée derrière un nom en .local.
3. Notez ce qui apparaît. Une adresse publique qui n'est pas celle du VPN est la fuite à corriger.
4. Modifiez la préférence, rechargez la page et relancez le test.

Avec media.peerconnection.enabled à false, le test ne peut plus créer la connexion, donc aucune adresse ne peut être listée. Avec les réglages plus doux, attendez-vous à voir l'adresse publique du VPN et aucune adresse locale sous forme numérique.

Ce que la désactivation de WebRTC ne corrige pas

Couper WebRTC ferme un canal, et un seul.

Cela ne masque pas votre adresse aux sites que vous visitez. Chaque page voit toujours d'où part votre requête HTTP : le serveur VPN quand le tunnel est actif, l'adresse de votre fournisseur d'accès quand il ne l'est pas.

Cela ne touche pas au DNS. Un navigateur peut avoir WebRTC désactivé et envoyer quand même ses résolutions au serveur de votre fournisseur. C'est un autre test et un autre correctif, détaillés dans le guide pour tester une fuite DNS.

Cela ne règle pas l'IPv6. Si votre VPN ne transporte que l'IPv4, le trafic IPv6 peut circuler hors du tunnel quels que soient les réglages du navigateur. Voir le guide sur la protection contre les fuites IPv6.

C'est enfin un réglage propre à un profil. Un second profil Firefox, un autre navigateur ou une application de bureau dotée de sa propre pile WebRTC gardent leur comportement. Pour passer tous les canaux en revue d'un seul coup, suivez le test de fuite VPN complet.

En bref

media.peerconnection.enabled à false dans about:config désactive entièrement WebRTC dans Firefox, et le bouton de réinitialisation le rétablit. Si vous avez encore besoin d'appels dans le navigateur, media.peerconnection.ice.default_address_only et media.peerconnection.ice.no_host retirent les adresses qui comptent tout en laissant WebRTC actif. Dans les deux cas, lancez un test WebRTC avant et après : le réglage ne vaut que ce que le test montre.