WebKit laisse fuir l'IP et le DNS réels malgré les proxys et iCloud Private Relay
Photo: WebKit project (logo) / LGPL
Une fuite d'IP et de DNS dans WebKit annule la confidentialité que les navigateurs à proxy sont censés apporter sur iOS. Les chercheurs de Mysk ont publié le 4 août 2026 des résultats montrant que trois fonctions distinctes de WebKit ouvrent des connexions directement depuis l'appareil, en ignorant le proxy que le navigateur devait utiliser. Ces trois mêmes chemins échappent également à l'iCloud Private Relay d'Apple.
Il ne s'agit pas d'un exploit distant. Une page n'a rien à casser : elle se contente d'utiliser des fonctions ordinaires de la plateforme web et regarde d'où arrive le trafic.
Les trois fonctions qui contournent le proxy
| Fonction | Ce qui s'échappe | Présente depuis |
|---|---|---|
| DNS prefetch | Résolveurs DNS réels et nom d'hôte demandé | iOS 26.0, septembre 2025 |
| WebAuthn related origin requests | Adresse IP réelle de l'appareil | iOS 18.0, septembre 2024 |
| WebTransport | Adresse IP réelle de l'appareil | iOS 26.4, mars 2026 |
DNS prefetch est une optimisation de vitesse. Une page indique qu'elle aura bientôt besoin d'un nom d'hôte et le moteur le résout à l'avance. Sur iOS, cette résolution passe par le chemin DNS habituel de l'appareil et non par le proxy. Un site peut placer un nom d'hôte unique par visiteur dans cette indication, puis lire les requêtes qui arrivent sur son propre serveur de noms faisant autorité, directement depuis le réseau réel du visiteur.
WebAuthn related origin requests fuit autrement. WebKit confie la cérémonie de passkey au service d'identifiants du système d'exploitation, et c'est ce service qui va chercher lui-même le fichier /.well-known/webauthn du site. La requête part du système et non du navigateur, donc les réglages de proxy du navigateur n'entrent jamais en jeu.
WebTransport est le plus direct des trois. En créer un ouvre une connexion QUIC de l'appareil vers la destination, sans aucun proxy entre les deux.
Pourquoi iCloud Private Relay ne vous sauve pas ici
On décrit souvent Private Relay comme un VPN pour Safari. Il n'en est pas un. Il fait transiter le trafic des pages de Safari par deux relais afin qu'aucun acteur ne voie à la fois qui vous êtes et ce que vous avez demandé. Cette protection couvre le chemin ordinaire de chargement d'une page, et les trois fuites vivent en dehors. Quand le service d'identifiants du système ou un socket QUIC sort de son côté, Private Relay n'est tout simplement pas dans la boucle.
Le même raisonnement explique pourquoi le problème est plus grave sur iPhone qu'ailleurs. Les règles de l'App Store imposent que tout navigateur iOS utilise WebKit, donc un navigateur axé sur la vie privée ne peut pas substituer un moteur qui acheminerait correctement ces chemins. Les navigateurs fondés sur Tor pour iOS héritent de la fuite par construction, tout comme n'importe quelle application qui bâtit son anonymat sur un proxy interne.
Ce qui est corrigé pour l'instant
Les parades viennent pour l'instant des développeurs d'applications et non du moteur. Psylo a publié la version 1.3.1 : elle retire des pages les indications dns-prefetch et désactive par défaut WebTransport et WebAuthn, qui restent activables à la demande. C'est un contournement au niveau de l'application : chaque navigateur concerné doit repérer le problème et désactiver une à une des fonctions utiles. Il n'y a pas de déclaration publique d'Apple, ni de changement annoncé dans WebKit qui traiterait les trois chemins ensemble.
Pourquoi un tunnel système n'est pas concerné
Ce qui compte ici, c'est le niveau où la confidentialité est appliquée. Un proxy configuré dans un navigateur ne couvre que le trafic que ce navigateur décide d'y faire passer, donc tout ce qu'ouvre un autre composant du système file à côté. Un tunnel complet est au contraire appliqué par la pile réseau du système d'exploitation : chaque paquet de chaque processus quitte l'appareil par la même interface, qu'il vienne du chargement d'une page, d'un service d'identifiants ou d'un socket QUIC brut. C'est pour cela que les VPN à tunnel complet restent intacts face aux trois fuites, contrairement aux proxys internes aux navigateurs, et c'est un rappel utile : la confidentialité au niveau du navigateur et celle au niveau du réseau ne règlent pas le même problème.
Pour qui s'appuie aujourd'hui sur un navigateur à proxy, les gestes sont modestes mais réels : mettre l'application à jour si son développeur a livré une parade, cesser de traiter Private Relay comme un outil d'anonymat, et vérifier ce que votre navigateur expose réellement plutôt que de croire l'indicateur affiché.
