Le 4 août 2026, les chercheurs de Mysk ont publié une analyse de trois mécanismes WebKit qui envoient du trafic en contournant un proxy configuré — directement depuis l'appareil. Tous les navigateurs iOS en mode proxy, y compris les navigateurs Tor, ainsi que le propre service d'Apple — iCloud Private Relay, sont concernés. Le proxy est activé, l'interface affiche un pays étranger, mais le site voit votre véritable IP et votre résolveur DNS domestique.
Ce n'est pas une vulnérabilité exotique pour les paranoïaques. C'est une démonstration claire d'une règle architecturale que tout le monde travaillant via un proxy devrait comprendre : le proxy au niveau de l'application ne protège que le trafic qui passe par la pile réseau de cette application. Tout ce que génère le système d'exploitation ou un service système distinct passe à côté.
Qu'est-ce qui fuit exactement
L'étude a commencé par une situation banale : un utilisateur du navigateur proxy Psylo s'est plaint auprès du développeur d'une fuite DNS. L'analyse de la plainte a révélé trois canaux de fuite indépendants — tous se trouvent dans WebKit lui-même, et non dans une application spécifique.
1. DNS prefetching — le plus simple et le plus désagréable
Mécanisme : la balise <link rel="dns-prefetch"> demande au navigateur de résoudre à l'avance le nom d'hôte pour accélérer le chargement futur. Le problème est que WebKit sur iOS résout ces noms par le chemin DNS normal de l'appareil, et non par le proxy.
Safari sur bureau prend en charge le dns-prefetch depuis Safari 5, mais iOS a ignoré cette balise — jusqu'à iOS 26.0 (septembre 2025). À ce moment-là, WebKit l'a activée dans le cadre du même changement qui a supprimé l'ancien dns-prefetching spéculatif implicite (bug 285744).
Comment cela est exploité : la page intègre dans ces balises des noms d'hôtes uniques pour chaque visiteur, puis observe simplement comment les requêtes arrivent sur son propre serveur DNS autoritaire — depuis l'adresse réelle du réseau du visiteur. Pas de JavaScript, pas d'interaction avec l'utilisateur. Il suffit d'ouvrir la page.
2. WebAuthn Related Origin Requests — fuite via le passeport de passkey
Ce canal est apparu avec iOS 18.0. Lorsque le site demande des informations d'identification WebAuthn (c'est-à-dire un passkey), le système vérifie le fichier https://<rpId>/.well-known/webauthn — pour s'assurer que le domaine est effectivement lié à la partie de confiance indiquée.
Détail clé : cette requête de vérification ne provient pas de la pile réseau du navigateur. Elle est exécutée par le service d'identifiants du système d'exploitation, qui envoie lui-même la requête HTTPS directement depuis l'appareil. Le proxy configuré dans le navigateur n'en a tout simplement pas connaissance (bug 268426).
Autrement dit, il suffit que la page initie une requête de passkey — et le serveur de l'attaquant obtient une connexion depuis votre véritable IP.
3. WebTransport — QUIC directement depuis l'appareil
Le canal le plus récent. L'appel new WebTransport(url) ouvre une connexion QUIC directement depuis l'appareil, contournant la configuration du proxy. WebTransport dans WebKit a longtemps été désactivé et a été rendu public dans iOS 26.4 en mars 2026 (bugs 260810 et 303453).
Qui est concerné
Apple exige que tous les navigateurs sur iPhone utilisent WebKit. Par conséquent, chaque navigateur iOS qui s'appuie sur l'API proxy de WebKit est concerné — y compris toutes les versions iOS des navigateurs Tor et Psylo, qui a lancé l'enquête. De plus, Safari et iCloud Private Relay.
Ce qui n'est pas concerné — les applications VPN. Elles fonctionnent au niveau système et encapsulent tout le trafic de l'appareil dans son ensemble, y compris celui généré par les services système. C'est là toute la différence : le tunnel système n'a pas de « contournement ». Une exception distincte — Onion Browser au niveau de sécurité Silver avec le mode Lockdown activé : il est immunisé contre la fuite via WebTransport.
Du côté des développeurs, la réaction est déjà là. Dans Psylo 1.3.1, tous les trois canaux ont été fermés : l'application bloque les suggestions de dns-prefetch (la page ne peut plus forcer l'appareil à résoudre des noms sous le contrôle de l'attaquant), et WebTransport ainsi que WebAuthn sont désactivés par défaut — ils peuvent être activés de manière ciblée, par des interrupteurs distincts. Selon les informations disponibles au moment de la publication, Apple devrait résoudre les problèmes dans une future mise à jour ; la société n'a pas donné de délais précis.
Pourquoi cela n'a-t-il été découvert que maintenant
La chronologie ici est révélatrice, et elle mérite d'être examinée séparément — elle explique pourquoi le problème n'a pas été remarqué plus tôt.
- Septembre 2024, iOS 18.0 — le mécanisme WebAuthn Related Origin Requests apparaît. Le canal de fuite existe depuis presque deux ans et n'a été discuté par personne durant tout ce temps : la vérification de domaine pour le passkey semble être un élément de sécurité, et non un moyen de révéler une adresse.
- Septembre 2025, iOS 26.0 — WebKit active le support du dns-prefetch sur les appareils mobiles. Formelement, c'est une optimisation de la vitesse de chargement ; en réalité, la page obtient la possibilité de forcer l'appareil à interroger un nom DNS arbitraire en contournant le proxy.
- Mars 2026, iOS 26.4 — WebTransport est activé publiquement. Troisième canal.
- Août 2026 — la plainte d'un utilisateur concernant une fuite DNS conduit à une analyse qui révèle les trois canaux simultanément.
Le dénominateur commun : aucune de ces fonctionnalités n'a été conçue comme un canal de dé-anonymisation. Les trois sont des capacités normales de la plateforme : accélération de la résolution, vérification de passkey, transport moderne. Elles deviennent des fuites uniquement en combinaison avec le mode proxy au niveau de l'application, et c'est pourquoi personne ne les a testées dans ce sens pendant des années.
La conclusion pour la pratique est simple et désagréable : l'absence de nouvelles concernant les fuites ne signifie pas leur absence. Il faut vérifier soi-même et régulièrement, et ne pas attendre que quelqu'un publie une analyse.
Comment se vérifier
Les chercheurs ont mis en ligne un stand public — leaks.psylo.app. Il vérifie trois choses : le trafic HTTPS normal (quelle IP et quels résolveurs DNS le serveur voit), WebTransport et la combinaison WebAuthn + dns-prefetch. Ouvrez-le avec le proxy activé et comparez le résultat avec l'adresse que vous vous attendez à voir.
Il est également important de vérifier l'hygiène de base — si l'IP, le DNS et l'adresse WebRTC correspondent dans votre configuration de travail. Si vous ne vous êtes pas occupé de cela systématiquement auparavant, commencez par notre analyse : comment vérifier un proxy pour une fuite DNS.
Conclusion pratique : la couche a son importance
L'histoire avec WebKit est un cas particulier d'une règle générale qu'il vaut la peine de garder à l'esprit lors de tout travail via un proxy, sur n'importe quelle plateforme.
- Proxy dans le navigateur ≠ proxy sur l'appareil. La configuration à l'intérieur de l'application couvre exactement le trafic que l'application envoie elle-même. Les services système, les processus en arrière-plan, les mises à jour, les connexions push et, comme il s'est avéré, le service passkey intégré — tout cela suit son propre chemin.
- Les fuites ne se produisent pas seulement dans des endroits « connus ». WebRTC est bien connu, et on a appris à le bloquer. Mais le dns-prefetching et la vérification WebAuthn — ce sont des fonctions de performance et de sécurité que personne n'a considérées comme un canal de dé-anonymisation. De nouvelles fonctionnalités des navigateurs créent régulièrement de nouveaux moyens de contournement.
- La mise à jour de la plateforme peut briser votre protection sans bruit. Ici, cela se voit littéralement par les dates : le dns-prefetching a « été activé » dans iOS 26.0, WebTransport — dans iOS 26.4. L'utilisateur n'a rien changé, mais la surface de fuite a augmenté d'elle-même.
Qu'est-ce que cela signifie pour le multi-comptes et l'automatisation
Pour ceux qui gèrent plusieurs comptes ou collectent des données, le risque ici n'est pas abstraitement privé, mais tout à fait financier. Les systèmes anti-fraude des plateformes croisent les signaux : si une session déclare une IP et qu'une requête associée provient d'une autre adresse et d'un résolveur domestique, c'est un motif suffisant pour lier les comptes ou marquer la session comme suspecte.
Conséquences pratiques :
- Ne gérez pas de sessions multi-comptes professionnelles dans des navigateurs mobiles avec un mode proxy. Tant que la plateforme n'a pas colmaté les failles, la couche d'application sur iOS est peu fiable par définition.
- Encapsulez le trafic au niveau système. Si la tâche concerne spécifiquement un environnement mobile, il est plus judicieux de mettre en place un proxy au niveau de l'appareil ou de router via une passerelle distincte, plutôt que de compter sur une configuration à l'intérieur du navigateur.
- Vérifiez la configuration après chaque mise à jour majeure du système d'exploitation et du navigateur. Au moins une fois par trimestre. Intégrez cela dans votre liste de contrôle, et ne le faites pas seulement « quand quelque chose ne va pas ».
- Désactivez ce que vous n'utilisez pas. WebTransport et WebAuthn dans un profil de travail pour le parsing ou le SMM ne sont presque certainement pas nécessaires — les désactiver élimine deux canaux de fuite sur trois.
La qualité de l'IP elle-même reste une variable distincte : même avec une configuration hermétique, une adresse de centre de données se révèle par ASN. Pour les scénarios où il est important de paraître comme un utilisateur ordinaire, des proxies résidentiels fonctionnent, et pour les applications mobiles et les plateformes avec les systèmes anti-fraude les plus stricts — des proxies mobiles avec des IP de véritables opérateurs de téléphonie mobile. Mais aucun type de proxy ne sauvera si une partie du trafic passe physiquement à côté — d'abord l'étanchéité, ensuite la qualité de l'adresse.
Conclusion
Les trois bugs de WebKit — DNS prefetching, WebAuthn Related Origin Requests et WebTransport — ont montré que « le proxy est activé » et « tout le trafic passe par le proxy » sont deux affirmations différentes. Sur iOS, l'écart entre elles s'est avéré suffisamment large pour qu'une page web ordinaire sans une seule ligne de JavaScript puisse connaître la véritable adresse d'un visiteur du navigateur Tor.
Tant qu'Apple prépare un correctif, la seule stratégie efficace est de vérifier, et non de supposer. Ouvrez un stand de test, comparez les adresses, désactivez les API superflues. Et considérez chaque mise à jour majeure du système d'exploitation comme un événement après lequel la configuration doit être vérifiée à nouveau. La différence entre la confidentialité et son illusion réside souvent dans une seule question non posée à temps : « est-ce que tout le trafic passe vraiment ? ». Il est également utile de comprendre quels autres signaux vous trahissent en plus de l'adresse — nous en avons parlé dans notre article sur la protection contre le fingerprinting des navigateurs.