Seguridad en microfrontends: qué cambia y qué hacer

Una plataforma de microfrontends carga código desde varios lugares en una sola página. Eso cambia el modelo de confianza, la Content Security Policy, el manejo de tokens y la cadena de suministro.

El modelo de confianza

Un hecho define todo lo demás. Los remotos cargados con Module Federation, Native Federation, import maps o custom elements corren en el mismo documento que el host. Comparten el mismo origen, el mismo DOM, el mismo almacenamiento y el mismo entorno de JavaScript.

El navegador no da ningún aislamiento entre ellos. Un remoto puede leer todo lo que el host puede leer y hacer todo lo que el host puede hacer. Si un remoto queda comprometido, toda la aplicación queda comprometida.

Por eso cada remoto es código de confianza total, y la plataforma es tan segura como su pipeline más débil. El único aislamiento que ofrece el navegador para código de interfaz es un iframe en otro origen, idealmente con el atributo sandbox. Úsalo para código que no controlas, como el widget de un proveedor. Mira iframes vs web components vs federation.

Cargar código desde varios orígenes

El host decide desde qué URLs se cargan los remotos. Esa decisión es un control de seguridad.

• El manifiesto es sensible. Quien pueda cambiar el manifiesto puede hacer que todos los usuarios carguen código arbitrario. Sírvelo desde infraestructura que controlas, restringe la escritura al pipeline y registra cada cambio.
• Nunca armes la URL de un remoto con datos del usuario. Una dirección de remoto tomada de un parámetro de URL o del almacenamiento del navegador es un camino directo a la inyección de scripts. Los mecanismos de sobrescritura para desarrolladores deben estar desactivados en producción.
• Prefiere pocos orígenes conocidos. Servir todos los remotos por HTTPS bajo un dominio propio, con una ruta por remoto, simplifica todo lo que sigue.
• Protege el almacenamiento. El bucket o el CDN que guarda los archivos de los remotos necesita permisos de escritura estrictos. El pipeline de cada equipo debe escribir solo en su propia ruta.

Content Security Policy

Una Content Security Policy le dice al navegador qué fuentes de código están permitidas. Con microfrontends necesita un diseño explícito.

• script-src debe listar los orígenes exactos que sirven remotos. Evita los comodines. Un ejemplo estricto: script-src 'self' https://static.example.com.
• connect-src debe cubrir las APIs de cada remoto y la ubicación del manifiesto.
• Evita unsafe-inline y unsafe-eval. Verifica que la salida de producción de tu herramienta de build funcione sin ellos. Angular agrega los estilos de los componentes a la página como elementos style inline; desde Angular 16 puede marcarlos con un nonce (ngCspNonce), de modo que style-src tampoco necesita unsafe-inline. El código AngularJS legacy tiene un modo ng-csp para correr sin unsafe-eval.

La política le pertenece al host, así que el equipo de plataforma es su dueño. Cada origen de remoto o API nueva es un cambio de política. Activa primero la política en modo de solo reporte y revisa las violaciones antes de exigirla.

Subresource Integrity compara un archivo con un hash. Funciona bien para etiquetas script clásicas con contenido fijo. Para módulos cargados de forma dinámica, el soporte de los navegadores es más limitado, así que revísalo antes de depender de él. Angular también soporta Trusted Types, que reducen el riesgo de inyección basada en el DOM.

Exposición de tokens

Cualquier script de la página puede leer localStorage, sessionStorage y cualquier variable que alcance. Con más equipos y más dependencias en una página, crece la probabilidad de que algún script se comporte mal.

• Prefiere tokens que JavaScript no pueda leer. Un backend-for-frontend que guarda los tokens en el servidor y le entrega al navegador una cookie de sesión marcada HttpOnly, Secure y SameSite saca el token de la página. Requiere protección contra la falsificación de peticiones entre sitios (CSRF).
• Si los tokens viven en el navegador, guárdalos en memoria dentro del host, entrega a los remotos una función que devuelva un token válido y usa tiempos de vida cortos. Esto limita las fugas accidentales. Un remoto malicioso igual puede llamar a esa función.
• Limita el alcance de los tokens. El mínimo privilegio en el backend limita lo que se puede hacer con un token robado.
• Mantén los tokens fuera de las URLs, los logs y los eventos que se intercambian entre remotos.

Los patrones están en autenticación compartida.

Cadena de suministro de dependencias

Cada remoto tiene su propio árbol de dependencias y su propio pipeline. El código de terceros que termina en la página es la suma de todos.

• Guarda los lockfiles en el repositorio e instala a partir de ellos en el pipeline.
• Escanea las dependencias en el pipeline de cada remoto y haz fallar el build ante vulnerabilidades críticas conocidas.
• Automatiza las actualizaciones con una herramienta como Renovate o Dependabot, para que los parches lleguen a todas partes.
• Separa las credenciales de despliegue por equipo. Una credencial filtrada debería alcanzar solo la ruta de un remoto.

Permisos por área

La autorización tiene tres capas, y solo una es una frontera de seguridad.

1. El host oculta lo que el usuario no puede usar. Las entradas de navegación y las rutas se filtran por rol. Esto es experiencia de usuario.
2. El remoto vuelve a revisar. Un guard de ruta impide renderizar una pantalla desde una URL directa. Esto también es experiencia de usuario.
3. El backend hace cumplir. Cada API verifica los permisos del usuario en cada petición. Esta es la frontera de seguridad.

El usuario puede leer y modificar el código que llega al navegador. Trata los permisos del frontend como una comodidad, y nunca incluyas secretos en un remoto.

Más en esta sección

• Desarrollo local con microfrontends
• Qué son los microfrontends: guía para quienes deciden
• Cuándo valen la pena los microfrontends y cuándo no
• Module Federation vs Native Federation en Angular