Situación actual
Mi empresa tiene un montón de entornos diferentes en los que no siempre es fácil implementar el código front-end para probarlo con datos de trabajo/en vivo. Usamos una extensión para intercambiar ciertos scripts que se envían desde el servidor con los disponibles localmente. Esto funciona principalmente, pero viene con algunas limitaciones.
Deseo
Hace unos años, trabajé en otra empresa que nos permitía ejecutar un comando en la consola del navegador que hacía lo mismo que la extensión. No miré en ese momento cómo se implementó, pero creo que tuvo algo que ver con tener básicamente un pequeño paquete de javascript que se envió primero al navegador que determinó qué paquete se debe entregar y si un valor en el almacenamiento local era marcado como "verdadero", colocaría etiquetas de script que apuntan a localhost. Si fuera falso, iría al servidor en su lugar.
Pregunta
Quiero implementar algo como esto en mi empresa actual, pero tengo curiosidad sobre las implicaciones de seguridad de esto.
Siempre que los paquetes de JavaScript que se sirven no contengan información confidencial, debería estar bien.
Si los paquetes que se envían contienen información confidencial, es probable que merezcan una refactorización: sería mejor solo entregar información confidencial después de que el backend autentique que el usuario está autorizado para recibirla, en lugar de entregarla a cualquier persona que suceda. para solicitar un paquete a través del administrador de paquetes front-end.
Al considerar la seguridad, una buena regla general es actuar como si el cliente pudiera leer el JavaScript del lado del cliente y modificarlo y ejecutarlo como desee. Por lo tanto, cualquier paso de verificación debe realizarse en el servidor, no en el cliente.
Si lo único que estás pensando en implementar es
si un valor en el almacenamiento local se marcó como "verdadero", colocaría etiquetas de script que apuntarían a localhost. Si fuera falso, iría al servidor en su lugar.
entonces eso está perfectamente bien: lo peor que los clientes podrían hacer al manipular eso es ejecutar su propio JavaScript (que ya pueden hacer).
Si esto tiene como objetivo facilitar a los desarrolladores la prueba del sitio en vivo, un mejor enfoque podría ser separar completamente el entorno de producción en vivo del entorno de desarrollo: configurar un servidor de desarrollo con datos ficticios y menos restricciones con las que los desarrolladores puedan interactuar. , mientras que los clientes solo pueden ver el servidor de producción (que ahora puede que ya no se beneficie de tener un administrador de secuencias de comandos front-end).