flawopen.com/Referência/JWT vs. cookies HttpOnly
JWT no localStorage vs. cookies HttpOnly: o que é mais seguro?
Para muitos aplicativos web, uma sessão gerenciada no servidor e entregue em um cookie HttpOnly é um bom padrão inicial. O JavaScript não consegue ler esse cookie, o que reduz a extração do token, mas não neutraliza XSS: código injetado da mesma origem ainda pode fazer requisições autenticadas e ler dados disponíveis à página.
Os compromissos de segurança
| Armazenamento / envio | Exposição a XSS | Comportamento CSRF | Revogação |
|---|---|---|---|
localStorage bearer token | JavaScript da mesma origem pode ler; XSS pode roubá-lo ou agir como usuário. | Não é anexado automaticamente a requisições entre sites; XSS e CSRF do lado do cliente continuam sendo riscos. | JWT autocontido pode valer até expirar, salvo se a revogação for verificada. |
HttpOnly cookie | JavaScript não lê o valor; XSS ainda pode enviar requisições autenticadas. | Enviado automaticamente pelas regras de cookie; SameSite é apenas uma camada CSRF. | Sessão opaca pode ser invalidada no servidor; JWT em cookie precisa de política própria. |
Arquitetura recomendada
- ✓Guarde os identificadores de sessão em cookies
HttpOnly; Secure; SameSite=Lax. - ✓Evite guardar tokens de autenticação persistentes em
localStorageousessionStorage.
Separe formato do token, armazenamento e estado da sessão
JWT é um formato de token; localStorage e cookies são mecanismos de armazenamento e envio no navegador. Um JWT pode ser guardado em qualquer um deles. Um identificador de sessão opaco em cookie normalmente aponta para o estado mantido no servidor. “JWT ou cookie” não é uma comparação direta entre alternativas equivalentes.
O que cada escolha muda
O navegador não anexa automaticamente valores de localStorage a requisições entre sites, mas XSS na mesma origem pode ler um bearer token armazenado ou agir pelo aplicativo. Cookies são enviados automaticamente conforme as regras do navegador; HttpOnly oculta o valor do JavaScript, mas não impede que código injetado use a página autenticada. SameSite=Lax é uma camada CSRF, não uma garantia completa: navegações de nível superior com métodos seguros e requisições same-site ainda importam. Não altere estado com GET e use uma defesa CSRF adequada, como tokens validados e/ou verificação de Origin.
A revogação depende do estado no servidor e da validação do token, não do local de armazenamento. Uma sessão no servidor pode ser invalidada removendo seu registro. Um JWT autocontido pode continuar aceito até expirar, a menos que o verificador consulte o estado de revogação; validade curta reduz essa janela, mas não a elimina.
Ponto de partida prático
- ✓Em um aplicativo web próprio, prefira uma sessão opaca mantida no servidor ou um Backend-for-Frontend (BFF), quando adequado.
- ✓Configure cookies de sessão com
Secure,HttpOnly,SameSiteintencional,Path=/e, quando possível, semDomain; considere__Host-. - ✓Use tokens CSRF e/ou validação de Origin em requisições que alteram estado conforme o modelo de ameaça; nunca altere estado via
GET. - ✓Se JWTs no navegador forem necessários, use validade curta, defina logout/revogação e previna XSS. Cookie não substitui verificações de autorização.