Dónde guardar el token en el navegador

El almacenamiento local (localStorage) y el de sesión (sessionStorage) son accesibles para cualquier script que se ejecute en el mismo origen: el propio, el de un proveedor y el que entre por un XSS. Una cookie con el atributo HttpOnly, en cambio, la envía el navegador al servidor pero ningún script puede leerla. Guardar un token en el almacenamiento local es, en la práctica, aceptar que el primer XSS o el primer script de terceros comprometido se lo lleva, y MITRE agrupa ese tipo de decisión bajo CWE-922, almacenamiento inseguro de información sensible.

La cookie no es gratis: como el navegador la envía solo, reaparece el riesgo de peticiones disparadas desde otro sitio, que se controla con SameSite, con una ruta (Path) limitada al punto que la usa y con las defensas del módulo de CSRF.

Abre el laboratorio y lee almacenamiento-exportado.txt. Fíjate en cuánto vive cada valor: un token de acceso robado sirve unas horas; uno de refresco robado sirve para fabricar accesos durante meses.

Un script de terceros cargado en la página corre con los mismos permisos que el código propio: lee el almacenamiento, el DOM y los formularios. Si no lleva verificación de integridad (SRI) y la política de contenido permite scripts de cualquier origen con HTTPS, un cambio en el servidor del proveedor basta para que el código que se ejecuta en el pago sea otro.

Revisa scripts-del-pago.txt y la cabecera Content-Security-Policy de cabeceras-pago.txt.

Lee propuesta-cookie.txt atributo por atributo. Dos detalles la desarman: el front tendría que leer la cookie con document.cookie, lo que solo es posible si la cookie no lleva HttpOnly, y el valor elegido para el envío entre sitios hace que el navegador la mande también en peticiones que nacen en otro sitio.

Con todo lo anterior, escribe la recomendación para DEV-2290. El objetivo es que ni el script del chat ni un XSS futuro puedan llevarse el token de larga vida, sin abrir la puerta a peticiones desde otros sitios.