Apple’s iCloud Private Relay is bedoeld om je surfgedrag in Safari en andere iOS-apps te beschermen door webverkeer via twee “relays” te laten lopen. Daardoor zou geen enkele derde partij (ook niet Apple zelf) moeten kunnen herleiden waar je vandaan komt of welke sites je bezoekt. Toch tonen onderzoekers aan dat er in WebKit, de engine achter Safari én veel iOS-browsers, manieren bestaan waardoor de ingestelde proxyroute kan worden omzeild.
Het resultaat: in bepaalde situaties kan je echte netwerk-IP zichtbaar worden voor een website. In dit artikel lees je wat er volgens de onderzoekers misgaat, welke WebKit-onderdelen een rol spelen en hoe je het risico verkleint.
Wat is iCloud Private Relay en waarom zou het je IP verbergen?
iCloud Private Relay werd geïntroduceerd met iOS 15 en maakt deel uit van iCloud+. Het principe is eenvoudig: Safari-webverkeer wordt via een dual-hop architectuur gerouteerd. Daardoor zou een partij niet tegelijk kunnen zien waar het verzoek vandaan komt én naar welke bestemming het gaat.
Onder privacy- en securityperspectief is dit vooral belangrijk voor bescherming tegen het koppelen van een browsing-sessie aan je echte locatie op basis van je netwerkadres. Maar de nieuwe bevindingen wijzen erop dat niet alle soorten verkeer altijd langs de verwachte proxyroute lopen.
De kern van het probleem: WebKit kan proxyverkeer bypassen
Volgens de onderzoekers Talal Haj Bakry en Tommy Mysk ligt de oorzaak in drie WebKit-functies die niet (altijd) meegaan met de proxy-instelling. Daardoor kan verkeer rechtstreeks vanaf het apparaat worden verstuurd, buiten de route die iCloud Private Relay zou moeten afschermen.
Ze beschrijven dat de lekken kunnen voortkomen uit de manier waarop WebKit bepaalde verzoeken afhandelt: DNS prefetching, WebAuthn Related Origin Requests en WebTransport. In combinatie kunnen deze onderdelen ervoor zorgen dat je werkelijke IP-adres buiten het beveiligde pad terechtkomt.
DNS prefetching: hostnamen via het normale DNS-pad
Een van de mechanismen is DNS prefetching. Dit is een techniek waarbij de browser alvast informatie kan opzoeken—bijvoorbeeld hostnamen—om pagina’s sneller te laden.
Het probleem dat de onderzoekers signaleren: bij DNS prefetching worden hostnamen resolven via het normale DNS-pad van het apparaat, niet via het DNS-verkeer dat door de browser/proxy-instellingen zou moeten lopen. Daarmee kan je echte netwerkpad alsnog herkenbaar worden.
WebAuthn Related Origin Requests: credential-service haalt een validatiebestand direct op
Daarnaast noemen de onderzoekers WebAuthn Related Origin Requests. WebAuthn is relevant omdat het websites in staat stelt om in te loggen met passkeys (op basis van een webstandaard).
Wat er mis kan gaan: de operating system’s credential service haalt een validatiebestand rechtstreeks op vanaf het apparaat. Daardoor wordt verkeer mogelijk niet via de proxy gerouteerd, en kan het echte IP-adres van het toestel zichtbaar worden.
WebTransport: een directe HTTP/3-verbinding buiten de proxy
De derde component is WebTransport. Dit opent een directe verbinding met gebruik van HTTP/3. De onderzoekers stellen dat WebTransport in dit scenario de proxy-configuratie kan omzeilen.
In plaats van dat de verbinding volledig via de ingestelde proxyroute verloopt, kan de verbinding daardoor direct contact leggen. Ook dan is het gevolg dat je echte IP-adres kan weglekken.
Voor wie is dit een privacy-risico?
De bevindingen zijn niet alleen van toepassing op Safari. Omdat WebKit ook wordt gebruikt door andere browsers op iOS en iPadOS—zoals onder andere Google Chrome, Microsoft Edge, Firefox en Brave—kan het risico breder gelden zolang die browsers WebKit’s proxyconfiguratie-API’s gebruiken.
Ook wordt aangegeven dat dit probleem macOS kan raken, dus in het algemeen: alle omgevingen die afhankelijk zijn van WebKit en de betreffende proxy-instellingen.
Niet elk scenario leidt echter tot dezelfde mate van lekken. De onderzoekers benoemen dat niet elke browser getroffen is (ze noemen expliciet dat desktop Chrome niet hetzelfde patroon volgt) en dat sommige omstandigheden de impact verminderen, zoals het gebruik van een VPN.
Hoe kan een website je echte IP daadwerkelijk in kaart brengen?
Belangrijk detail: de onderzoekers geven aan dat de bug niet “per ongeluk” automatisch alle data exposeert. Een website moet het mechanisme bewust benutten om een sessie te koppelen aan het gelekte IP-adres.
Volgens Mysk hoeft dit niet te gebeuren met gebruik van passkeys en vereist het geen extra interactie van de gebruiker. Het misbruik draait om de manier waarop een website WebAuthn kan configureren of WebKit-verkeer kan triggeren zodat de “lekken” plaatsvinden.
Met andere woorden: het risico gaat over het kunnen associëren van jouw actuele sessie met je echte netwerkadres, terwijl Private Relay aan staat.
Een proof-of-concept om te testen: leaks.psylo.app
Om het effect inzichtelijk te maken, is er een proof-of-concept website gepubliceerd: leaks.psylo[.]app. Daarmee kunnen gebruikers nagaan of hun echte IP-adres kan lekken wanneer iCloud Private Relay actief is.
In de demo worden onderdelen onderscheiden. Zo verwijst het instrument onder meer naar een sectie voor “HTTPS Traffic” (het reguliere netwerkverkeer dat WebKit genereert) en een sectie “Possible IP leaks” die laat zien op welke manieren de echte IP buiten het verwachte proxypad kan belanden.
Wanneer vermindert een VPN het risico?
De onderzoekers geven aan dat de lekken worden gemitigeerd wanneer een gebruiker is verbonden met een VPN. Dat ligt voor de hand: doordat het VPN-transport de zichtbaarheid van je echte IP naar buiten toe verandert, wordt het nut van een IP-lek kleiner.
Let wel: een VPN is geen “officiële patch” van de onderliggende WebKit-afhandeling, maar het kan wel praktisch helpen om te voorkomen dat een website het echte netwerkadres direct kan gebruiken.
Geschiedenis: eerdere privacyproblemen rond iCloud-onderdelen
Dit is niet de eerste keer dat er security- of privacykwesties rond iCloud-privacyfuncties worden gemeld. Kort na de introductie in 2021 wees FingerprintJS al op een mechanisme dat via WebRTC echte IP-informatie kon lekken.
Bovendien komt de onthulling niet los van eerdere bevindingen rond Apple’s Hide My Email-dienst, waarbij onder bepaalde omstandigheden echte e-mailadressen zichtbaar konden worden. Dat ondermijnde de privacyclaims van die functionaliteit.
Het patroon is duidelijk: privacybeschermende features zijn complex, en zelfs wanneer de bedoeling correct is, kunnen specifieke browser- of OS-mechanismen alsnog gaten veroorzaken.
Wat kun je nu doen?
Zolang er geen definitieve reparatie beschikbaar is, kun je als gebruiker in elk geval je blootstelling inschatten en beheersen.
- Test met een PoC om te kijken of “Possible IP leaks” bij jouw setup relevant is.
- Gebruik een VPN als je je netwerk-IP extra afgeschermd wilt houden.
- Wees alert bij websites die passkey- en WebAuthn-functionaliteit claimen, zeker als je vermoedt dat ze geautomatiseerde of privacy-gevoelige tracking willen doen.
Daarnaast is het verstandig om te wachten op updates van Apple en je besturingssysteem en browsers te onderhouden. Onderzoekers geven aan dat Apple de rapportage onderzoekt, maar een concrete fix of planning ontbreekt in de berichtgeving die hiervoor is gebruikt.
Waarom dit onderwerp breder raakt dan alleen iCloud Private Relay
De kernboodschap gaat verder dan één dienst: het laat zien hoe privacybescherming kan worden beïnvloed door de manier waarop een browser-engine (hier: WebKit) bepaalde netwerkfuncties verwerkt.
DNS-resolutie, credential-validaties en geavanceerde transportprotocollen zijn stuk voor stuk onderdelen die in de praktijk vaak “net iets anders” lopen dan het hoofdpad van proxyverkeer. Daardoor kan een privacyroute alsnog worden omzeild, zelfs als de gebruiker denkt dat alles afgeschermd is.
Voor organisaties betekent dit dat privacy- en securitybewaking niet alleen draait om “staat de juiste knop aan?”, maar ook om de onderliggende technische afhandeling en de risico’s bij specifieke gebruikscases, zoals passkeys en webstandaarden.
Conclusie
Onderzoekers tonen aan dat iCloud Private Relay in bepaalde situaties niet volledig kan voorkomen dat websites je echte IP-adres zien. De oorzaak ligt volgens hen in WebKit-functies die de proxyroute bypassen: DNS prefetching, WebAuthn Related Origin Requests en WebTransport.
Je kunt het risico voor jouw situatie verkennen met de gepubliceerde proof-of-concept, en het effect vaak verminderen door een VPN te gebruiken. Tegelijkertijd is dit een duidelijke reminder dat privacybescherming technisch tot op het detailniveau moet kloppen—zeker wanneer passkeys en modern webtransport in beeld komen.
Wil je meer lezen over de bredere context van privacy, identiteiten en securitymaatregelen? Dan is ook een artikel over governance en compliance in cyberrisk relevant voor het volwassen maken van je beveiligingsaanpak: Governance vs compliance in cyberrisk: toekomstbestendig.
Bron: https://thehackernews.com/2026/08/webkit-proxy-bypasses-can-expose-real.html
