The host app cannot control the WebView's network stack. On iOS, WKWebView cannot intercept HTTPS at all — Apple documents that registering a WKURLSchemeHandler for http or https raises NSInvalidArgumentException, and NSURLProtocol-style interception of http/https is unsupported. On Android, shouldInterceptRequest is partial: redirect hops, blob:, and javascript: never fire. That means no host-enforced certificate pinning, no transparent auth, no connection reuse, and no request policy — every page re-establishes TLS and exfiltration to an unknown host is invisible. A host-owned runtime mediates the network at the native layer: pinning, signed auth, allowlist, and unified telemetry the page can never bypass.
The host cannot see the wire
WKWebView's networking runs in a separate network process, and Apple explicitly forbids overriding the built-in http and https handling. The documentation states it is a programmer error to register a handler for a scheme WebKit already handles, such as https, and attempting it raises NSInvalidArgumentException. NSURLProtocol interception of http/https is unsupported in WKWebView — Apple's own developer relation engineer confirmed the only sanctioned path is custom URL schemes. So the host literally cannot sit between the page and its HTTPS requests. Whatever the page fetches, it fetches over the system's own TLS, with the system's own policy, out of the app's reach.
Android is partial, not in control
On Android, shouldInterceptRequest (API 21) lets the host return a response for a resource, but it is not invoked for javascript:, blob:, or android_asset URLs, and for redirects only the initial resource URL — subsequent redirect URLs are never called. Even when it does fire, it cannot transparently add headers to the system's own TLS connection, and it cannot enforce certificate pinning. The control point looks complete in the API reference and leaks in practice: a redirect chain, an inline blob, or a script-initiated fetch quietly bypasses whatever the host thought it had hooked.
What you lose without a controllable network layer
A WebView that the host cannot mediate takes away the controls the rest of the app takes for granted:
- Certificate pinning. The only WebView hook is onReceivedSslError, an after-the-fact error the app may choose to ignore — not real pinning. The MITM defenses that ship in the app's native HTTP client do not apply to WebView traffic.
- Transparent auth. You cannot attach a signed request header or device attestation to every WebView request without a JS bridge the page can detect or block.
- Connection reuse. Each page and each WebView re-establishes TLS; there is no host-level connection pool and no HTTP/3 0-RTT across navigations.
- Request policy. You cannot, at the platform layer, block a page from calling out to an unknown host — data exfiltration is invisible.
- Telemetry. You cannot uniformly measure WebView request latency, failures, and bytes the way you measure native calls.
The runtime fix
A host-owned runtime mediates every request at the native layer, below the page. It pins certificates against a known set and fails closed, injects signed auth and device attestation onto outbound requests so the page never sees them, maintains a host-level connection pool and negotiates HTTP/3, and enforces an allowlist so unknown hosts are blocked before the socket opens. Unified telemetry rides along on every request. The page cannot see or bypass the policy because the policy lives beneath it, in the runtime — not in a bridge it can outrun.
| Dimension | WebView | Host-owned runtime |
|---|---|---|
| HTTPS interception | iOS impossible; Android partial | Native-layer interception, complete |
| Certificate pinning | onReceivedSslError only, bypassable | Enforced pin set, fail-closed |
| Transparent auth | JS-bridge only, detectable | Signed header and attestation, invisible |
| Connection reuse | Per-page TLS, no pool | Host pool plus HTTP/3, 0-RTT |
| Request policy | No platform-level block | Allowlist, block before connect |
| Telemetry | No unified view | Per-request latency, failure, bytes |
The series keeps returning to one fact: a WebView inherits the platform's weakest surfaces and adds a web-shaped one. The network is the most fundamental surface of all — and in a stock WebView it is the one the host is least able to govern. A runtime puts the app back on the wire, so the traffic is the app's to secure, not the system's to decide.
Sources
- Apple Developer Forums — Quinn «The Eskimo»: WKURLSchemeHandler only lets you implement custom schemes, it does not let you override the built-in handling of http and https — the authoritative statement that WKWebView cannot intercept standard HTTPS.
- WebKit Bug 138169 — WKWebView does not support NSURLProtocol-style interception of http or https — the long-standing request for what the platform refuses to provide.
- Android Developers — WebViewClient.shouldInterceptRequest: not called for javascript:, blob:, or asset URLs; only the initial redirect URL — the documented limits of Android's interception hook.
- OWASP MASTG — Network Communication: WebView lacks the browser's security UI; TLS policy and pinning must be enforced at the app layer — why WebView traffic needs app-level controls.
- Web.dev — Web on Android: WebView gives the embedding app full access to rendered content and lacks the browser's security and privacy controls — the structural gap between a WebView and a hardened browser.
