Las apps web aisladas (IWA) proporcionan un modelo de seguridad que permite que las aplicaciones web accedan a funciones potentes, como los sockets directos y el Controlled Frame, que suelen estar restringidas en la Web estándar de "visita rápida". Dado que las IWA operan en un entorno de alta confianza, deben cumplir con políticas estrictas de seguridad y privacidad. Estos lineamientos están diseñados para garantizar que, a medida que la plataforma web adquiere más potencia, los usuarios sigan seguros y se mantenga la integridad del entorno del navegador.
El modelo de confianza de IWA
El núcleo de la plataforma de IWA se basa en políticas técnicas estrictas que obligan a los desarrolladores a mantener un alto nivel de seguridad. Si bien las apps web estándar se basan en un modelo de permisos flexible, las IWA se firman de forma criptográfica y se entregan con paquetes web, lo que permite verificar su origen y su integridad.
A cambio de esta identidad verificada, las IWA obtienen acceso a APIs privilegiadas. Para mantener esta confianza, los desarrolladores deben seguir un enfoque centrado en la seguridad y cumplir con políticas más estrictas, como la Política de Seguridad del Contenido (CSP) y los Trusted Types, que garantizan la seguridad del usuario incluso cuando se usan capacidades potentes. Esto significa lo siguiente:
- Transparencia: Los usuarios nunca deben sorprenderse por el uso que hace una aplicación de las APIs con privilegios.
- Privilegio mínimo: Las apps solo deben solicitar y usar las capacidades específicas que se requieren para su propósito declarado.
- Integridad estática: Toda la lógica ejecutable debe estar contenida en el paquete de la app para permitir la auditoría de seguridad y evitar la carga lateral de código malicioso.
Si bien las IWA incluyen protecciones integradas sólidas, como una Política de Seguridad del Contenido (CSP) estricta que impide la ejecución de secuencias de comandos externas, las limitaciones técnicas por sí solas no pueden mitigar todos los riesgos. Incluso en un entorno de alta confianza, ciertos patrones de implementación o elecciones de los desarrolladores pueden comprometer de forma involuntaria la seguridad o la privacidad de los usuarios. En esta guía, se describen estos casos restringidos y las políticas que rigen el uso de las APIs con privilegios.
Por qué son importantes estas pautas
Cumplir con estas políticas no se trata solo de satisfacer los requisitos, sino de crear un ecosistema sostenible para las aplicaciones web avanzadas. Si sigues estos lineamientos, te asegurarás de que tu aplicación cumpla con lo siguiente:
- Evita regresiones de seguridad: Mantiene la lógica autónoma para evitar vulnerabilidades como la secuencia de comandos entre sitios (XSS) y la ejecución remota de código.
- Protege la privacidad del usuario: Garantiza que los datos sensibles y el acceso al hardware se manejen solo con la intención explícita y la transparencia del usuario.
- Garantiza la longevidad de la plataforma: Ayuda a mantener los altos estándares de seguridad necesarios para que la plataforma de IWA siga expandiendo su conjunto de capacidades.
Principios básicos
Transparencia y la intención del usuario
La regla más fundamental es no sorprender al usuario. El comportamiento de tu aplicación debe alinearse con su propósito declarado y las expectativas del usuario.
- Mantente dentro del alcance: No implementes funciones que se extiendan más allá del propósito claro de tu aplicación.
- Huella de API mínima: Solicita y usa solo el conjunto específico de APIs de IWA necesarias para lograr la función principal de tu app.
No se permite la carga lateral de código dinámico
El modelo de seguridad de la IWA depende de la capacidad de los administradores o del proveedor del navegador para verificar toda la lógica ejecutable. Por lo tanto, tu paquete de IWA debe ser autónomo. La plataforma aplica esta política a través de una Política de Seguridad del Contenido (CSP) estricta que bloquea la ejecución basada en cadenas, como eval() y new Function():
script-src 'self' 'wasm-unsafe-eval';
require-trusted-types-for 'script';
Si bien la CSP permite que 'wasm-unsafe-eval' admita WebAssembly, no debes eludir el espíritu de este límite de seguridad.
Prácticas estrictamente prohibidas
- Envío de intérpretes para código remoto: No puedes incluir un intérprete de código (por ejemplo, Python o Lua compilados en WASM) para descargar y ejecutar secuencias de comandos externas con acceso privilegiado a la red, como sockets directos.
- Lógica cargada de forma remota: No uses Service Workers para incorporar código cargado de forma remota en el origen de la IWA.
- Código versus datos: Si bien se permite descargar datos (como JSON), descargar cualquier código destinado a interpretarse o ejecutarse es un incumplimiento directo de la política.
El principio de privilegio mínimo
Siempre usa la API menos potente que pueda realizar una tarea. Las APIs privilegiadas específicas de la IWA nunca deben usarse como un atajo para omitir las restricciones de seguridad o las indicaciones del usuario de las APIs web estándar. En la siguiente tabla, se describen casos de uso comunes para ayudarte a decidir cuándo usar las APIs web tradicionales en lugar de las capacidades específicas de las IWA:
| Tarea | Usar la API web estándar (recomendado) | Evita la API de IWA privilegiada (restringida) |
|---|---|---|
| Acceso a disco duro externo | Usa la API de File System Access para la E/S de archivos estándar. | No uses WebUSB sin restricciones para acceder al almacenamiento. |
| Interacción con la tarjeta inteligente | Usa la API de Smart Card. | No uses WebUSB sin restricciones para tarjetas inteligentes. |
| Comunicación con dispositivos en serie | Usa la API de WebSerial si es suficiente para tu dispositivo. | Evita WebUSB sin restricciones si WebSerial puede realizar la tarea. |
| Cómo incorporar contenido confiable | Usa un objeto <iframe> estándar. |
No uses <controlledframe> para la incorporación simple, a menos que se requiera aislamiento. |
Lineamientos específicos de la API
Las APIs de IWA proporcionan capacidades potentes que suelen estar restringidas en el navegador. La orientación general es nunca usar estas funciones privilegiadas de una manera que sorprenda a los usuarios o que comprometa su confianza y sus datos.
API de Direct Sockets
La API de Direct Sockets otorga acceso sin procesar a TCP y UDP, incluido el acceso a multicast y a la red local.
Permitido
- Compatibilidad con protocolos personalizados: Conexión a servidores remotos que usan protocolos personalizados para los que actualmente no existe una API web de nivel superior.
- Mantener servicios de backend: Conectarse a un servidor predefinido y codificado de forma rígida que se usa específicamente para los servicios de backend de tu aplicación
- Descubrimiento de hardware esencial: Acceder a la red local o usar la transmisión multidifusión para descubrir hardware específico y relacionado que sea esencial para la función de la app (por ejemplo, una app de edición de video que localiza el almacenamiento conectado a la red)
No se permite
- Sorprender al usuario: Implementar acceso a la red que no esté claramente justificado por la funcionalidad principal de la app, como un editor de texto que se comunica con dispositivos de la red local.
- Analizar redes de forma arbitraria: Realizar análisis amplios de la red local del usuario (por ejemplo, analizar los puertos de 192.168.1.0/24) para crear un perfil del usuario o descubrir dispositivos no relacionados
- Segmentación para dispositivos locales: Está estrictamente prohibido intentar sondear, reconfigurar o atacar otros dispositivos en la red local.
API de Controlled Frame
El elemento <controlledframe> permite incorporar y modificar contenido de origen cruzado, incluida la inserción de secuencias de comandos y la alteración de encabezados.
Permitido
- Optimización de las interfaces de usuario: Incorporación de un servicio de terceros y CSS para ocultar elementos de la IU irrelevantes o proporcionar una experiencia más cohesiva
- Mediar en la comunicación segura: Actuar como un portero recibiendo solicitudes de la página incorporada con
postMessagey devolviendo solo los datos necesarios y saneados recuperados a través de APIs privilegiadas
No se permite
- Robo de credenciales del usuario: Se inyectan secuencias de comandos para capturar contraseñas, cookies de sesión o cualquier otro dato sensible del usuario del contenido incorporado.
- Incumplimiento de las condiciones del servicio: Alterar las plataformas integradas de formas que infrinjan sus Condiciones del Servicio, como el clic en anuncios programático o el scraping no autorizado
- Proxying privileged access: Crear un pass-through que le otorgue al contenido incorporado no confiable acceso directo o no controlado a una API de IWA privilegiada.
- Implementación de IA no controlada: Realizar acciones en nombre de un usuario que accedió a su cuenta a través de la IA sin restricciones específicas y transparentes del caso de uso
Grabación de pantalla sin restricciones
Permite la captura de pantalla sin las indicaciones repetidas de permiso del usuario que se encuentran en la Web estándar.
Permitido
- Proporcionar funcionalidad principal: Usar la captura de pantalla como una parte obvia del servicio de la app, como en las funciones de grabación de reuniones virtuales o tutoriales
- Garantizar que los usuarios estén al tanto: Informar a los usuarios claramente que se puede realizar una grabación antes de que interactúen con la aplicación
No se permite
- Grabación subrepticia: Capturar la pantalla del usuario sin su conocimiento y consentimiento explícitos y anticipados
- Incumplimiento de las reglamentaciones de privacidad: Participar en prácticas de grabación que incumplan las leyes de privacidad locales o internacionales
WebUSB sin restricciones
WebUSB sin restricciones omite la lista de bloqueo estándar de WebUSB para permitir la interacción de bajo nivel con los dispositivos.
Permitido
- Compatibilidad con hardware propietario: Interactuar con hardware especializado o heredado para el que no existe una API web de alto nivel, como los controladores industriales.
Ahora se permite
- Eludir las APIs dedicadas: Usar WebUSB para dispositivos que tienen una API más específica y restringida, como tarjetas inteligentes (usar la API de Smart Card) o almacenamiento externo (usar la API de File System Access).
Administración de ventanas (window.open y window.focus)
Las IWA pueden crear ventanas emergentes y ventanas de enfoque sin el gesto del usuario que requiere la Web estándar.
Permitido
- Notificación de finalización de tareas: Enfocar la ventana de la app cuando finaliza una tarea en segundo plano crítica iniciada por el usuario, como la renderización de un video
No se permite
- Spam: Bombardear al usuario con varias ventanas no solicitadas.
- Phishing: Apertura de ventanas diseñadas para imitar diálogos del sistema o engañar al usuario
- Robo de enfoque: Interrumpe al usuario robando el enfoque de otras aplicaciones para eventos no críticos.
Conclusión
La arquitectura de seguridad de las apps web aisladas está diseñada para potenciar a los desarrolladores y, al mismo tiempo, mantener un entorno de alta confianza para los usuarios. Si cumples con estos lineamientos, te asegurarás de que tu aplicación siga siendo un ciudadano responsable del ecosistema de la IWA. Las conclusiones más importantes de esta guía son las siguientes:
- Prioriza la transparencia: El comportamiento de tu aplicación siempre debe alinearse con su propósito declarado. Nunca implementes funcionalidades que puedan sorprender o defraudar al usuario.
- Aplicar la integridad del paquete: Toda la lógica ejecutable debe estar contenida en el paquete de la IWA para permitir la verificación estática. Se prohíbe estrictamente eludir el modelo de seguridad a través de la carga lateral de código dinámico o intérpretes remotos.
- Cumple con el principio de privilegio mínimo: Siempre selecciona la API más restringida disponible para una tarea determinada. Las APIs de IWA privilegiadas solo se deben usar cuando las APIs web estándar no son suficientes para la funcionalidad principal de la aplicación.
- Actúa como un guardián: Cuando uses herramientas potentes como
<controlledframe>, tu IWA debe actuar como un mediador seguro en lugar de un proxy transparente para el contenido no confiable.
Antes de publicar tu IWA, realiza una auditoría final de tu implementación y pregúntate lo siguiente:
- ¿Estoy usando la API más sencilla y restringida posible para esta tarea?
- ¿Se sorprendería o se sentiría traicionado un usuario por lo que hace mi app?
Si la respuesta a la primera pregunta es "No" o la segunda es "Sí", es probable que tu aplicación incumpla las políticas de seguridad de la IWA y que se quite.