O que é localStorage e sessionStorage?

localStorage e sessionStorage são dois mecanismos fornecidos pela Web Storage API, um padrão embutido em todo navegador moderno. Eles permitem que sites armazenem pares chave-valor diretamente no navegador do visitante, sem envolver o servidor a cada carregamento de página. Se você já alternou o modo escuro em um site e descobriu que sua preferência continuava lá no dia seguinte, é provável que o site tenha salvado essa escolha no localStorage.

Como a Web Storage API funciona

A Web Storage API é intencionalmente simples. Você chama localStorage.setItem('chave', 'valor') para gravar dados, localStorage.getItem('chave') para lê-los e localStorage.removeItem('chave') para apagá-los. O sessionStorage usa exatamente os mesmos métodos. Ambos só aceitam strings, então objetos normalmente são serializados com JSON.stringify() antes de serem salvos. Não há linguagem de consulta, indexação ou estrutura relacional. É um armazenamento chave-valor plano, projetado para leituras e escritas rápidas e leves.

localStorage vs. sessionStorage: principais diferenças

• Persistência: os dados do localStorage permanecem no navegador até que o usuário ou o site os apague explicitamente. Não há data de expiração. Os dados do sessionStorage, por outro lado, são apagados no momento em que a aba do navegador é fechada.
• Escopo entre abas: o localStorage é compartilhado entre todas as abas e janelas que pertencem à mesma origem (protocolo + domínio + porta). O sessionStorage é isolado em uma única aba. Se você abre a mesma página em duas abas, cada aba tem seu próprio sessionStorage.
• Limites de armazenamento: ambos normalmente oferecem de 5 a 10 MB por origem, dependendo do navegador. Chrome e Firefox usam padrão de cerca de 5 MB por origem para cada armazenamento. O Safari pode ser mais rigoroso, especialmente no modo de navegação privada, onde às vezes limita o armazenamento a apenas algumas centenas de kilobytes.
• Comportamento de rede: nem o localStorage nem o sessionStorage são enviados ao servidor com requisições HTTP. Essa é a diferença fundamental em relação aos cookies, que são anexados automaticamente ao cabeçalho de cada requisição.

O que sites WordPress costumam armazenar

Plugins e temas do WordPress usam o armazenamento do navegador para uma ampla variedade de propósitos. Eis os mais comuns:

• Preferências de tema: alternâncias de modo escuro, estado da barra lateral (recolhida/expandida), escolhas de tamanho de fonte. Quase sempre são armazenadas no localStorage porque devem sobreviver ao fechamento da aba.
• Dados do carrinho de compras: o WooCommerce e plugins semelhantes às vezes guardam fragmentos do carrinho em localStorage para evitar idas e vindas extras ao servidor ao exibir o mini-carrinho no cabeçalho.
• Rascunhos de formulário: plugins de formulário de contato podem auto-salvar a entrada do usuário em sessionStorage para que um formulário parcialmente preenchido não se perca se o usuário acidentalmente sair da página e voltar pelo botão voltar.
• Escolhas de consentimento de cookies: alguns plugins de banner de consentimento (como Complianz ou CookieYes) armazenam o estado de consentimento do visitante em localStorage em vez de em um cookie, embora usar um cookie seja mais comum.
• Estado da interface do admin: o próprio painel administrativo do WordPress usa ambos os mecanismos de armazenamento. Por exemplo, ele lembra quais meta boxes estão recolhidas, quais colunas estão visíveis na lista de posts e se o menu do admin está dobrado.
• Buffers de analytics e rastreamento: alguns scripts de analytics agrupam eventos em localStorage e os enviam ao servidor em lotes para reduzir requisições de rede.

Considerações de segurança

O Web Storage é conveniente, mas vem com trocas reais de segurança que os desenvolvedores precisam entender.

• Exposição a XSS: qualquer JavaScript que rode na página pode ler o localStorage e o sessionStorage. Se um atacante conseguir injetar um script por meio de uma vulnerabilidade de cross-site scripting (XSS), pode extrair todos os valores armazenados. Cookies podem ser protegidos com a flag HttpOnly, que bloqueia o acesso por JavaScript completamente. Não há proteção equivalente para o Web Storage.
• Política de mesma origem: o armazenamento é escopado pela origem, ou seja, https://example.com não pode ler o armazenamento de https://other.com. Entretanto, qualquer script na mesma origem, incluindo scripts de terceiros que você carrega (analytics, redes de anúncios, widgets de chat), tem acesso total ao mesmo armazenamento.
• Sem criptografia: os dados são armazenados em texto puro no disco. Qualquer pessoa com acesso físico ao dispositivo, ou malware rodando no dispositivo, pode lê-los. Nunca armazene senhas, tokens ou outras credenciais sensíveis no Web Storage.
• Sem validação no servidor: como os dados vivem apenas no navegador, um usuário ou script pode modificá-los livremente. Nunca dependa de valores do Web Storage para decisões de autorização ou segurança no servidor.

Implicações de GDPR e privacidade

Sob o GDPR e a Diretiva ePrivacy, localStorage e sessionStorage são tratados da mesma forma que cookies no que diz respeito a requisitos de consentimento. O princípio jurídico é neutro em relação à tecnologia: se você armazena ou lê informações no dispositivo do usuário para um propósito que não é estritamente necessário ao serviço solicitado pelo usuário, você precisa de consentimento. Isso significa que um carrinho do WooCommerce armazenado em localStorage provavelmente é "estritamente necessário" e não exige consentimento. Mas um ID de analytics armazenado em localStorage para rastrear visitantes recorrentes definitivamente exige. Muitos donos de site negligenciam isso porque ferramentas de consentimento de cookies tradicionalmente focam em cookies, mas os reguladores deixaram claro que as regras se aplicam a todas as tecnologias de armazenamento do lado do cliente.

Web Storage vs. cookies: quando usar cada um

• Use cookies: quando o servidor precisa ler o valor a cada requisição (IDs de sessão, tokens de autenticação), quando você precisa de proteção HttpOnly contra XSS, ou quando precisa de controle granular sobre expiração.
• Use localStorage: quando precisa persistir preferências do lado do cliente ou guardar dados em cache entre sessões, os dados não precisam viajar até o servidor e os dados não são sensíveis.
• Use sessionStorage: quando os dados só devem viver pela duração de uma única sessão de aba, como progresso em um assistente de formulário, estado temporário de UI ou tokens de redirecionamento de uso único.

Comparação de desempenho

Ler e gravar no Web Storage é síncrono e ocorre na thread principal. Para pequenas quantidades de dados isso é rápido, geralmente abaixo de um milissegundo. Mas se uma página grava ou lê grandes volumes de dados a cada interação, pode causar travamentos. Os cookies, em contraste, adicionam custo de um modo diferente: aumentam o tamanho de cada cabeçalho de requisição HTTP, o que torna cada chamada de rede mais lenta. Para armazenar um punhado de pequenos valores, ambas as abordagens têm bom desempenho. Para conjuntos maiores de dados (dezenas de KB ou mais), considere o IndexedDB, que é assíncrono e não bloqueia a thread principal.

Como inspecionar o armazenamento no DevTools

Todo navegador grande permite inspecionar o Web Storage. No Chrome, abra o DevTools (F12), vá até a aba Application e procure "Local Storage" e "Session Storage" na barra lateral esquerda. Você pode ver cada par chave-valor, editar valores manualmente e apagar entradas. O Firefox tem um painel semelhante na aba Storage. É a forma mais fácil de ver exatamente o que um site WordPress armazena no seu navegador e de solucionar comportamentos inesperados.

O que o InspectWP verifica

O InspectWP lista todas as entradas de localStorage e sessionStorage definidas pelo seu site WordPress durante a varredura. Isso lhe dá um panorama claro do que o seu site armazena no lado do cliente, quais plugins são responsáveis e se alguma entrada pode levantar preocupações de privacidade sob o GDPR ou as regras da ePrivacy.