Guia Completo dos Flags de Segurança do Cookie|Secure / HttpOnly / SameSite / __Host-
Cookie é o método mais comumente usado para gerenciamento de sessão em aplicações Web, mas sem configuração correta pode levar a ataques como <strong>session hijacking</strong> (sequestro de sessão), <strong>CSRF</strong> (cross-site request forgery) e roubo de token via <strong>XSS</strong>. Este artigo explica o significado dos 4 principais flags que devem ser adicionados a Cookies (<code>Secure</code> / <code>HttpOnly</code> / <code>SameSite</code> / prefixo <code>__Host-</code>) e resume as armadilhas na implementação.
Estrutura do cabeçalho Set-Cookie de Cookie
Quando o servidor define um Cookie no navegador, retorna um header como o seguinte na resposta HTTP.
Set-Cookie: session_id=abc123; Path=/; Domain=example.com; Expires=Wed, 22 Apr 2026 10:00:00 GMT; Secure; HttpOnly; SameSite=Lax
Existem múltiplos atributos separados por ponto e vírgula, mas podem ser divididos em 2 tipos principais.
- <strong>atributos de escopo</strong>: Path / Domain / Expires / Max-Age — determina quando e onde o Cookie é enviado
- <strong>atributos de segurança</strong>: Secure / HttpOnly / SameSite — restringe envio/acesso
Secure — Enviar apenas via HTTPS
Cookies com o atributo <code>Secure</code> são enviados ao servidor pelo navegador <strong>apenas em conexões HTTPS</strong>. Sem ele, quando a vítima acessa o site via <code>http://</code>, o Cookie trafega em texto plano e pode ser roubado por um ataque man-in-the-middle (Man-in-the-Middle), comprometendo a sessão.
<strong>Regra de ouro:</strong> sempre adicione aos cookies de autenticação. No desenvolvimento local, cookies seguros são enviados mesmo sem HTTPS em localhost, mas não há problema se a produção pressupõe HTTPS.
HttpOnly — Inacessível a partir de JavaScript
Quando <code>HttpOnly</code> é definido, <code>document.cookie</code> não pode mais ler o cookie. Isso impede que JavaScript injetado por ataque XSS roube o cookie.
XSS é uma vulnerabilidade que ainda pode ocorrer, então considere-a essencial para cookies de sessão. Se você precisar ler o valor do Cookie pelo lado do JavaScript (por exemplo: token CSRF), a prática recomendada é <strong>criar um Cookie separado somente leitura</strong> ou passar o valor <strong>através de uma tag <meta></strong>.
SameSite — Controle de envio em solicitações entre sites
O atributo SameSite é o núcleo da proteção CSRF. Os valores são os 3 seguintes:
| Valor | Comportamento | Defesa contra CSRF |
|---|---|---|
Strict | Não enviar para solicitações entre sites (mesmo quando vindo de links externos) | O mais forte |
| <code>Lax</code> (padrão) | Enviar apenas em navegação GET de nível superior (clique de link OK, formulário POST NG) | Forte |
None | Enviar em todas as solicitações entre sites (Secure obrigatório) | Nenhum |
Navegadores modernos a partir de 2020 tratam SameSite não especificado como <code>Lax</code>, portanto, mesmo sem especificar explicitamente, você obtém proteção CSRF mínima, mas é melhor ser explícito para deixar clara sua intenção.
Ao usar <code>SameSite=None</code> em integração SSO ou incorporação de iframe, <strong>deve-se sempre adicionar Secure também</strong> conforme exigido pelos navegadores modernos. Cookies <code>SameSite=None</code> sem Secure são rejeitados pelo navegador.
Prefixo __Host- / __Secure-
Se o nome do Cookie começa com <code>__Host-</code>, o navegador força as 3 condições a seguir.
- Flag <code>Secure</code> obrigatória
- Não deve incluir o atributo <code>Domain</code> (= apenas o host exato que enviou a solicitação)
- Deve ser <code>Path=/</code>
Esses fornecem garantias poderosas de que 「não podem ser sobrescritos a partir de outros subdomínios」 e 「Cookies não podem ser colocados arbitrariamente através de falsificação de cabeçalho Host」. É mais robusto adicionar um prefixo como <code>__Host-session</code> aos Cookies de sessão.
O outro prefixo <code>__Secure-</code> apenas força o sinalizador Secure obrigatório (sem restrições de Domain / Path).
Limite de 4096 bytes
O valor do Cookie é recomendado em RFC 6265 como <strong>total de 4096 bytes</strong>. Se você colocar JSON ou arrays grandes em um Cookie, pode exceder esse limite e o navegador silenciosamente cortará. O padrão é armazenar dados grandes em sessões server-side e colocar apenas o ID da sessão no Cookie.
Exemplo de implementação: Cookie de sessão de autenticação
Um Cookie de autenticação configurado corretamente tem o seguinte formato.
Set-Cookie: __Host-session=eyJ0eXAi...; Path=/; Max-Age=3600; Secure; HttpOnly; SameSite=Lax
- <code>__Host-</code>: previne poluição de subdomínio e falsificação de host
- <code>Path=/</code>: acessível em todo o site
- <code>Max-Age=3600</code>: expira em 1 hora
- <code>Secure</code>: enviado apenas via HTTPS
- <code>HttpOnly</code>: não acessível a partir de JavaScript
- <code>SameSite=Lax</code>: não envia em POST entre sites (proteção CSRF)
Exemplo com PHP (Laravel)
// config/session.php
return [
'secure' => true, // Secure フラグ
'http_only' => true, // HttpOnly フラグ
'same_site' => 'lax', // SameSite=Lax
'path' => '/',
'cookie' => '__Host-session',
];
Exemplo com Node.js (Express)
const session = require('express-session');
app.use(session({
name: '__Host-session',
secret: process.env.SESSION_SECRET,
cookie: {
secure: true,
httpOnly: true,
sameSite: 'lax',
path: '/',
maxAge: 3600 * 1000,
},
}));
Como verificar as configurações de Cookie de um site existente
Você pode verificar instantaneamente se os Cookies do seu site ou de sites de terceiros estão configurados corretamente com a <a href="/ja/check/cookies/">ferramenta de inspeção de Cookie do DevLab</a>. Basta inserir a URL e a ferramenta analisará todos os cabeçalhos Set-Cookie retornados e exibirá diagnósticos como os seguintes.
- Presença ou ausência de Secure / HttpOnly / SameSite em cada Cookie
- Violações como <code>SameSite=None</code> sem Secure
- Consistência do prefixo __Host-
- Aviso de excesso de 4096 bytes
- Resumo geral (taxa de Secure / taxa de HttpOnly / distribuição de SameSite)
Resumo
Os flags de segurança do Cookie não devem ser definidos 「apenas por segurança」, mas sim após entender o cenário de ataque e a resposta correspondente. No mínimo, adicione <strong>Secure + HttpOnly + SameSite + prefixo __Host- + Max-Age curto</strong> aos Cookies de sessão de autenticação em produção. Para revisar as configurações dos sites existentes, recomendamos usar a <a href="/ja/check/cookies/">ferramenta de inspeção de Cookie</a>.