Inside a WebView the page's secure transport is whatever the embedding app configured, and the defaults are hostile. Android blocks mixed content since Pie but ships no certificate pinning and a default onReceivedSslError that aborts silently; countless apps "fix" the blank page by calling handler.proceed() and trusting every certificate, which Google Play rejects and a man-in-the-middle defeats. iOS WKWebView leans on App Transport Security yet exposes no clean per-request pinning API. A host-owned runtime ships one transport policy: enforce HTTPS, pin certificates, fail closed, and surface a real, explainable error instead of a dead screen.
Android: mixed content blocked, but certificates are your problem
Since Android 9 (Pie, API 28) WebView blocks mixed content by default — an HTTPS page may not pull scripts, images, or iframes over plain HTTP. Before that, the default allowed it. To relax the rule you call setMixedContentMode, but every looser mode (COMPATIBILITY or ALWAYS_ALLOW) weakens the guarantee and is explicitly discouraged for production.
The bigger trap is certificates. When the WebView hits an untrusted, expired, or mismatched cert, WebViewClient.onReceivedSslError fires and the default action is to cancel the load — a silent blank page. The "obvious" fix developers copy from Stack Overflow is handler.proceed(), which accepts any certificate and disables all validation. Google Play actively rejects apps that ignore SSL errors this way, and it hands a network attacker a free man-in-the-middle position. WebView also ships no built-in certificate pinning: pinning a known-good public key requires hand-rolling a network layer, which almost nobody does.
iOS: ATS blocks cleartext, but the cert path is coarse
WKWebView benefits from App Transport Security, which blocks cleartext HTTP by default and only allows exceptions through explicit Info.plist entries. But certificate handling is coarse: cert errors surface as a generic authentication challenge (didReceiveAuthenticationChallenge with a server-trust protection space), with no per-request pinning API and no built-in "show the user what went wrong" flow. The common dev shortcut is to accept the server trust unconditionally — fine on a test device, a rejection risk and a security hole in production. Older iOS versions had no SSL-error hook on WKWebView at all, so a bad cert simply failed.
What you lose without a unified transport policy
- Mixed content fails quietly. Scripts and images blocked by a silent default leave a broken page with no visible reason.
- Blind cert acceptance. handler.proceed() / unconditional trust turns every Wi-Fi into a possible interception point.
- No pinning. A compromised or misissued CA can mint a "valid" certificate for your domain and the WebView will accept it.
- Silent failures. The default cert-error path is a blank screen, not an error the user or the app can act on.
- No consistency. Android and iOS diverge in defaults, APIs, and failure modes, so the same page behaves differently per platform.
The runtime fix
A host-owned runtime ships one transport policy below the page. It enforces HTTPS and HSTS, pins the server's public key so a rogue CA cannot impersonate it, fails closed on any cert validation error, and — instead of a blank screen — renders a real, explainable error with a safe, clearly-labeled override. The page gets a single, predictable secure-transport contract on every platform, and the host can prove the connection was actually protected.
| Dimension | WebView | Host-owned runtime |
|---|---|---|
| Mixed content | Blocked by default since Pie; relax weakens it | Enforced, no silent downgrade |
| Cert error default | Silent cancel / blank page | Fail closed, explainable error |
| Cert pinning | None built in, must hand-roll | Enforced per origin |
| iOS cert path | Coarse server-trust challenge | Unified policy, same API surface |
| MITM exposure | High if proceed() used | Closed by pinning + strict validation |
| Cross-platform | Divergent defaults and APIs | One contract everywhere |
A browser earns trust by making the secure path the default and the insecure path visible. A stock WebView makes the insecure path the tempting shortcut and the failure path a blank screen. A runtime restores the contract: HTTPS enforced, certificates pinned, errors explained, and no silent downgrade the user never agreed to.
Sources
- Android Developers — WebSettings.setMixedContentMode: mixed content blocked by default since API 28, looser modes discouraged — the silent mixed-content default.
- Android Developers — WebViewClient.onReceivedSslError: default cancels; Google Play rejects handler.proceed() — the blank-page trap and its dangerous "fix".
- Apple Developer — App Transport Security: cleartext HTTP blocked by default — the iOS baseline.
- Apple Developer — WKNavigationDelegate webView(_:didReceive:completionHandler:): server-trust challenge, no per-request pinning — the coarse iOS cert path.
- web.dev — Web on Android: WebView delegates security-sensitive behavior to the embedding app — why transport security is app-side, not web-side.
