Datos sensibles en el almacenamiento del navegador

localStorage guarda pares de clave y valor por origen y no caduca: sigue ahí al cerrar la pestaña, el navegador y el equipo, hasta que el código o la persona lo borren. sessionStorage es igual pero vive solo mientras dura la pestaña. Los dos los lee y escribe cualquier script que corra en ese origen, incluido uno inyectado.

Las cookies van aparte. Una cookie marcada HttpOnly no la puede leer ningún script de la página: el navegador la adjunta a las peticiones y nada más. Por eso guardar la credencial de la sesión en una cookie HttpOnly y guardarla en localStorage no es lo mismo frente a una inyección de script: en el segundo caso el script se la puede llevar y usarla desde otro sitio hasta que caduque.

La guía de pruebas web de OWASP dedica una prueba al almacenamiento del navegador dentro de su capítulo del lado cliente.

Abre el laboratorio y lee tras-iniciar-sesion.txt. Además de la cookie, la aplicación usa una segunda credencial para hablar con la API, y la guarda en el almacenamiento persistente.

La gravedad de una credencial expuesta depende de cuánto tiempo sirve. Una que caduca en minutos limita el daño; una que dura semanas lo alarga. El valor guardado trae sus fechas.

Cerrar sesión debería dejar el navegador como estaba antes de entrar, sobre todo en un equipo compartido: un café internet, el computador de la familia, la taquilla de un teatro. Compara los dos archivos y mira también verificacion-token.txt, donde el evaluador usó la credencial de su propia cuenta después de salir.

Ya tienes las piezas: una credencial de larga vida en almacenamiento legible por scripts, que el servidor no anula al cerrar sesión, y datos personales que sobreviven a la salida. Falta redactarlo sin inflarlo: hoy no hay una inyección de script demostrada en el alcance.