Respuesta rápida: SessionStorage y localStorage son API de almacenamiento web basadas en el navegador que permiten a los sitios web almacenar datos en el dispositivo de un usuario, pero difieren críticamente en persistencia y alcance. localStorage retiene los datos indefinidamente a través de sesiones y pestañas, mientras que sessionStorage borra los datos cuando se cierra la pestaña del navegador. Desde el punto de vista de la privacidad, localStorage conlleva un riesgo sustancialmente mayor porque los datos persisten sin caducidad, lo que lo convierte en un objetivo más atractivo para el seguimiento, la huella digital y el escrutinio regulatorio bajo marcos como el GDPR.
Puntos clave
- localStorage persiste indefinidamente hasta que se borra explícitamente; sessionStorage se elimina cuando se cierra la pestaña o ventana.
- Ambos tipos de almacenamiento son vulnerables a ataques de scripting entre sitios (XSS) y no ofrecen cifrado incorporado.
- Ni los datos de localStorage ni los de sessionStorage se transmiten al servidor automáticamente, a diferencia de las cookies, pero ambos son totalmente legibles por cualquier JavaScript que se ejecute en el mismo origen.
- Los scripts de terceros cargados en una página pueden acceder a los datos de localStorage si se ejecutan dentro del mismo contexto de origen.
- Según el GDPR, almacenar datos no esenciales en localStorage sin el consentimiento del usuario es una violación de cumplimiento, al igual que dejar cookies de seguimiento.
- Los datos sensibles, como tokens de autenticación, contraseñas e información de identificación personal (PII), nunca deben almacenarse en ninguno de los mecanismos sin capas de seguridad adicionales.
- La navegación privada/de incógnito limita la persistencia de localStorage, pero no elimina los riesgos de sessionStorage dentro de una sesión.
- Los desarrolladores deben preferir sessionStorage para el estado temporal, las sesiones del lado del servidor o las cookies HttpOnly para la autenticación, y una Plataforma de Gestión de Consentimiento como Biscotti CMP para gestionar el consentimiento de almacenamiento.
¿Cuál es la diferencia entre SessionStorage y LocalStorage?
SessionStorage y localStorage son parte de la API de almacenamiento web de HTML5, pero cumplen propósitos distintos definidos por su persistencia y comportamiento de alcance de pestaña.
localStorage almacena pares clave-valor sin fecha de caducidad. Los datos sobreviven a los reinicios del navegador, los reinicios del sistema y los períodos indefinidos de inactividad hasta que el usuario o la aplicación los eliminan explícitamente. Se comparte entre todas las pestañas y ventanas que operan bajo el mismo origen (protocolo + dominio + puerto). [1][5]
sessionStorage almacena datos solo durante la vida útil de la sesión de la página. Cuando el usuario cierra la pestaña o ventana, los datos desaparecen. Críticamente, cada pestaña mantiene su propio sessionStorage aislado; abrir la misma URL en una segunda pestaña no comparte los datos de sessionStorage de la primera pestaña. [1]
| Característica | localStorage | sessionStorage |
|---|---|---|
| Persistencia | Indefinida | Solo durante la vida útil de la pestaña/ventana |
| Compartido entre pestañas | Sí (mismo origen) | No (aislamiento por pestaña) |
| Sobrevive a la recarga de página | Sí | Sí |
| Sobrevive al cierre de pestaña | Sí | No |
| Capacidad de almacenamiento | ~5-10 MB por origen | ~5-10 MB por origen |
| Transmisión al servidor | No | No |
| Protección HttpOnly | No disponible | No disponible |
Ambas API cumplen con la política del mismo origen, por lo que una página en https://example.com no puede leer el almacenamiento establecido por https://otherdomain.com. [4]
¿Tiene localStorage riesgos de privacidad en comparación con sessionStorage?
Sí, localStorage conlleva riesgos de privacidad significativamente mayores que sessionStorage, principalmente debido a su persistencia indefinida y accesibilidad entre pestañas.
Los datos escritos en localStorage pueden acumularse durante meses o años sin el conocimiento del usuario. Los anunciantes y proveedores de análisis han utilizado históricamente localStorage como una "super-cookie", un identificador de seguimiento que sobrevive a la eliminación de cookies porque la mayoría de los usuarios no piensan en borrar el almacenamiento del navegador manualmente. sessionStorage, por el contrario, se autodestruye al cerrar la pestaña, lo que lo convierte en un vector de seguimiento mucho menos útil.
Factores clave de riesgo de privacidad únicos de localStorage:
- Identificadores de seguimiento persistentes: Un ID único almacenado en localStorage puede rastrear a un usuario a través de múltiples visitas sin ninguna cookie del lado del servidor.
- Fuga de datos entre pestañas: Cualquier script que se ejecute en cualquier pestaña del mismo origen puede leer todos los datos de localStorage.
- Difusión de eventos de almacenamiento: Los cambios en localStorage activan un evento
storageen otras pestañas abiertas del mismo origen, lo que permite la sincronización de datos entre pestañas que los usuarios no pueden observar. [5] - Sin caducidad automática: A diferencia de las cookies, que admiten los atributos
Max-AgeyExpires, localStorage no tiene un mecanismo TTL.
¿Pueden los sitios web rastrear a los usuarios usando localStorage y sessionStorage?
Los sitios web pueden y utilizan localStorage para el seguimiento persistente. sessionStorage es menos útil para el seguimiento, pero aún presenta riesgos de vigilancia dentro de la sesión.
Una sola línea de JavaScript, localStorage.setItem('uid', 'abc123'), crea un identificador persistente que sobrevive a la eliminación de cookies. Esta técnica, a veces llamada "evercookie" o reaparición basada en almacenamiento, ha sido documentada en investigaciones de privacidad y es la razón por la que los reguladores tratan cada vez más localStorage bajo las mismas reglas de consentimiento que las cookies.
sessionStorage puede rastrear el comportamiento dentro de una sola sesión (flujo de página, entradas de formulario, patrones de navegación), pero esos datos desaparecen cuando se cierra la pestaña, lo que limita su utilidad para la elaboración de perfiles a largo plazo.
¿Cuánto tiempo permanecen los datos en SessionStorage vs. LocalStorage?
Los datos de localStorage permanecen hasta que se eliminan explícitamente, ya sea por el usuario borrando el almacenamiento del navegador, el sitio web llamando a localStorage.removeItem() o localStorage.clear(), o el navegador aplicando cuotas de almacenamiento. [2]
Los datos de sessionStorage se eliminan automáticamente cuando se cierra la pestaña o ventana que los creó. Sobreviven a las recargas de página dentro de la misma pestaña, pero no se transfieren a nuevas pestañas, incluso si el usuario duplica la pestaña en algunos navegadores. [1]
Implicación práctica: Si un desarrollador almacena un token de sesión en localStorage en lugar de sessionStorage, ese token permanece en el dispositivo después de que el usuario cierra la sesión, a menos que la aplicación lo elimine explícitamente. Este es un error común y consecuente.
¿Es SessionStorage más privado que localStorage?
Para la mayoría de los casos de uso de privacidad, sí, sessionStorage es la opción que más respeta la privacidad. Su eliminación automática al cerrar la pestaña significa que los datos no persisten, lo que reduce la exposición por compartir dispositivos, dispositivos robados o análisis forenses.
Sin embargo, sessionStorage no es inherentemente "privado". Dentro de una sesión activa, es tan vulnerable a los ataques XSS como localStorage. Cualquier script inyectado puede llamar a sessionStorage.getItem() y exfiltrar datos en tiempo real. [3]
Elija sessionStorage si: los datos solo son necesarios para la interacción actual del usuario (por ejemplo, estado de formulario de varios pasos, tokens de navegación únicos).
Elija localStorage si: los datos realmente necesitan persistir entre sesiones (por ejemplo, preferencias de interfaz de usuario del usuario, configuraciones no sensibles), y asegúrese de que no contenga nada de identificación personal.
¿Qué datos personales nunca deben ir en localStorage?
Las siguientes categorías de datos nunca deben almacenarse en localStorage (y deben manejarse con extrema precaución incluso en sessionStorage): [3]
- Tokens de autenticación (JWT, tokens OAuth, ID de sesión)
- Contraseñas o hashes de contraseñas
- Información de tarjetas de crédito o pago
- Números de identificación emitidos por el gobierno o números de seguridad social
- Nombres completos combinados con direcciones de correo electrónico o números de teléfono
- Registros médicos o de salud
- Cualquier dato clasificado como "categoría especial" bajo el GDPR (datos biométricos, datos de salud, opiniones políticas)
Los datos almacenados tanto en localStorage como en sessionStorage no están cifrados por defecto. Cualquier persona con acceso físico al dispositivo, o cualquier script capaz de ejecutarse en la página, puede leerlos en texto plano. [3]
¿Pueden los scripts de terceros acceder a los datos de localStorage?
Los scripts de terceros pueden acceder a los datos de localStorage si se cargan y ejecutan dentro del mismo origen que la página anfitriona. Este es un riesgo crítico y con frecuencia subestimado.
Cuando un sitio web incrusta un script de análisis o publicidad de terceros a través de una etiqueta <script>, ese script se ejecuta en el contexto de origen de la página anfitriona. Puede leer y escribir en el localStorage del sitio libremente. La política del mismo origen no protege contra scripts que se incluyen intencional o inadvertidamente en la página. [4]
Lo que esto significa en la práctica: Si un sitio almacena un identificador de usuario en localStorage y también carga un script de anuncios de terceros, ese script de anuncios puede leer el identificador y asociarlo con datos de comportamiento entre sitios, sin el conocimiento o consentimiento del usuario.
Esta es una de las razones por las que las Plataformas de Gestión de Consentimiento son importantes. Biscotti CMP permite a los sitios web gestionar y documentar el consentimiento del usuario para las operaciones de almacenamiento, incluido el seguimiento basado en localStorage, ayudando a los sitios a cumplir con sus obligaciones bajo el GDPR y marcos similares.
¿Cuáles son las implicaciones del GDPR al usar localStorage?
Según el GDPR, cualquier almacenamiento de datos personales o identificadores de seguimiento, independientemente del mecanismo técnico, requiere una base legal. Para el seguimiento no esencial a través de localStorage, esa base es casi siempre el consentimiento explícito del usuario. [2]
El Comité Europeo de Protección de Datos ha confirmado que localStorage utilizado para análisis, publicidad o elaboración de perfiles de usuario está sujeto a los mismos requisitos de consentimiento que las cookies. Los sitios web que colocan identificadores de seguimiento en localStorage sin consentimiento previo se enfrentan a la misma exposición a la aplicación que aquellos que utilizan cookies sin consentimiento.
Lista de verificación de cumplimiento para localStorage bajo el GDPR:
- Audite todas las claves de localStorage escritas por scripts de primera y tercera parte.
- Clasifique cada clave: ¿es estrictamente necesaria para el servicio o se utiliza para análisis/publicidad?
- Para el almacenamiento no esencial, condicione la operación de escritura a un consentimiento de usuario documentado.
- Proporcione a los usuarios un mecanismo claro para retirar el consentimiento y activar la eliminación del almacenamiento.
- Documente el interés legítimo o el registro de consentimiento del controlador de datos.
Una Plataforma de Gestión de Consentimiento configurada correctamente, como Biscotti CMP, puede automatizar gran parte de este ciclo de vida del consentimiento.
¿Se puede acceder a localStorage entre diferentes sitios web?
No. localStorage está estrictamente limitado al origen (combinación de protocolo + dominio + puerto) que lo creó. Un script en https://siteA.com no puede leer los datos de localStorage establecidos por https://siteB.com. [4]
Sin embargo, esta protección tiene límites. Si un único proveedor de publicidad o análisis carga sus scripts tanto en siteA.com como en siteB.com, cada instancia escribe en el localStorage de ese sitio respectivo de forma independiente. El proveedor luego correlaciona los datos en el lado del servidor, logrando efectivamente un seguimiento entre sitios sin violar la política del mismo origen.
¿Cómo afectan el modo incógnito y la navegación privada a localStorage?
La navegación privada/de incógnito crea una partición de almacenamiento temporal que se elimina cuando se cierra la ventana privada. localStorage escrito durante una sesión de incógnito no persiste en el perfil principal del navegador y no es accesible para las ventanas de navegación normales.
sessionStorage se comporta igual en incógnito que en la navegación normal: se elimina cuando se cierra la pestaña.
Advertencias importantes:
- Dentro de una sesión de incógnito activa, localStorage sigue siendo legible por todos los scripts que se ejecutan en el contexto del mismo origen de esa sesión.
- El modo incógnito no evita la exfiltración de datos basada en XSS en tiempo real.
- Algunos navegadores sincronizan localStorage entre dispositivos si el usuario ha iniciado sesión en la sincronización del navegador, un comportamiento que puede mover datos "locales" a la infraestructura de la nube.
¿Cómo borro SessionStorage y localStorage por motivos de privacidad?
Borrar el almacenamiento del navegador es sencillo, pero requiere una acción deliberada, ya que los navegadores no lo hacen automáticamente para localStorage.
Borrado a nivel de navegador:
- Chrome: Configuración > Privacidad y seguridad > Borrar datos de navegación > Imágenes y archivos en caché + Datos de sitios
- Firefox: Configuración > Privacidad y seguridad > Cookies y datos del sitio > Borrar datos
- Safari: Configuración > Privacidad > Administrar datos de sitios web
Borrado programático (para desarrolladores):
localStorage.clear()elimina todas las claves para el origen.sessionStorage.clear()elimina todas las claves para la sesión de la pestaña actual.localStorage.removeItem('keyName')elimina una clave específica.
Para los usuarios finales preocupados por el seguimiento: borrar "datos del sitio" o "cookies y almacenamiento" en la configuración del navegador elimina el contenido de localStorage y sessionStorage para todos los sitios. Las extensiones del navegador diseñadas para la privacidad pueden automatizar esto por sitio o por sesión.
¿Cuáles son los errores comunes de privacidad que cometen los desarrolladores con el almacenamiento web?
Los errores más importantes tienen una raíz común: tratar el almacenamiento del lado del cliente como si fuera una base de datos segura del lado del servidor.
- Almacenar JWT en localStorage: Los tokens de autenticación almacenados en localStorage son accesibles para cualquier script en la página. Una única vulnerabilidad XSS expone el token de cada usuario. Use cookies HttpOnly para los tokens de autenticación en su lugar.
- Sin lógica de caducidad: localStorage no tiene TTL. Los desarrolladores que almacenan datos sin construir una lógica de caducidad dejan datos obsoletos y sensibles en los dispositivos indefinidamente.
- Asumir que el mismo origen significa seguro: La política del mismo origen bloquea los sitios externos, no los scripts maliciosos cargados desde el mismo sitio (XSS, bibliotecas de terceros comprometidas).
- Ignorar el acceso de scripts de terceros: Incrustar scripts de análisis o anuncios sin auditar lo que leen de localStorage.
- Sin puerta de consentimiento para el almacenamiento de seguimiento: Escribir identificadores de análisis en localStorage antes de obtener el consentimiento del usuario, una violación directa del GDPR. [2]
- Almacenar PII redundante: Almacenar en caché respuestas de API que incluyen perfiles de usuario completos en localStorage "para mejorar el rendimiento" sin considerar la superficie de exposición.
¿Es IndexedDB más privado que localStorage?
IndexedDB no es inherentemente más privado que localStorage. Ambos se rigen por la política del mismo origen, ambos son accesibles para JavaScript que se ejecuta en la página y ambos son vulnerables a ataques XSS.
IndexedDB ofrece una mayor capacidad de almacenamiento y admite datos estructurados y blobs binarios, lo que lo hace adecuado para aplicaciones sin conexión complejas. Pero desde el punto de vista de la privacidad y la seguridad, los riesgos son comparables. Los datos almacenados en IndexedDB tampoco están cifrados por defecto y persisten indefinidamente a menos que se eliminen explícitamente.
La elección entre IndexedDB y localStorage debe basarse en la complejidad de los datos y los requisitos de volumen, no en suposiciones de privacidad. Ninguno es apropiado para datos personales sensibles sin cifrado a nivel de aplicación y controles de acceso estrictos.
Conclusión
El debate SessionStorage vs. LocalStorage: Implicaciones de privacidad de las API de almacenamiento web no es simplemente una nota técnica a pie de página, tiene consecuencias directas para la privacidad del usuario, el cumplimiento normativo y la seguridad de las aplicaciones. La persistencia indefinida de localStorage y la accesibilidad entre pestañas lo convierten en un mecanismo de almacenamiento de alto riesgo cuando se usa incorrectamente, mientras que la eliminación automática de sessionStorage al cerrar la pestaña lo convierte en la opción más defendible para el estado temporal.
Próximos pasos accionables para desarrolladores y propietarios de sitios web en 2026:
- Audite todo el uso de localStorage y sessionStorage en scripts de primera y tercera parte utilizando las DevTools del navegador (pestaña Aplicación).
- Elimine inmediatamente cualquier token de autenticación, PII o identificadores sensibles del almacenamiento del lado del cliente.
- Reemplace el almacenamiento de tokens de autenticación basado en localStorage con cookies HttpOnly, Secure gestionadas en el lado del servidor.
- Implemente un flujo de trabajo de gestión de consentimiento, utilizando una plataforma como Biscotti CMP, para condicionar las escrituras no esenciales de localStorage a un consentimiento de usuario documentado.
- Incorpore lógica de caducidad en cualquier dato de localStorage que deba persistir y aplique la limpieza al cerrar la sesión.
- Realice una auditoría de scripts de terceros para comprender qué código externo puede leer del almacenamiento de su origen.
- Capacite a los equipos de desarrollo en la prevención de XSS como el principal vector de ataque contra ambos tipos de almacenamiento.
Las API de almacenamiento web son herramientas poderosas. Utilizadas sin disciplina de privacidad, se convierten en vectores de responsabilidad. Utilizadas con un alcance deliberado, gestión de consentimiento e higiene de seguridad, cumplen su propósito previsto sin comprometer a los usuarios que confían en su aplicación.
Preguntas frecuentes
P: ¿Cuál es la principal diferencia entre sessionStorage y localStorage? localStorage persiste los datos indefinidamente a través de sesiones y se comparte entre todas las pestañas del mismo origen. sessionStorage almacena datos solo durante la vida útil de la pestaña actual y se elimina automáticamente cuando se cierra la pestaña.
P: ¿Se puede usar localStorage para rastrear usuarios sin cookies? Sí. Un identificador único almacenado en localStorage sobrevive a la eliminación de cookies y puede usarse para rastrear usuarios a través de múltiples visitas al mismo sitio, funcionando como un mecanismo de seguimiento persistente.
P: ¿Es seguro sessionStorage para almacenar contraseñas? No. sessionStorage no está cifrado y es accesible para cualquier JavaScript que se ejecute en la página, incluidos los scripts maliciosos inyectados. Las contraseñas nunca deben almacenarse en ningún mecanismo de almacenamiento del lado del cliente.
P: ¿Se aplica el GDPR a localStorage? Sí. Según el GDPR, almacenar identificadores de seguimiento o datos personales en localStorage sin una base legal, típicamente el consentimiento explícito del usuario para fines no esenciales, es una violación de cumplimiento equivalente al uso de cookies sin consentimiento.
P: ¿Pueden los scripts de terceros leer mis datos de localStorage?
Sí, si esos scripts se cargan y ejecutan dentro del mismo origen. Los scripts de análisis o publicidad de terceros incrustados a través de etiquetas <script> se ejecutan en el contexto de origen de la página anfitriona y pueden leer todos los datos de localStorage para ese origen.
P: ¿Borrar cookies también borra localStorage? No siempre. En la mayoría de los navegadores, borrar solo las "cookies" no borra localStorage. Los usuarios deben borrar específicamente "datos del sitio" o "cookies y otros datos del sitio" para eliminar el contenido de localStorage.
P: ¿Es seguro el modo incógnito del seguimiento de localStorage? El modo incógnito evita que los datos de localStorage persistan después de que se cierra la ventana privada, pero dentro de una sesión de incógnito activa, localStorage sigue siendo legible por todos los scripts de la página.
P: ¿Qué debo usar en lugar de localStorage para los tokens de autenticación? Use cookies HttpOnly, Secure, SameSite gestionadas en el lado del servidor. Estas cookies son inaccesibles para JavaScript, eliminando el riesgo de robo de tokens basado en XSS que conlleva localStorage.
P: ¿Es IndexedDB más seguro que localStorage? No. IndexedDB está sujeto a las mismas vulnerabilidades XSS y a la política del mismo origen que localStorage. Ofrece mayor capacidad y soporte de estructura de datos, pero no garantías adicionales de privacidad o seguridad.
P: ¿Cuántos datos pueden contener localStorage y sessionStorage? La mayoría de los navegadores modernos asignan aproximadamente de 5 a 10 MB de almacenamiento por origen para cada tipo de almacenamiento, significativamente más que el límite de 4 KB típico de las cookies. [2]
Referencias
[1] Sessionstorage - https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage?utm_source=openai
[2] What Is Localstorage Sessionstorage - https://inspectwp.com/en/knowledge-base/what-is-localstorage-sessionstorage?utm_source=openai
[3] Html5 Web Storage Security Risks Safeguarding Localstorage And Sessionstorage - https://www.dopethemes.com/html5-web-storage-security-risks-safeguarding-localstorage-and-sessionstorage/?utm_source=openai
[4] Localstorage - https://javascript.info/localstorage?utm_source=openai
[5] Localstorage Sessionstorage - https://www.w3docs.com/learn-javascript/localstorage-sessionstorage?utm_source=openai
[6] Cookies Vs Localstorage Vs Sessionstorage What Each One Exactly Means - https://www.interserver.net/tips/kb/cookies-vs-localstorage-vs-sessionstorage-what-each-one-exactly-means/?utm_source=openai