Resposta rápida: SessionStorage e localStorage son ambas APIs de Almacenamento Web baseadas no navegador que permiten aos sitios web almacenar datos no dispositivo dun usuario, pero difiren criticamente na persistencia e no alcance. localStorage retén os datos indefinidamente a través de sesións e pestanas, mentres que sessionStorage borra os datos cando se pecha a pestana do navegador. Desde o punto de vista da privacidade, localStorage conleva un risco substancialmente maior porque os datos persisten sen caducidade, converténdoo nun obxectivo máis atractivo para o seguimento, a pegada dixital e o escrutinio regulatorio baixo marcos como o GDPR.
Puntos clave
- localStorage persiste indefinidamente ata que se borra explicitamente; sessionStorage elimínase cando se pecha a pestana ou xanela.
- Ambos tipos de almacenamento son vulnerables a ataques de scripting entre sitios (XSS) e non ofrecen cifrado incorporado.
- Nin os datos de localStorage nin os de sessionStorage se transmiten ao servidor automaticamente, a diferenza das cookies, pero ambos son totalmente lexibles por calquera JavaScript que se execute na mesma orixe.
- Os scripts de terceiros cargados nunha páxina poden acceder aos datos de localStorage se se executan no mesmo contexto de orixe.
- Segundo o GDPR, almacenar datos non esenciais en localStorage sen o consentimento do usuario é unha violación de conformidade, o mesmo que deixar cookies de seguimento.
- Os datos sensibles como tokens de autenticación, contrasinais e información de identificación persoal (PII) nunca deben almacenarse en ningún dos mecanismos sen capas de seguridade adicionais.
- A navegación privada/incógnito limita a persistencia de localStorage pero non elimina os riscos de sessionStorage dentro dunha sesión.
- Os desenvolvedores deben preferir sessionStorage para o estado temporal, as sesións do lado do servidor ou as cookies HttpOnly para a autenticación, e unha Plataforma de Xestión de Consentimento como Biscotti CMP para xestionar o consentimento de almacenamento.
Cal é a diferenza entre SessionStorage e LocalStorage?
SessionStorage e localStorage son ambos parte da API de Almacenamento Web HTML5, pero serven propósitos distintos definidos polo seu comportamento de persistencia e alcance da pestana.
localStorage almacena pares clave-valor sen data de caducidade. Os datos sobreviven aos reinicios do navegador, aos reinicios do sistema e a períodos indefinidos de inactividade ata que o usuario ou a aplicación os elimine explicitamente. Compártese entre todas as pestanas e xanelas que operan baixo a mesma orixe (protocolo + dominio + porto). [1][5]
sessionStorage almacena datos só durante a vida útil da sesión da páxina. Cando o usuario pecha a pestana ou xanela, os datos desaparecen. Criticamente, cada pestana mantén o seu propio sessionStorage illado; abrir a mesma URL nunha segunda pestana non comparte os datos de sessionStorage da primeira pestana. [1]
| Característica | localStorage | sessionStorage |
|---|---|---|
| Persistencia | Indefinida | Só durante a vida útil da pestana/xanela |
| Compartido entre pestanas | Si (mesma orixe) | Non (illamento por pestana) |
| Sobrevive á recarga da páxina | Si | Si |
| Sobrevive ao peche da pestana | Si | Non |
| Capacidade de almacenamento | ~5-10 MB por orixe | ~5-10 MB por orixe |
| Transmisión ao servidor | Non | Non |
| Protección HttpOnly | Non dispoñible | Non dispoñible |
Ambas APIs adhiren á política de mesma orixe, polo que unha páxina en https://example.com non pode ler o almacenamento establecido por https://otherdomain.com. [4]
Ten localStorage riscos de privacidade en comparación con sessionStorage?
Si, localStorage conleva riscos de privacidade significativamente maiores que sessionStorage, principalmente debido á súa persistencia indefinida e accesibilidade entre pestanas.
Os datos escritos en localStorage poden acumularse durante meses ou anos sen o coñecemento do usuario. Os anunciantes e provedores de análises usaron historicamente localStorage como unha "super-cookie", un identificador de seguimento que sobrevive á eliminación de cookies porque a maioría dos usuarios non pensan en borrar o almacenamento do navegador manualmente. sessionStorage, pola contra, autodestrúese ao pechar a pestana, o que o converte nun vector de seguimento moito menos útil.
Factores clave de risco de privacidade únicos para localStorage:
- Identificadores de seguimento persistentes: Un ID único almacenado en localStorage pode seguir a un usuario a través de múltiples visitas sen ningunha cookie do lado do servidor.
- Fuga de datos entre pestanas: Calquera script que se execute en calquera pestana da mesma orixe pode ler todos os datos de localStorage.
- Difusión de eventos de almacenamento: Os cambios en localStorage activan un evento
storagenoutras pestanas abertas da mesma orixe, o que permite a sincronización de datos entre pestanas que os usuarios non poden observar. [5] - Sen caducidade automática: A diferenza das cookies, que admiten os atributos
Max-AgeeExpires, localStorage non ten un mecanismo TTL.
Poden os sitios web rastrexar usuarios usando localStorage e sessionStorage?
Os sitios web poden e usan localStorage para o seguimento persistente. sessionStorage é menos útil para o seguimento pero aínda presenta riscos de vixilancia dentro da sesión.
Unha única liña de JavaScript, localStorage.setItem('uid', 'abc123'), crea un identificador persistente que sobrevive á eliminación de cookies. Esta técnica, ás veces chamada "evercookie" ou respawning baseado en almacenamento, foi documentada en investigacións de privacidade e é a razón pola que os reguladores tratan cada vez máis localStorage baixo as mesmas regras de consentimento que as cookies.
sessionStorage pode rastrexar o comportamento dentro dunha única sesión (fluxo de páxina, entradas de formulario, patróns de navegación), pero eses datos desaparecen cando se pecha a pestana, o que limita a súa utilidade para a elaboración de perfís a longo prazo.
Canto tempo permanecen os datos en SessionStorage vs. LocalStorage?
Os datos de localStorage permanecen ata que se eliminan explicitamente, xa sexa polo usuario que borra o almacenamento do navegador, o sitio web que chama a localStorage.removeItem() ou localStorage.clear(), ou o navegador que aplica cotas de almacenamento. [2]
Os datos de sessionStorage elimínanse automaticamente cando se pecha a pestana ou xanela que os creou. Sobreviven ás recargas de páxina dentro da mesma pestana pero non se transfiren a novas pestanas, aínda que o usuario duplique a pestana nalgúns navegadores. [1]
Implicación práctica: Se un desenvolvedor almacena un token de sesión en localStorage en lugar de sessionStorage, ese token permanece no dispositivo despois de que o usuario peche a sesión, a menos que a aplicación o elimine explicitamente. Este é un erro común e consecuente.
É SessionStorage máis privado que localStorage?
Para a maioría dos casos de uso de privacidade, si, sessionStorage é a opción que máis respecta a privacidade. A súa eliminación automática ao pechar a pestana significa que os datos non persisten, reducindo a exposición por compartir dispositivos, dispositivos roubados ou análises forenses.
Con todo, sessionStorage non é inherentemente "privado". Dentro dunha sesión activa, é tan vulnerable a ataques XSS como localStorage. Calquera script inxectado pode chamar a sessionStorage.getItem() e exfiltrar datos en tempo real. [3]
Escolla sessionStorage se: os datos só son necesarios para a interacción actual do usuario (por exemplo, estado de formulario de varios pasos, tokens de navegación dunha soa vez).
Escolla localStorage se: os datos realmente necesitan persistir entre sesións (por exemplo, preferencias de UI do usuario, configuración non sensible), e asegúrese de que non conteña nada de identificación persoal.
Que datos persoais nunca deben ir en localStorage?
As seguintes categorías de datos nunca deben almacenarse en localStorage (e deben manexarse con extrema precaución incluso en sessionStorage): [3]
- Tokens de autenticación (JWTs, tokens OAuth, IDs de sesión)
- Contrasinais ou hashes de contrasinais
- Información de tarxeta de crédito ou pago
- Números de identificación emitidos polo goberno ou números de seguridade social
- Nomes completos combinados con enderezos de correo electrónico ou números de teléfono
- Rexistros médicos ou de saúde
- Calquera dato clasificado como "categoría especial" baixo o GDPR (datos biométricos, datos de saúde, opinións políticas)
Os datos almacenados tanto en localStorage como en sessionStorage non están cifrados por defecto. Calquera persoa con acceso físico ao dispositivo, ou calquera script capaz de executarse na páxina, pode lelos en texto plano. [3]
Poden os scripts de terceiros acceder aos datos de localStorage?
Os scripts de terceiros poden acceder aos datos de localStorage se se cargan e executan dentro da mesma orixe que a páxina anfitrioa. Este é un risco crítico e frecuentemente subestimado.
Cando un sitio web incrusta un script de análise ou publicidade de terceiros a través dunha etiqueta <script>, ese script execútase no contexto de orixe da páxina anfitrioa. Pode ler e escribir no localStorage do sitio libremente. A política de mesma orixe non protexe contra scripts que se inclúen intencionadamente ou inadvertidamente na páxina. [4]
O que isto significa na práctica: Se un sitio almacena un identificador de usuario en localStorage e tamén carga un script de anuncios de terceiros, ese script de anuncios pode ler o identificador e asocialo con datos de comportamento entre sitios, sen o coñecemento ou consentimento do usuario.
Esta é unha das razóns polas que as Plataformas de Xestión de Consentimento importan. Biscotti CMP permite aos sitios web xestionar e documentar o consentimento do usuario para operacións de almacenamento, incluído o seguimento baseado en localStorage, axudando aos sitios a cumprir as súas obrigas baixo o GDPR e marcos similares.
Cales son as implicacións do GDPR no uso de localStorage?
Segundo o GDPR, calquera almacenamento de datos persoais ou identificadores de seguimento, independentemente do mecanismo técnico, require unha base legal. Para o seguimento non esencial a través de localStorage, esa base é case sempre o consentimento explícito do usuario. [2]
O Comité Europeo de Protección de Datos confirmou que localStorage usado para análises, publicidade ou elaboración de perfís de usuario está suxeito aos mesmos requisitos de consentimento que as cookies. Os sitios web que deixan identificadores de seguimento en localStorage sen consentimento previo enfróntanse á mesma exposición de aplicación que aqueles que usan cookies sen consentimento.
Lista de verificación de conformidade para localStorage baixo o GDPR:
- Auditar todas as claves de localStorage escritas por scripts de primeira e terceira parte.
- Clasificar cada clave: é estritamente necesaria para o servizo, ou úsase para análises/publicidade?
- Para o almacenamento non esencial, protexer a operación de escritura detrás do consentimento documentado do usuario.
- Proporcionar aos usuarios un mecanismo claro para retirar o consentimento e activar a eliminación do almacenamento.
- Documentar o interese lexítimo ou o rexistro de consentimento do controlador de datos.
Unha Plataforma de Xestión de Consentimento correctamente configurada como Biscotti CMP pode automatizar gran parte deste ciclo de vida do consentimento.
Pódese acceder a localStorage a través de diferentes sitios web?
Non. localStorage está estritamente limitado á orixe (combinación de protocolo + dominio + porto) que o creou. Un script en https://siteA.com non pode ler os datos de localStorage establecidos por https://siteB.com. [4]
Con todo, esta protección ten límites. Se un único provedor de publicidade ou análises carga os seus scripts tanto en siteA.com como en siteB.com, cada instancia escribe no localStorage dese sitio respectivo de forma independente. O provedor entón correlaciona os datos no lado do servidor, logrando efectivamente o seguimento entre sitios sen violar a política de mesma orixe.
Como afectan o modo incógnito e a navegación privada a localStorage?
A navegación privada/incógnito crea unha partición de almacenamento temporal que se elimina cando se pecha a xanela privada. O localStorage escrito durante unha sesión de incógnito non persiste no perfil principal do navegador e non é accesible para as xanelas de navegación regulares.
sessionStorage compórtase igual en incógnito que na navegación regular: elimínase cando se pecha a pestana.
Advertencias importantes:
- Dentro dunha sesión de incógnito activa, localStorage segue sendo lexible por todos os scripts que se executan no contexto de mesma orixe desa sesión.
- O modo incógnito non impide a exfiltración de datos baseada en XSS en tempo real.
- Algúns navegadores sincronizan localStorage entre dispositivos se o usuario iniciou sesión na sincronización do navegador, un comportamento que pode mover datos "locais" á infraestrutura na nube.
Como borro SessionStorage e localStorage por privacidade?
Borrar o almacenamento do navegador é sinxelo pero require unha acción deliberada xa que os navegadores non o fan automaticamente para localStorage.
Borrado a nivel de navegador:
- Chrome: Configuración > Privacidade e seguridade > Borrar datos de navegación > Imaxes e ficheiros en caché + Datos do sitio
- Firefox: Configuración > Privacidade e seguridade > Cookies e datos do sitio > Borrar datos
- Safari: Configuración > Privacidade > Xestionar datos do sitio web
Borrado programático (para desenvolvedores):
localStorage.clear()elimina todas as claves para a orixe.sessionStorage.clear()elimina todas as claves para a sesión da pestana actual.localStorage.removeItem('keyName')elimina unha clave específica.
Para os usuarios finais preocupados polo seguimento: borrar "datos do sitio" ou "cookies e almacenamento" na configuración do navegador elimina o contido de localStorage e sessionStorage para todos os sitios. As extensións do navegador deseñadas para a privacidade poden automatizar isto por sitio ou por sesión.
Cales son os erros comúns de privacidade que cometen os desenvolvedores co almacenamento web?
Os erros máis consecuentes teñen unha raíz común: tratar o almacenamento do lado do cliente coma se fose unha base de datos segura do lado do servidor.
- Almacenar JWTs en localStorage: Os tokens de autenticación almacenados en localStorage son accesibles para calquera script da páxina. Unha única vulnerabilidade XSS expón o token de cada usuario. Use cookies HttpOnly para tokens de autenticación no seu lugar.
- Sen lóxica de caducidade: localStorage non ten TTL. Os desenvolvedores que almacenan datos sen construír lóxica de caducidade deixan datos obsoletos e sensibles nos dispositivos indefinidamente.
- Asumir que a mesma orixe significa seguro: A política de mesma orixe bloquea sitios externos, non scripts maliciosos cargados desde o mesmo sitio (XSS, bibliotecas de terceiros comprometidas).
- Ignorar o acceso de scripts de terceiros: Incrustar scripts de análise ou anuncios sen auditar o que len de localStorage.
- Sen porta de consentimento para o almacenamento de seguimento: Escribir identificadores de análise en localStorage antes de obter o consentimento do usuario, unha violación directa do GDPR. [2]
- Almacenar PII redundante: Almacenar en caché respostas da API que inclúen perfís de usuario completos en localStorage "para o rendemento" sen considerar a superficie de exposición.
É IndexedDB máis privado que localStorage?
IndexedDB non é inherentemente máis privado que localStorage. Ambos réxense pola política de mesma orixe, ambos son accesibles a JavaScript que se executa na páxina e ambos son vulnerables a ataques XSS.
IndexedDB ofrece maior capacidade de almacenamento e admite datos estruturados e blobs binarios, o que o fai axeitado para aplicacións sen conexión complexas. Pero desde o punto de vista da privacidade e a seguridade, os riscos son comparables. Os datos almacenados en IndexedDB tampouco están cifrados por defecto e persisten indefinidamente a menos que se eliminen explicitamente.
A elección entre IndexedDB e localStorage debe estar impulsada pola complexidade dos datos e os requisitos de volume, non por suposicións de privacidade. Ningún dos dous é axeitado para datos persoais sensibles sen cifrado a nivel de aplicación e controis de acceso estritos.
Conclusión
O debate SessionStorage vs. LocalStorage: Implicacións de Privacidade das APIs de Almacenamento Web non é simplemente unha nota técnica, ten consecuencias directas para a privacidade do usuario, o cumprimento normativo e a seguridade das aplicacións. A persistencia indefinida de localStorage e a accesibilidade entre pestanas convérteno nun mecanismo de almacenamento de alto risco cando se usa indebidamente, mentres que a eliminación automática de sessionStorage ao pechar a pestana convérteo na opción máis defendible para o estado temporal.
Próximos pasos accionables para desenvolvedores e propietarios de sitios web en 2026:
- Auditar todo o uso de localStorage e sessionStorage en scripts de primeira e terceira parte usando as Ferramentas de Desenvolvedor do navegador (pestana Aplicación).
- Eliminar inmediatamente calquera token de autenticación, PII ou identificadores sensibles do almacenamento do lado do cliente.
- Substituír o almacenamento de tokens de autenticación baseado en localStorage por cookies HttpOnly, Secure, SameSite xestionadas no lado do servidor.
- Implementar un fluxo de traballo de xestión de consentimento, usando unha plataforma como Biscotti CMP, para protexer as escrituras non esenciais de localStorage detrás do consentimento documentado do usuario.
- Construír lóxica de caducidade en calquera dato de localStorage que deba persistir e aplicar a limpeza ao pechar a sesión.
- Realizar unha auditoría de scripts de terceiros para comprender que código externo pode ler do almacenamento da súa orixe.
- Adestrar aos equipos de desenvolvemento na prevención de XSS como o principal vector de ataque contra ambos tipos de almacenamento.
As APIs de almacenamento web son ferramentas poderosas. Usadas sen disciplina de privacidade, convértense en vectores de responsabilidade. Usadas con alcance deliberado, xestión de consentimento e hixiene de seguridade, serven ao seu propósito sen comprometer aos usuarios que confían na súa aplicación.
Preguntas frecuentes
P: Cal é a principal diferenza entre sessionStorage e localStorage? localStorage persiste os datos indefinidamente entre sesións e compártese entre todas as pestanas da mesma orixe. sessionStorage almacena datos só durante a vida útil da pestana actual e elimínase automaticamente cando se pecha a pestana.
P: Pódese usar localStorage para rastrexar usuarios sen cookies? Si. Un identificador único almacenado en localStorage sobrevive á eliminación de cookies e pódese usar para rastrexar usuarios a través de múltiples visitas ao mesmo sitio, funcionando como un mecanismo de seguimento persistente.
P: É seguro sessionStorage para almacenar contrasinais? Non. sessionStorage non está cifrado e é accesible a calquera JavaScript que se execute na páxina, incluídos os scripts maliciosos inxectados. Os contrasinais nunca deben almacenarse en ningún mecanismo de almacenamento do lado do cliente.
P: Aplícase o GDPR a localStorage? Si. Segundo o GDPR, almacenar identificadores de seguimento ou datos persoais en localStorage sen unha base legal, normalmente o consentimento explícito do usuario para fins non esenciais, é unha violación de conformidade equivalente ao uso de cookies sen consentimento.
P: Poden os scripts de terceiros ler os meus datos de localStorage?
Si, se eses scripts se cargan e executan dentro da mesma orixe. Os scripts de análise ou publicidade de terceiros incrustados a través de etiquetas <script> execútanse no contexto de orixe da páxina anfitrioa e poden ler todos os datos de localStorage para esa orixe.
P: Borrar as cookies tamén borra localStorage? Non sempre. Na maioría dos navegadores, borrar só as "cookies" non borra localStorage. Os usuarios deben borrar especificamente "datos do sitio" ou "cookies e outros datos do sitio" para eliminar o contido de localStorage.
P: É seguro o modo incógnito do seguimento de localStorage? O modo incógnito impide que os datos de localStorage persistan despois de que se peche a xanela privada, pero dentro dunha sesión de incógnito activa, localStorage segue sendo lexible por todos os scripts da páxina.
P: Que debo usar en lugar de localStorage para tokens de autenticación? Use cookies HttpOnly, Secure, SameSite xestionadas no lado do servidor. Estas cookies son inaccesibles a JavaScript, eliminando o risco de roubo de tokens baseado en XSS que conleva localStorage.
P: É IndexedDB máis seguro que localStorage? Non. IndexedDB está suxeito ás mesmas vulnerabilidades XSS e á política de mesma orixe que localStorage. Ofrece maior capacidade e soporte de estrutura de datos pero non garantías adicionais de privacidade ou seguridade.
P: Canta cantidade de datos poden almacenar localStorage e sessionStorage? A maioría dos navegadores modernos asignan aproximadamente de 5 a 10 MB de almacenamento por orixe para cada tipo de almacenamento, significativamente máis que o límite de 4 KB típico das 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