Dado el tamaño creciente del código frontend, el concepto de micro-frontend y federación de módulos proporcionado por Webpack 5 es una posible solución. Sin embargo, teniendo en cuenta la posibilidad de que esté integrando código de otros equipos/terceros, el código externo podría intentar acceder a información para la que no está destinado simplemente accediendo al objeto de window e iterando a través de sus elementos secundarios.
Esta no tiene que ser información crítica como contraseñas y tarjetas de crédito, que a menudo se aíslan mediante un iframe . Se podría recopilar y utilizar indebidamente información menos confidencial, como correos electrónicos de usuarios o datos de seguimiento.
En este caso, ¿hay alguna configuración técnica que no involucre iframes que pueda limitar el alcance de acceso de los scripts? ¿Es esto algo que técnicamente podría implementarse dentro de un programa WebAssembly?
Editar : Sí, la regla conservadora es simplemente no ejecutar código que no sea de confianza. Sin embargo, la pregunta que se plantea es si es técnicamente posible aislar el código frontend sin usar iframe para limitar su acceso a la información.
Javascript es intrínsecamente "público", por lo que en algún momento las cosas que ingresas o sacas eventualmente estarán expuestas, ya sea a través de la búsqueda de red/XHR, o mediante la ejecución de la función.
Hay un patrón "privado" en javascript, que evita husmear dentro de un objeto, donde define explícitamente los métodos/propiedades que están expuestos:
window.myThing = (function(){ var a = "a"; var private_b = "b"; function one(){ return "one" } function private_two(){ return private_b } return { public_a : a, public_one : one } }()); for(var prop in window.myThing){ console.log(prop, window.myThing[prop]) } // ---------------------------------- // only the following properties // are exposed from the window scope: // ---------------------------------- // + public_a as - a // + public_one as ƒ one()En teoría, este tipo de patrón podría permitir métodos y propiedades internas (no expuestas/no transitables)... y aprovechar alguna forma de encriptación para "entradas y salidas".