Skip to content

Guia Completo dos Flags de Segurança do Cookie|Secure / HttpOnly / SameSite / __Host-

Categoria:Segurança Web
Este artigo está disponível atualmente apenas em japonês. As versões traduzidas serão publicadas sequencialmente.

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.

  1. <strong>atributos de escopo</strong>: Path / Domain / Expires / Max-Age — determina quando e onde o Cookie é enviado
  2. <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 &lt;meta&gt;</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:

ValorComportamentoDefesa contra CSRF
StrictNã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
NoneEnviar 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>.