Como verificar a segurança dos cookies: Secure, HttpOnly, SameSite e prefixos de cookie

Quando alguém faz login no seu site, o servidor normalmente entrega ao navegador dessa pessoa um cookie de sessão. A partir daí, quem estiver de posse desse cookie é esse usuário. Os atributos do cookie determinam quando o navegador o envia, por quais conexões e se os scripts da página podem lê-lo. Acertar custa uma linha de configuração; errar pode transformar um bug pequeno em um sequestro de conta.

Os atributos que importam

Secure

Secure diz ao navegador para enviar o cookie somente por HTTPS. Sem ele, o cookie pode trafegar em uma requisição HTTP comum — por exemplo, quando alguém digita o seu domínio sem https://, antes de o redirecionamento acontecer —, e aí qualquer pessoa na mesma rede consegue lê-lo. Em um site HTTPS, todo cookie deve ser Secure.

HttpOnly

HttpOnly esconde o cookie do JavaScript (document.cookie). Se um invasor conseguir injetar um script na sua página, ele não poderá simplesmente ler um cookie de sessão e enviá-lo para outro lugar. Use-o em cookies de sessão e de autenticação. Os cookies que o seu próprio código de front-end precisa ler, como um token CSRF que alguns frameworks expõem de propósito ao JavaScript, não podem ser HttpOnly — e isso é esperado.

SameSite

SameSite controla se o cookie é enviado quando a requisição vem de outro site:

• SameSite=Strict: enviado apenas em requisições que começam no seu próprio site. É o mais seguro, mas um visitante que segue um link de um e-mail para o seu site chega parecendo deslogado.
• SameSite=Lax: enviado em navegações de nível superior, como o clique em um link, mas não em envios de formulário, imagens ou frames entre sites. Um bom padrão para cookies de sessão.
• SameSite=None: enviado em qualquer contexto entre sites, necessário para widgets incorporados e alguns fluxos de login único (SSO). Precisa ser combinado com Secure, ou os navegadores rejeitam o cookie.

Os navegadores baseados em Chromium tratam um cookie sem o atributo SameSite como Lax, mas nem todo navegador se comporta assim; portanto, defina-o explicitamente.

Domain e Path

Se você omitir Domain, o cookie fica restrito ao host (host-only): enviado apenas ao host exato que o definiu. Definir Domain=example.com o compartilha com todos os subdomínios, inclusive aqueles esquecidos em outra hospedagem, que podem ser menos seguros. Só amplie o escopo quando você realmente precisar compartilhar um login entre subdomínios.

Expires e Max-Age

Sem Expires ou Max-Age, o cookie deveria durar apenas a sessão do navegador, embora navegadores que restauram sessões possam mantê-lo por mais tempo. Para logins persistentes, escolha uma duração compatível com o risco e garanta que o servidor também expire as sessões do lado dele.

Prefixos de cookie: __Host- e __Secure-

Os prefixos no nome do cookie fazem o navegador aplicar as regras por você. Um cookie cujo nome começa com __Secure- só é aceito se tiver o atributo Secure e tiver sido definido por HTTPS. Um cookie que começa com __Host- é mais rigoroso: precisa ser Secure, ser definido por HTTPS, ter Path=/ e não ter o atributo Domain. Isso o prende a um único host, de modo que um subdomínio comprometido ou descuidado não consegue sobrescrevê-lo.

Para um cookie de sessão que não precisa ser compartilhado entre subdomínios, __Host- é a opção mais forte disponível: Set-Cookie: __Host-session=…; Secure; HttpOnly; SameSite=Lax; Path=/.

Como verificar os seus cookies

1. No navegador. Abra as ferramentas de desenvolvedor, vá até Application (Chrome, Edge) ou Storage (Firefox), depois Cookies, e selecione o seu site. A tabela mostra as colunas Domain, Path, Expires, HttpOnly, Secure e SameSite de cada cookie.
2. Na resposta bruta. Na aba Network (Rede), clique na requisição do documento e leia os cabeçalhos de resposta Set-Cookie. Isso mostra exatamente o que o servidor enviou, inclusive atributos que o navegador possa ter rejeitado.
3. Depois do login. Muitos sites só definem os cookies importantes após o login ou quando um carrinho é criado; então verifique de novo nessas páginas.
4. Com um verificador. O verificador de segurança gratuito do Rudra lê os cabeçalhos Set-Cookie da resposta da própria página e aponta cookies sem Secure em HTTPS, cookies com cara de sessão sem HttpOnly, SameSite=None sem Secure, cookies sem SameSite e cookies com escopo no domínio pai.

Vale conhecer dois limites da verificação automática. Ela decide se um cookie tem "cara de sessão" pelo nome (nomes que contêm trechos como sess, sid, token ou auth); por isso, reporta esses apontamentos com confiança média: confirme o que o cookie realmente guarda. E ela só enxerga os cookies definidos por aquela única resposta — não os definidos depois por JavaScript, por outras páginas, após o login ou por terceiros. Os valores dos cookies nunca são lidos nem armazenados.

Como definir os atributos de cookie nas plataformas mais comuns

• Sessões PHP: no php.ini, defina session.cookie_secure = 1, session.cookie_httponly = 1 e session.cookie_samesite = "Lax" (PHP 7.3 ou superior), ou passe as mesmas opções para session_set_cookie_params().
• Django: SESSION_COOKIE_SECURE = True e CSRF_COOKIE_SECURE = True. SESSION_COOKIE_HTTPONLY e SESSION_COOKIE_SAMESITE = "Lax" já são os padrões.
• Express (Node.js): res.cookie("sid", value, { secure: true, httpOnly: true, sameSite: "lax" }), ou as opções cookie do express-session. Atrás de um proxy, ative trust proxy para que o Express saiba que a conexão é HTTPS.
• WordPress: os cookies de login do núcleo são HttpOnly e marcados como Secure quando o site roda em HTTPS. Os cookies de plugins variam; confira-os nas ferramentas de desenvolvedor e fale com os autores do plugin se estiverem sem os atributos.
• Proxy reverso como último recurso: a diretiva proxy_cookie_flags do nginx (1.19.3 ou superior) pode adicionar secure, httponly e samesite aos cookies de uma aplicação que você não pode alterar.

Erros comuns

• Marcar os cookies como Secure em produção, mas testar só por HTTP localmente e depois desativar o atributo "temporariamente".
• Definir SameSite=None sem Secure, o que faz os navegadores descartarem o cookie e um login ou conteúdo incorporado parar de funcionar.
• Dar aos cookies de sessão o escopo do domínio pai "por via das dúvidas".
• Guardar tokens de sessão no localStorage, onde qualquer script injetado consegue lê-los — cookies HttpOnly são mais seguros.
• Colocar dados pessoais nos valores dos cookies. Cookies devem guardar identificadores, não informações.

Os cookies são só uma parte do quadro. Para cabeçalhos, HTTPS e os limites dos testes passivos, leia como verificar a segurança de um site.