La app host no puede controlar la pila de red de WebView. En iOS, WKWebView no puede interceptar HTTPS en absoluto — Apple documenta que registrar un WKURLSchemeHandler para http o https lanza NSInvalidArgumentException, y la intercepción NSURLProtocol de http/https no es compatible. En Android, shouldInterceptRequest es parcial: los saltos de redirección, blob: y javascript: nunca se disparan. Eso significa que no hay fijación de certificados forzada por el host, ni autenticación transparente, ni reutilización de conexiones, ni política de solicitudes — cada página renegocia TLS y la exfiltración a un host desconocido es invisible. Un runtime propio del host mediatiza la red en la capa nativa: fijación, autenticación firmada, lista blanca y telemetría unificada que la página nunca puede eludir.
El host no puede ver el cable
La red de WKWebView se ejecuta en un proceso de red separado, y Apple prohíbe explícitamente anular el manejo nativo de http y https. La documentación indica que es un error de programación registrar un handler para un esquema que WebKit ya maneja, como https, y al intentarlo se lanza NSInvalidArgumentException. La intercepción NSURLProtocol de http/https no es compatible con WKWebView — el propio ingeniero de relaciones de desarrolladores de Apple confirmó que la única vía sancionada son los esquemas de URL personalizados. Así que el host literalmente no puede interponerse entre la página y sus solicitudes HTTPS. Lo que la página obtenga, lo obtiene sobre el TLS del sistema, con la política del sistema, fuera del alcance de la app.
Android es parcial, no está bajo control
En Android, shouldInterceptRequest (API 21) permite al host devolver una respuesta para un recurso, pero no se invoca para javascript:, blob:, ni URL android_asset, y en redirecciones solo para la URL de recurso inicial — las URL de redirección subsiguientes nunca se llaman. Incluso cuando se dispara, no puede agregar encabezados de forma transparente a la conexión TLS del sistema, ni puede forzar la fijación de certificados. El punto de control parece completo en la referencia de la API y pierde en la práctica: una cadena de redirección, un blob en línea o un fetch iniciado por script eluden silenciosamente lo que el host creía haber enganchado.
Qué pierdes sin una capa de red controlable
Un WebView que el host no puede mediatizar quita los controles que el resto de la app da por sentados:
- Fijación de certificados. El único gancho de WebView es onReceivedSslError, un error a posteriori que la app puede ignorar — no es fijación real. Las defensas anti-MITM que trae el cliente HTTP nativo de la app no se aplican al tráfico de WebView.
- Autenticación transparente. No puedes adjuntar un encabezado de solicitud firmado o una atestación de dispositivo a cada solicitud de WebView sin un puente JS que la página pueda detectar o bloquear.
- Reutilización de conexiones. Cada página y cada WebView renegocia TLS; no hay grupo de conexiones a nivel host ni HTTP/3 0-RTT entre navegaciones.
- Política de solicitudes. No puedes, a nivel de plataforma, bloquear que una página llame a un host desconocido — la exfiltración de datos es invisible.
- Telemetría. No puedes medir uniformemente la latencia, los fallos y los bytes de las solicitudes de WebView como lo haces con las llamadas nativas.
La solución en runtime
Un runtime propio del host mediatiza cada solicitud en la capa nativa, por debajo de la página. Fija los certificados contra un conjunto conocido y falla cerrado, inyecta autenticación firmada y atestación de dispositivo en las solicitudes salientes para que la página nunca las vea, mantiene un grupo de conexiones a nivel host y negocia HTTP/3, y aplica una lista blanca para que los hosts desconocidos se bloqueen antes de abrir el socket. La telemetría unificada acompaña a cada solicitud. La página no puede ver ni eludir la política porque la política vive por debajo de ella, en el runtime — no en un puente que pueda dejar atrás.
| Dimensión | WebView | Runtime propio del host |
|---|---|---|
| Intercepción HTTPS | iOS imposible; Android parcial | Intercepción en capa nativa, completa |
| Fijación de certificados | solo onReceivedSslError, evasible | Conjunto fijado, falla cerrado |
| Autenticación transparente | solo puente JS, detectable | Encabezado firmado y atestación, invisible |
| Reutilización de conexiones | TLS por página, sin grupo | Grupo host + HTTP/3, 0-RTT |
| Política de solicitudes | Sin bloqueo a nivel plataforma | Lista blanca, bloquea antes de conectar |
| Telemetría | Sin vista unificada | Latencia, fallo y bytes por solicitud |
La serie vuelve una y otra vez a un hecho: un WebView hereda las superficies más débiles de la plataforma y agrega una con forma de web. La red es la superficie más fundamental de todas — y en un WebView estándar es la que el host menos puede gobernar. Un runtime devuelve la app al cable, para que el tráfico sea de la app para proteger, no del sistema para decidir.
Fuentes
- Foros de Desarrolladores de Apple — Quinn «The Eskimo»: WKURLSchemeHandler solo permite implementar esquemas personalizados, no anula el manejo nativo de http y https — la afirmación autoritativa de que WKWebView no puede interceptar HTTPS estándar.
- WebKit Bug 138169 — WKWebView no soporta la intercepción estilo NSURLProtocol de http/https — la capacidad que la plataforma se niega a proporcionar.
- Android Developers — WebViewClient.shouldInterceptRequest: no se llama para javascript:, blob: ni assets; solo la URL de redirección inicial — los límites documentados del gancho de intercepción de Android.
- OWASP MASTG — Comunicación de red: WebView carece de la UI de seguridad del navegador; la política TLS y la fijación deben forzarse en la capa de la app — por qué el tráfico de WebView necesita controles a nivel de app.
- Web.dev — Web en Android: WebView da a la app acceso total al contenido renderizado y carece de los controles de seguridad y privacidad del navegador — la brecha estructural entre un WebView y un navegador endurecido.
