El almacenamiento local es una API de almacenamiento web que permite a los sitios web almacenar pares clave-valor en un navegador sin tiempo de caducidad. Aunque es conveniente para la persistencia de datos del lado del cliente, requiere una cuidadosa consideración de la seguridad, ya que los datos almacenados son accesibles para cualquier JavaScript que se ejecute en el origen. Los datos confidenciales deben cifrarse y la entrada debe validarse para evitar ataques XSS.
Local Storage es una API de Web Storage que permite a un sitio guardar pares clave-valor de tipo cadena en el navegador sin caducidad, acotados a un único origen (protocolo más host más puerto). Los datos que escribe pages.example.com solo puede leerlos ese mismo origen, y sobreviven al cierre de pestañas, a las recargas de página y a los reinicios del navegador hasta que el código o el usuario los borran. El acceso es síncrono a través de window.localStorage, así que las lecturas y escrituras bloquean el hilo principal, y el límite de tamaño práctico ronda los 5 a 10 MB por origen. A diferencia de las cookies, el contenido nunca viaja con las peticiones HTTP, lo que mantiene pequeñas las cabeceras de las peticiones, pero también significa que el servidor nunca ve ni controla lo que una página guarda ahí.
La propiedad crítica es que cualquier JavaScript que se ejecute en el origen puede leer todas las claves de Local Storage. No existe un equivalente a HttpOnly, así que un único fallo de cross-site scripting, o un solo script de terceros comprometido, puede enumerar el almacén y exfiltrar todo lo que encuentre. Por eso, los tokens de sesión, los JWT, las claves de API o los datos personales guardados aquí quedan mucho más expuestos que ese mismo valor en una cookie HttpOnly, que el script no puede leer. Además, los valores persisten indefinidamente, así que un token robado semanas después del inicio de sesión todavía puede ser válido. Local Storage no ofrece cifrado, ni comprobaciones de integridad, ni caducidad automática, lo que lo convierte en una mala caja fuerte para cualquier cosa que un atacante quiera.
Trata Local Storage como público para cualquier código de la página. Guarda los tokens de autenticación en cookies HttpOnly, Secure y SameSite en lugar de en un almacén que JavaScript puede leer, y almacena localmente solo datos no sensibles y de bajo valor. Sanea y valida todo lo que leas de vuelta antes de insertarlo en el DOM, ya que los valores controlados por un atacante recuperados del almacén pueden provocar XSS basado en el DOM. Una Content Security Policy estricta limita qué scripts pueden ejecutarse y, por tanto, quién puede tocar el almacén. cside es relevante en la parte de los scripts de terceros: al enrutar los scripts externos a través de un método Script y analizar la carga útil, puede detectar y bloquear un script de un proveedor que empiece a leer el almacenamiento y a exfiltrarlo.
No para los secretos. Local Storage nunca se envía con las peticiones, lo que evita cierta exposición a CSRF, pero cualquier script del origen puede leerlo, y no se puede marcar como HttpOnly. Una cookie HttpOnly es invisible para JavaScript, así que para los tokens de sesión una cookie bien configurada es la opción más segura.
No. Local Storage está particionado por origen completo, así que app.example.com y shop.example.com tienen almacenes separados y aislados, y no pueden leer los datos del otro. Las cookies se pueden compartir entre subdominios mediante el atributo domain, pero Local Storage no tiene un mecanismo equivalente.
We answer client-side security questions every day. Bring yours.