HttpOnly, Secure e SameSite: o que cada atributo do cookie protege
Três atributos de uma linha de configuração resolvem a maior parte dos sequestros de sessão. Entenda o que cada um impede.
Bruno Alexandre·14/10/2026·6 leituras
Um cookie de sessão é uma credencial, e a boa notícia é que a maior parte dos sequestros acontece porque três atributos simples não estavam presentes.
As partes de um cookie de sessão e o que cada atributo protege
O HttpOnly impede que scripts da página leiam o valor do cookie. Sem ele, qualquer erro de script, biblioteca de terceiro desconhecida ou extensão maliciosa instalada no navegador vira um sequestro de sessão completo. Com ele, o script até consegue executar, mas não consegue levar o token. É a diferença entre um incidente e um incidente automatizado em escala.
O Secure exige que o cookie só seja enviado por conexão criptografada. Sem ele, o token viaja em texto legível, e qualquer equipamento no caminho entre o navegador e o servidor consegue copiá-lo. Com ele, a rede aberta deixa de ser um problema, porque não há nada legível no caminho.
O SameSite limita o envio do cookie em requisições originadas de outros sites. Ele corta o ataque por link, em que a vítima clicou em um endereço e o navegador entregou o cookie junto sem a pessoa perceber. O valor Lax é o padrão razoável, e o Strict funciona bem em painéis administrativos, onde quase todo acesso é interno.
O detalhe que costuma passar batido é o Domain. Um cookie sem escopo bem definido, com o domínio amplo demais, é entregue para subdomínios que ninguém do time avaliou. O cookie de sessão da aplicação deve ficar preso ao host que realmente precisa dele.
Nada disso substitui HTTPS, troca de token no login e monitoramento de acessos. Mas são as três primeiras medidas, e elas estão na mesma linha de configuração.
Em 21 de outubro de 2026 o PHP corrigiu duas falhas críticas que permitem executar código sem qualquer autenticação. Quem tem site em PHP precisa atualizar hoje.
