Existe un riesgo que no aparece en ninguna hoja de ruta. Una app de consumo embebe un H5 de terceros para entregar un servicio — pagos, préstamos, seguros. La página funciona. Pero el código que corre dentro de tu app es una caja negra que no escribiste, no puedes leer y no puedes impedir que cambie. Si esa caja filtra el número de tarjeta de un usuario, o sirve un formulario de phishing, o se altera en tránsito, el regulador y el usuario golpean tu puerta. No la del proveedor.
He estado en suficientes revisiones post-incidente para saber cómo se juega esto. El host carga con la marca, la licencia y la responsabilidad legal. La página embebida no carga con nada, y nunca se diseñó para hacerlo.
Por qué el H5 es opaco por construcción
Una página H5 dentro de un webview ejecuta código del origen del proveedor. No controlas su contenido, sus dependencias, ni su cadencia de actualización. El proveedor puede empujar un nuevo build a las 2 a.m. y tu app lo está sirviendo una hora después. No hay firma que verifiques, no hay puerta de revisión de tu lado, no hay inventario de qué scripts trae.
Esa opacidad es exactamente lo que los marcos de seguridad señalan. El Mobile Top 10 de OWASP marca la calidad de código débil y la alteración de código como riesgos móviles de primer orden; el cross-site scripting, el ataque web clásico, vive de forma nativa dentro de una superficie H5 porque, al fin, es una página web. Un webview no aísla la página de sí misma — corre lo que sea que el origen sirva.
La exposición de cumplimiento es concreta, no teórica. Los flujos de pago que tocan datos de tarjeta caen bajo PCI DSS, que espera que sepas adónde va el dato del titular y que lo restrinjas. Las apps financieras en la mayoría de las jurisdicciones responden ante un regulador que quiere evidencia de control sobre cada componente que maneja datos del cliente — el DORA de la UE (Ley de Resiliencia Operativa Digital, 2022/2554) convierte la resiliencia operativa y el riesgo de terceros en una obligación de nivel de consejo. Cuando el componente de riesgo es un H5 de terceros que no puedes auditar, respondes esas preguntas con «confiamos en ellos».
Cara a cara
| Dimensión | H5 de terceros embebido | Runtime de mini-programa (del host) |
|---|---|---|
| Visibilidad de código | Origen de terceros inauditable | Paquete firmado y revisado |
| Control de actualización | El proveedor empuja a voluntad | El host revisa cada release |
| Superficie de ataque | XSS, alteración, phishing | Sandbox, capacidad acotada |
| Datos de pago | Difícil de restringir | Límites impuestos por el host |
| Postura regulatoria | «Confiamos en el proveedor» | Primera parte, control con evidencia |
| Respuesta a incidentes | Culpar, lento | El host retira al instante |
La diferencia es la latencia de control. Con H5, tu respuesta más rápida a un build malo es una llamada frenética al proveedor. Con un runtime, el host firma, revisa y puede sacar un paquete no conforme del catálogo en minutos. Esa brecha es la diferencia entre un incidente que gestionas y uno que te gestiona a ti.
Un runtime no hace la seguridad gratis. El host sigue responsable del motor, de la línea de revisión y del endurecimiento del runtime. Pero convierte una superficie de terceros opaca en una superficie que realmente gobiernas: paquetes firmados, APIs graduadas, listas blancas de capacidades y una baja que controlas. La caja negra se vuelve caja de cristal.
La línea honesta: si tu app toca dinero, salud o identidad, «embebimos una página web» no es una arquitectura defendible. Un runtime controlable es lo que convierte esa exposición de un pasivo que heredaste en un control que posees.
