Cookies, LocalStorage y SessionStorage…: ¿cuál usar y cuándo?

"¿Dónde guardo el token?", "¿Puedo guardar esto en localStorage?"…
Si te has hecho estas preguntas, esta guía es para ti.

---

🧭 Introducción

Hace unos días publiqué un artículo sobre cómo implementar autenticación moderna usando Redux Toolkit junto a Redux Persist. Como parte del ejemplo, incluí un componente de inicio de sesión que almacena el token en el localStorage, simplemente para demostrar el flujo completo.
Poco después, recibí algunos mensajes internos de colegas que medijeron:

"Oye, pero guardar el token de autenticación en el localStorage es súper peligroso"

Y si, tienen razón… si se tratara de un entorno de producción real.
este feedback me hizo pensar en que muchos desarrolladores incluso con experiencia aún tienen dudas sobre dónde y cómo deberíamos almacenar el token de autenticación del usuario en el cliente. ¿LocalStorage ?¿SessionStorage? ¿Cookies? ¿O quizás alguna solución más moderna como IndexedDB o incluso Private State Token?
En este artículo vamos a explorar cada una de estas opciones con una mirada práctica, revisaremos:

• Las ventajas y desventajas de cada enfoque.
• Cuáles son las tecnologías más utilzadas hoy en día.
• Y sobre todo, qué no deberias usar jamás en entornos productivos.

TL;DR

---

🗂️ LocalStorage

Persistencia simple y permanente en el navegador

LocalStorage es uno de los métodos más comunes para guardar datos del lado del cliente. Permite almacenar pares clave-valor de forma permanente en el navegador, incluso después de cerrar la pestaña o reiniciar el navegador. Es ideal para guardar configuraciones o estados que deben mantenerse entre sesiones, como el tema oscuro o la última pestaña abierta por el usuario.

Ventajas:

• Fácil de usar (localStorage.setItem / getItem).
• Persistencia a largo plazo sin expiración automática.
• Compatible con todos los navegadores modernos.
• Ideal para guardar configuraciones o preferencias no sensibles.

Desventajas:

• No es seguro para tokens de autenticación: accesible desde cualquier script en la misma página, lo que lo hace vulnerable a ataques de XSS.
• No se envía automáticamente en cada request, como las cookies.
• No se puede compartir entre subdominios.

Cuándo usarlo
 ✅ Configuraciones del usuario, temas, flags, o cualquier dato no sensible.
 ❌ Nunca para guardar access tokens, refresh tokens o información personal sensible.

🕒 SessionStorage

Datos temporales por pestaña

SessionStorage es similar a LocalStorage, pero sus datos solo viven durante la sesión actual del navegador. Es decir, la información se mantiene mientras la pestaña esté abierta y se elimina automáticamente al cerrarla. Esto lo hace ideal para datos sensibles al contexto de navegación, como el progreso en un formulario o información temporal entre páginas de una misma sesión.

Ventajas:

• Mismo API simple que localStorage.
• Menor tiempo de vida, ideal para sesiones temporales.
• Aísla los datos entre pestañas (cada pestaña del navegador tiene su propio sessionStorage).

Desventajas:

• Misma exposición a ataques XSS que localStorage.
• No persiste al cerrar la pestaña del navegador.
• No se comparte entre ventanas o pestañas del mismo dominio.

Cuándo usarlo
 ✅ Datos temporales de la sesión, como pasos de formularios largos.
 ❌ Mismos que localStorage, Mas validaciones al no persistir entre pestañas del navegador

🍪 Cookies

El clásico canal de datos entre navegador y servidor

Las cookies existen desde los inicios de la web y permiten almacenar pequeños fragmentos de datos que el navegador envía automáticamente con cada solicitud HTTP al servidor. Son ampliamente utilizadas para manejar sesiones de usuario, autenticación y preferencias. Aunque su capacidad es limitada y tienen un impacto en el rendimiento, siguen siendo clave cuando es necesario compartir información entre cliente y servidor.

Ventajas:

• Se pueden marcar como HttpOnly y Secure,
• Mayor protección contra XSS.
• Se envían automáticamente con cada petición al mismo dominio (útil para API's que dependen de sesiones).
• Permiten establecer expiraciones y reglas de acceso detalladas.

Desventajas:

• Mas complejas de manejar en JS si no usas librerías.
• Consumen espacio en cada request HTTP.
• Vulnerables a ataques CSRF si no se manejan bien (aunque se pueden mitigar con tokens antifalsificación y el uso correcto de SameSite)

Cuándo usarlo
 ✅ Ideal para tokens de sesión (access tokens) mediante HttpOnly, sobre todo en SSR (Server Site Rendering) o BFF (Backend For Frontend)
 ❌ Cuando necesitas controlar todo el ciclo de vida de la sesión, cuando necesitas compativilidad con navegadores antiguos.

🧰 IndexedDB

Base de datos local para aplicaciones complejas

IndexedDB es un sistema de base de datos NoSQL orientado a objetos dentro del navegador. A diferencia de LocalStorage y SessionStorage, está pensado para almacenar grandes volúmenes de datos de forma estructurada y realizar búsquedas avanzadas. Es perfecto para aplicaciones offline, almacenamiento de cachés complejas o sincronización de datos temporales sin conexión.

Ventajas

• Soporta gran volumen de datos (MB a GB).
• Ideal para aplicaciones offline o con caché compleja.
• No bloquea el hilo principal: se accede con promesas o callbacks.

Desventajas

• Más compleja que localStorage; necesita una estructura tipo base de datos.
• Menor soporte en navegadores antiguos.
• Exposición a XSS si no se usa bien.

Cuándo usarlo
 ✅ Ideal para Progressive Web Apps, almacenamiento de datos complejos offline, caché de grandes volúmenes.
 ❌ No se recomienda para autenticación si no se implementan mecanismos extra de seguridad.

🛡️ Private State Tokens

Verificación sin rastreo

Private State Tokens (antes conocidos como Trust Tokens) son una tecnología relativamente nueva diseñada para reemplazar el uso de cookies de terceros en escenarios donde se necesita verificar la autenticidad de un usuario, sin comprometer su privacidad ni permitir el seguimiento entre sitios. Son útilies para combatir el fraude y el spam en la web en un contexto donde la privacidad es una prioridad creciente.

Ventajas:

• Diseñado para proteger la privacidad del usuario.
• El backend puede emitir tokens sin exponer la información personal.
• Ideal para evitar fraudes, bots y problemas de identidad entre sitios.

Desventajas:

• Aún no es estándar ni ampliamente soportado (muy verde aun).
• Requiere configuracion específica desde el backend.
• No sustituye al almacenamiento de sesión, si no que lo complementa.

Cuándo usarlo
 ✅ Sistemas que necesitan validar usuarios sin rastreo ni fingerprinting.
 ❌ No es una alternativa directa a JWT, cookies o almacenamiento local.

🤔 Y Entonces cual uso?

Depende.... No hay una única respuesta, pero si una guia clara:

• 🔒 Para autenticación segura: usa cookies HttpOnly + Secure. Es lo más recomendado en producción.
• 🧪 Para pruebas, ejemplos o demos: puedes usar localStorage o sessionStorage, pero deja claro que no es seguro.
• 📦 Para almacenar grandes volúmenes o datos complejos (no sensibles): considera IndexedDB.
• 🛡️ ¿Privacidad avanzada o anonimato?: mantente atento a tecnologías como Private State Tokens, aún en evolución.

Y si no sabes cual elegir siempre piensa en la seguridad primero.

🎯 En resumen: no existe una única respuesta correcta… pero sí malas decisiones que puedes evitar

En el mundo real del desarrollo web, no hay soluciones mágicas. Cada aplicación tiene sus propias necesidades, riesgos y niveles de seguridad aceptables. Pero lo que sí está claro es que ciertas decisiones pueden exponerte innecesariamente a vulnerabilidades graves.
Si estás desarrollando con usuarios reales y datos sensibles, piensa más allá del frontend. Considera todo el flujo:

• ¿Cómo se genera y entrega el token?
• ¿Dónde se guarda y por qué?
• ¿Cómo se renueva y revoca?
• ¿Qué pasa si un atacante lo roba?

La seguridad no es una receta, es una serie de decisiones bien informadas.
Y tu arquitectura debe diseñarse con una visión completa: frontend, backend y experiencia de usuario, todos alineados.

---

💬 ¿Y tú, dónde guardas tus tokens?

Este tema genera debate por una razón: no todos los equipos lo resuelven igual, y muchas veces se toman decisiones por inercia.

Ahora te toca a ti:

👉 ¿Has tenido problemas de seguridad por elegir mal?
👉 ¿Tu equipo aún guarda todo en localStorage sin
cuestionarlo?

Cuéntame en los comentarios.
Y si este artículo te ayudó a entender mejor tus opciones, compartelo con tu equipo o en redes.
Quizás te ahorre un buen dolor de cabeza más adelante.