Segurança: o que nunca armazenar no armazenamento

localStorage e sessionStorage salvam dados sem criptografia no disco, dentro do perfil do usuário. Qualquer processo com acesso ao sistema de arquivos — incluindo malware, ferramentas de backup ou outro usuário conectado — pode ler todos os valores armazenados sem passar pelo navegador.

Todos os scripts em execução na origem compartilham o mesmo armazenamento. Um ataque XSS bem-sucedido, um SDK de terceiros comprometido ou uma extensão maliciosa do navegador pode chamar localStorage.getItem e extrair todos os valores armazenados. Não há isolamento entre scripts.

Não coloque tokens de sessão, JWTs, tokens de atualização ou chaves de API no localStorage. Se um invasor injetar uma única linha de JavaScript, o token vazará imediatamente. Use cookies httpOnly, Secure e SameSite para que o token nunca possa ser acessado pelo JavaScript.

Armazenar senhas de qualquer forma — em texto simples, com hash ou criptografadas — é errado no cliente. Aplicar hash no lado do cliente não ajuda quando o invasor pode ler o hash e reutilizá-lo. O tratamento de senhas pertence inteiramente ao servidor, usando um hash de senha dedicado, como bcrypt.

O PCI-DSS proíbe armazenar números de cartão, CVVs, dados da tarja magnética ou datas de validade no armazenamento do cliente. Em vez disso, use um provedor de pagamentos tokenizado (Stripe, Braintree, Adyen) que devolva um token de curta duração vinculado à sua origem.

Documentos de identificação governamentais, datas de nascimento completas, endereços residenciais e dados médicos atraem órgãos reguladores (GDPR, HIPAA) e invasores. Armazene apenas o que for necessário para a sessão atual, solicite novamente quando necessário e deixe o servidor manter a fonte oficial dos dados.

Um erro de XSS que vaza document.cookie é grave. O mesmo erro em uma página que armazena tokens em localStorage entrega ao invasor todos os valores armazenados de uma só vez. Trate localStorage como uma superfície em que “se um script foi comprometido, tudo foi comprometido”.

Criptografar valores com uma chave que também fica no JavaScript não oferece proteção real — o invasor que consegue ler o texto cifrado também consegue ler a chave. Os segredos reais precisam permanecer no servidor e ser emitidos novamente, nunca persistidos no cliente.

Preferências da interface (tema, barra lateral recolhida, idioma), sinalizadores de funcionalidade não sensíveis, conteúdo de rascunhos de formulários e estado temporário de assistentes são aceitáveis. Eles já são visíveis para o usuário, e o vazamento deles não permite assumir o controle da conta.

Emita a autenticação por meio de Set-Cookie: token=...; HttpOnly; Secure; SameSite=Strict. O sinalizador HttpOnly torna o cookie inacessível ao JavaScript, neutralizando a maioria das cargas úteis de XSS que roubam tokens, mesmo quando há outros erros na página.

Se precisar armazenar em cache dados aparentemente sensíveis, delimite o escopo com rigor (TTL curto, limpe ao sair da sessão, remova ao fechar a aba por meio de sessionStorage), aplique uma Política de Segurança de Conteúdo rigorosa para bloquear scripts injetados e audite todos os scripts de terceiros executados em páginas autenticadas.

Por que os tokens de autenticação armazenados em localStorage são considerados um risco de segurança?

O Armazenamento da Web é texto simples, pode ser lido por scripts e é compartilhado por origem. Nunca coloque nele tokens de autenticação, senhas, dados de pagamento ou informações pessoais regulamentadas. Mantenha os segredos em cookies httpOnly e reserve localStorage para estados inofensivos da interface que o usuário poderia ver de qualquer maneira.