Cookies, localStorage y sessionStorage: qué guardar en cada uno
Publicado el 2026-10-26 por frfrand
Diferencias entre cookies y almacenamiento web, expiración, seguridad, sesiones, XSS y CSRF explicados.
Cookies, localStorage y sessionStorage permiten conservar información relacionada con una web, pero no funcionan igual ni ofrecen las mismas propiedades de seguridad. Elegir dónde guardar datos de sesión sin entender estas diferencias puede exponer información o romper el funcionamiento de una aplicación.
¿Qué es una cookie?
Una cookie es un pequeño dato asociado a un sitio que el navegador puede enviar automáticamente en solicitudes HTTP que cumplan determinadas condiciones.
Por eso se utiliza para mantener sesiones: el navegador puede adjuntar un identificador de sesión sin que cada página tenga que pedir otra vez la contraseña.
Sus atributos importan mucho. Secure restringe el envío a conexiones seguras en los contextos previstos; HttpOnly evita que JavaScript lea la cookie; SameSite controla parte del comportamiento entre sitios.
No hay que asumir que cualquier cookie implica rastreo publicitario. Algunas son esenciales para autenticar usuarios o mantener preferencias.
¿Qué es localStorage?
Es un almacenamiento de pares clave-valor disponible para JavaScript del mismo origen, sujeto a las políticas del navegador. Suele conservar información incluso después de cerrar la pestaña o el navegador, aunque el usuario pueda borrarla y el navegador establezca límites.
Puede servir para guardar preferencias no sensibles, como el tema visual de una aplicación.
No es un lugar ideal para secretos importantes: si una vulnerabilidad XSS permite ejecutar código en tu página, ese código puede acceder al almacenamiento disponible para JavaScript.
¿Y sessionStorage?
También almacena valores por origen, pero está asociado a la sesión de una pestaña o contexto de navegación. Normalmente se elimina cuando termina esa sesión de página.
Por ejemplo, puede resultar útil para conservar temporalmente el avance de un formulario en una pestaña. Aun así, no constituye una garantía de confidencialidad frente a scripts que se ejecuten dentro de ese origen.
Tabla de comparación
| Característica | Cookie | localStorage | sessionStorage |
|---|---|---|---|
| ¿Se envía automáticamente en HTTP? | Puede enviarse según sus atributos | No | No |
| ¿Puede leerlo JavaScript? | Depende de HttpOnly y contexto | Sí, bajo las reglas del origen | Sí, bajo las reglas del origen |
| ¿Cuánto permanece? | Según duración y políticas | Normalmente hasta borrado o limpieza | Asociado a la sesión de pestaña |
| Uso común | Sesiones y preferencias | Preferencias no sensibles | Estado temporal de una pestaña |
Esta tabla simplifica algunos detalles: el comportamiento exacto depende del navegador y de las políticas de almacenamiento.
¿Dónde guardo un token de autenticación?
No existe una respuesta universal. Una cookie HttpOnly con atributos correctos reduce la exposición del valor a JavaScript, pero hay que diseñar protección frente a CSRF cuando corresponda.
Guardar un token en localStorage evita su envío automático como cookie, pero aumenta su exposición si un script malicioso se ejecuta en el origen.
La decisión depende de la arquitectura, las amenazas, la duración de sesión y la forma de validar permisos. Copiar una solución porque «todo el mundo lo hace» no es suficiente.
¿Es buena idea almacenar datos personales?
Reduzca la información sensible almacenada en el navegador. Un campo de contraseña, datos de pago o documentos privados no deberían persistir sin una necesidad real y controles apropiados.
Además, estos mecanismos no reemplazan la base de datos del servidor. El usuario puede borrar sus datos locales, utilizar otro dispositivo o navegar en un contexto privado.
Un ejemplo útil
Una web de reservas puede guardar el idioma preferido en localStorage. La sesión de usuario puede gestionarse mediante cookies configuradas correctamente. Y el paso actual de un formulario podría mantenerse en sessionStorage para la pestaña activa.
Las reservas confirmadas, pagos y permisos deben verificarse desde el backend: no puede confiar en un precio simplemente porque aparezca en el almacenamiento del visitante.
¿Qué relación tiene con ArduMaker?
Si alojás una aplicación web en ArduMaker, tu frontend puede utilizar estos mecanismos como cualquier otra web. El VPS donde ejecutás el backend no determina automáticamente si las cookies o los tokens están configurados de forma segura.
En una frase: cookies, localStorage y sessionStorage son herramientas diferentes. Elegí cada una según persistencia, exposición a JavaScript y necesidad real.
Fuentes: Cookies en MDN · Web Storage API · OWASP HTML5 Security.