Secretos y lógica de autorización en el cliente

Las herramientas de compilación de aplicaciones de una sola página leen variables de entorno y las sustituyen por su valor dentro del código al compilar. Para no filtrar todo el entorno, solo exponen al navegador las que llevan un prefijo acordado: VITE_ en Vite, NEXT_PUBLIC_ en Next.js, REACT_APP_ en Create React App. Una variable con ese prefijo deja de ser configuración y pasa a ser texto dentro de un archivo JavaScript que cualquiera descarga. Por eso esas variables nunca deben llevar datos sensibles.

No todo lo que parece una clave es secreto. Muchos proveedores emiten claves públicas pensadas para el navegador, limitadas por dominio o por servicio. La pregunta no es si el valor está en el cliente, sino si su dueño lo diseñó para estar ahí. MITRE agrupa la credencial secreta incrustada en el código bajo CWE-798.

Abre el laboratorio. Cruza env-produccion.txt con catalogo-credenciales.txt, y confirma con busqueda-en-paquete.txt qué valores aparecen de verdad en los archivos publicados. Una variable sin el prefijo no llega al paquete aunque esté en el mismo archivo.

En rutas.jsx, el panel de administración se muestra solo si el rol guardado en localStorage es admin. Ese valor lo controla el navegador: cualquiera puede cambiarlo, o llamar a la API sin pasar por la app. Una guarda de rutas en el cliente es una comodidad de interfaz; quien autoriza es el servidor, en cada petición, con el rol que él mismo lee de la sesión. MITRE describe el error de confiar en el cliente para una regla de seguridad como CWE-602.

Lee registro-api-admin.txt. El rol que aparece en cada línea es el de la sesión en el servidor.

El registro muestra que una ruta de administración sí comprueba el rol y otras no. El equipo propone dos cambios: mover el rol de localStorage a una cookie, y añadir la comprobación de rol a las rutas que no la tienen.

La llave privada de la pasarela está en dos archivos publicados, y en las versiones anteriores de la app que puedan estar en cachés y copias.