Seguridad: qué no debe almacenar nunca

localStorage y sessionStorage guardan los datos sin cifrar en el disco, dentro del perfil del usuario. Cualquier proceso con acceso al sistema de archivos, incluido un malware, una herramienta de copia de seguridad u otro usuario que haya iniciado sesión, puede leer todos los valores almacenados sin pasar por el navegador.

Todos los scripts que se ejecutan en el origen comparten el mismo Storage. Un ataque XSS exitoso, un SDK de terceros comprometido o una extensión maliciosa del navegador pueden llamar a localStorage.getItem y exfiltrar todos los valores almacenados. No existe aislamiento entre scripts.

No almacene tokens de sesión, JWT, refresh tokens ni claves de API en localStorage. Si un atacante inyecta una sola línea de JavaScript, el token se filtra de inmediato. Use cookies con los atributos httpOnly, Secure y SameSite para que el token nunca sea accesible desde JavaScript.

Almacenar contraseñas de cualquier forma —en texto plano, con hash o cifradas— es incorrecto en el cliente. Aplicar hash en el cliente no ayuda cuando el atacante puede leer el hash y reutilizarlo. La gestión de contraseñas debe realizarse por completo en el servidor mediante un hash de contraseñas específico, como bcrypt.

PCI-DSS prohíbe almacenar números de tarjeta, CVV, datos de la banda magnética o fechas de vencimiento en el almacenamiento del cliente. En su lugar, use un proveedor de pagos con tokenización (Stripe, Braintree, Adyen) que devuelva un token de corta duración vinculado a su origen.

Los documentos de identidad oficiales, las fechas de nacimiento completas, las direcciones particulares y los datos médicos atraen la atención de los organismos reguladores (GDPR, HIPAA) y de los atacantes. Almacene únicamente lo necesario para la sesión actual, solicítelo de nuevo cuando sea necesario y deje que el servidor conserve la fuente de verdad.

Un fallo de XSS que filtra document.cookie ya es grave. El mismo fallo en una página que almacena tokens en localStorage entrega al atacante todos los valores almacenados de una sola vez. Trate localStorage como una superficie en la que «si se compromete un script, se compromete todo».

Cifrar valores con una clave que también se encuentra en JavaScript no ofrece una protección real: el atacante que puede leer el texto cifrado también puede leer la clave. Los secretos reales deben permanecer en el servidor y volver a emitirse; nunca deben persistirse en el cliente.

Las preferencias de la interfaz (tema, barra lateral contraída, idioma), los indicadores de funcionalidad no confidenciales, el contenido de formularios en borrador y el estado efímero de asistentes son totalmente seguros. De todos modos son visibles para el usuario, y su filtración no permite tomar el control de la cuenta.

Emita la autenticación mediante Set-Cookie: token=...; HttpOnly; Secure; SameSite=Strict. La marca HttpOnly impide que JavaScript acceda a la cookie, lo que neutraliza la mayoría de las cargas XSS que roban tokens, incluso cuando existen otros fallos en la página.

Si debe almacenar en caché datos que parecen confidenciales, limite estrictamente su alcance (TTL corto, borrado al cerrar sesión y eliminación al cerrar la pestaña mediante sessionStorage), aplique una directiva de seguridad de contenido estricta para bloquear scripts inyectados y audite todos los scripts de terceros que se ejecuten en páginas autenticadas.

¿Por qué se considera un riesgo de seguridad almacenar tokens de autenticación en localStorage?

Web Storage es texto sin formato, cualquier script puede leerlo y se comparte por origen. Nunca almacene allí tokens de autenticación, contraseñas, datos de pago ni información personal regulada. Mantenga los secretos en cookies httpOnly y reserve localStorage para estados inofensivos de la interfaz que el usuario podría ver de todos modos.