Three WebKit Features Walk Straight Past Your Proxy

Set WKWebsiteDataStore.proxyConfigurations on a WebKit view and you'd reasonably assume every packet that view generates goes through your proxy. It doesn't. Mysk — Talal Haj Bakry and Tommy Mysk — found three web platform features that open connections straight off the device, past the proxy, from a page the user merely visited: DNS prefetching, WebAuthn Related Origin Requests, and WebTransport. The same three walk past iCloud Private Relay in Safari.

Read those as three bugs and you'll patch three things and wait for the fourth. They're one bug with three faces.

The proxy setting only covers the traffic WebKit owns

proxyConfigurations arrived in iOS 17 and macOS 14 and does exactly what it says: it proxies WebKit's network process. The problem is that a growing share of what a modern web page can trigger doesn't originate in WebKit's network process.

DNS prefetching is resolved by the system resolver, so a <link rel="dns-prefetch"> hint gets answered by whatever DNS servers the device is actually configured with. Mysk's write-up notes the obvious weaponization: a hostile page embeds a hostname unique to each visitor and watches its own authoritative nameserver for the query. That's not passive telemetry, it's a de-anonymization primitive that links a session to a resolver, an ISP, and often a metro area.

WebAuthn is worse, architecturally. When a page calls navigator.credentials.get() with an rpId that doesn't match the origin, the Related Origin Requests flow validates it by fetching https://<rpId>/.well-known/webauthn. On Apple platforms that fetch is issued by the OS credential service, not by the browser — a different process, on a different network path, one the browser has no handle on. Mysk reports it fires without user interaction. Compare Chrome, where the browser performs that same well-known fetch itself and it inherits the browser's proxy config; the standard isn't the problem, the delegation is.

WebTransport is the simplest of the three. new WebTransport(url) opens a QUIC session, and the QUIC path was never offered the proxy, so the server on the far end sees the device's address.

The part that should sting is Private Relay

Apple's own description of Private Relay puts DNS resolution inside the protected set — Safari browsing, DNS queries, and insecure app traffic. A dns-prefetch tag defeats that with markup, no JavaScript required. This isn't the familiar and fair caveat that Private Relay is not a VPN and doesn't cover other apps. This is a page loaded in Safari, generating a lookup that Apple says it hides, and the lookup arriving on the open network anyway.

There's a bleak little detail in the timeline. WebKit's Safari 26.0 notes announce <link rel=dns-prefetch> support arriving on iOS, iPadOS and visionOS with the line "Supported on macOS since Safari 5, it now has improved privacy." Per Mysk, that same release is where the iOS DNS leak begins. And because macOS has carried dns-prefetch since Safari 5, a WebKit-based proxy browser on the Mac may have been leaking this for years — it's just that on macOS you can ship Gecko or Chromium instead, so nobody had to care.

Every engine has lost this fight before

Proxy bypass through a side channel is one of the oldest recurring failures in browsers. Chromium's own network-stack documentation warns that the DNS prefetcher issues local lookups even with a SOCKS5 proxy configured. Firefox needed network.proxy.socks_remote_dns and still shipped CNAME and search-domain leaks around it. Tor Browser's history is a long list of proxy-bypass advisories, which is exactly why the Tor Project's design treats proxy-safety as a property of the whole build rather than a setting.

The lesson those projects converged on: proxy obedience has to be an invariant enforced at the bottom of the stack, with a fail-closed default, so a new feature that forgets to route through it breaks loudly instead of leaking quietly. WebKit has no such switch. proxyConfigurations is a property on a data store, and anything that resolves, connects, or delegates outside that store is silently exempt. Ship a new networking-capable API — and Apple keeps shipping them, WebTransport landed in Safari 26.4 in March 2026 — and you get a new exemption for free.

On the Mac that's a bug. On iOS it's a trap, because you cannot ship your own engine or your own network stack, so you cannot fix it. Onion Browser and Psylo are downstream of Apple's implementation whether they like it or not. BrowserEngineKit exists on paper and, more than two years after the DMA forced it into being, no shipping iOS browser uses an alternative engine. This is the concrete cost of that, and it lands on the users with the highest stakes.

What to do this week

If you ship a WKWebView-based browser, an in-app browser, or anything that proxies WebKit and tells users their traffic is covered, treat all three as live and assume there's a fourth:

• Strip dns-prefetch and preconnect link hints before the page parses them — a WKContentRuleList or a document-start user script, not a post-hoc DOM sweep.
• Turn WebAuthn off unless a user explicitly enables it per session. This costs you passkey sign-in, which is a genuine loss; make it a per-session toggle rather than a global one.
• Turn WebTransport off. Right now this is cheap — the API only became broadly available in March 2026, so almost nothing depends on it. That window closes.
• WebKit's per-webpage Lockdown Mode preference disables WebTransport wholesale, which is how Onion Browser's Silver level avoids that leak, per Mysk. It's a blunt instrument and it breaks pages, but it fails closed, which is the right direction.
• Stop trusting the API and start asserting at the boundary. Point the app at a proxy you control, load a page with all three triggers, and watch your authoritative DNS logs and netflow for anything arriving from the device address. Mysk's checker at leaks.psylo.app reproduces it; put the equivalent in CI.

For everyone else: a system-wide VPN still contains all three, because it operates below the layer where WebKit is making these decisions. That's the honest recommendation and also an indictment — "use a VPN" is not what an application-level proxy API is supposed to require.

Two caveats worth stating plainly. Mysk publishes this alongside the release that fixes it in their own browser, so read it with that in mind — though the findings are trivially reproducible, and at least one independent tester confirmed the WebAuthn leak while getting a muddier result on WebTransport. And there's no CVE, no radar, and no public Apple response or fix commitment attached to any of the three. The bugs are real. The timeline for fixes is currently nobody's.