Una app nativa comparte un almacén de credenciales con su pila de red. Dentro de un WebView ese almacén está aislado: el jar de cookies es distinto del navegador del sistema y del HTTP nativo, las cookies entre sitios se descartan por las reglas de SameSite, y cada fetch con credenciales necesita un apretón de manos CORS que la página no controla del todo. Un runtime propio del host ofrece un túnel de credenciales: un canal autenticado entre web y nativo.
El WebView guarda su propio jar de cookies
En Android, CookieManager es por perfil de WebView y nunca es el jar del navegador del sistema. En iOS, WKHTTPCookieStore es distinto de NSHTTPCookieStorage, y desde iOS 14 el WebView aplica Prevención de Rastreo Inteligente — las cookies de terceros caducan en siete días y las lecturas entre sitios se bloquean. Una cookie de sesión fijada por un login nativo no llega automáticamente a un fetch() dentro de la página, así que la petición vuelve con 401.
SameSite descarta la credencial en silencio
Chrome 80+ hizo que SameSite=Lax fuera el valor por defecto y exige Secure en cualquier cookie SameSite=None; iOS 15.4+ ata None a Secure y Partitioned o la descarta. Así, una cookie acuñada sin esos atributos simplemente no se envía en una petición entre sitios. Combinado con CORS, un fetch con credenciales necesita Access-Control-Allow-Credentials: true y un Access-Control-Allow-Origin explícito (nunca *) — y un pre-flight fallido lanza un TypeError opaco que la página no puede inspeccionar.
Qué se rompe cuando la auth cruza el muro
- El login funciona y luego da 401. Lo nativo fija la sesión; el
fetchdel WebView nunca la lleva. - El SSO entre subdominios falla. La sincronización de cookies
login.example.com→app.example.comse rompe mientras Safari funciona. - SameSite descarta el token. Una cookie
NonesinSecurese descarta en motores modernos. - El pre-flight lanza errores opacos. Depurar una denegación CORS es a ciegas — retroalimenta la caja negra de depuración del WebView.
- Hacks desesperados. Algunos equipos recurren a
--disable-web-security, imposible en producción y una mina de cumplimiento.
La solución del runtime
Un runtime propio del host controla las credenciales. El host guarda la sesión en un solo almacén y la puentea a la página por un canal autenticado — adjuntando la cookie correcta, respetando SameSite y Secure en la capa nativa, y proxiando las peticiones entre orígenes para que CORS y el pre-flight se manejen donde se pueden ver. Una identidad, web y nativo, cada petición autenticada.
| Dimensión | WebView | Runtime propio del host |
|---|---|---|
| Jar de cookies | Distinto del sistema y nativo | Un solo almacén compartido |
| Cookie entre sitios | Descartada por SameSite | Respetada en capa nativa |
| Fetch con credenciales | Fallo CORS opaco | Tunelizada y visible |
| SSO entre subdominios | Se rompe | Funciona |
| Depuración de pre-flight | TypeError a ciegas | Registrada por el host |
| Seguro por defecto | Fácil de errar | Aplicado |
Una app nativa nunca pierde su sesión en el borde de red. Un WebView común sí lo hace. Un runtime lleva una identidad a través del muro — y autentica cada petición.
Fuentes
- MDN — CORS — el pre-flight, las credenciales y las reglas de
Access-Control-Allow-Originque limitan las peticiones entre orígenes. - web.dev — SameSite cookies explained — por qué
Laxes el valor por defecto yNoneexigeSecure. - Android Developers — CookieManager — el jar por perfil que el WebView guarda aparte del navegador del sistema.
- Apple — WKHTTPCookieStore — el almacén de cookies del WebView, distinto de
NSHTTPCookieStorage. - Chrome for Developers — SameSite updates — el cambio a Lax por defecto en Chrome 80 que rompió las cookies entre sitios no solicitadas.
