Cookies HTTP Como Construir e Analisar-los Corretamente

Os cookies HTTP estão por toda parte. Cada sessão de login, carrinho de compras e ferramenta de análise depende deles. No entanto, a maioria dos desenvolvedores copia e cola uma Set-Cookie cabecalho e passa para frente sem entender o que os atributos realmente fazem — ou o que acontece quando eles são mal configurados.

Este guia aborda a anatomia dos cookies, todos os atributos significativos, como interpretar strings de cookies e por que SameSite é sua defesa contra CSRF. Se quiser começar imediatamente, tente o IO Tools Parser de Cookie ou o Construtor de Cookie.

O que um Cookie Realmente Parece

Quando um servidor deseja definir um cookie, ele envia um Set-Cookie cabeçalho de resposta:

Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=86400

O navegador armazena isso e o envia de volta em solicitações subsequentes como:

Cookie: sessionId=abc123

Isso é o mecanismo completo. A complexidade está nos atributos.

Anatomia do Cookie: Desmembrando a String

Uma string de cookie segue um formato consistente:

name=value; attribute1; attribute2=attributeValue; ...

O name=value par de chave-valor vem primeiro. Tudo após a primeira vírgula é uma diretiva para o navegador — o servidor nunca vê esses atributos no Cookie cabeçalho que recebe.

Os Atributos de Segurança que Você Deve Configurar Corretamente

HttpOnly

HttpOnly impede que JavaScript leia o cookie via document.cookie. Isso é uma defesa direta contra ataques XSS que roubam tokens de sessão.

Set-Cookie: sessionId=abc123; HttpOnly

Qualquer cookie que autentica um usuário deve ter HttpOnly. Não há boa razão para não fazê-lo.

Seguro

Secure significa que o navegador envia o cookie apenas em conexões HTTPS. Sem isso, o cookie viaja em texto claro por HTTP e pode ser interceptado. Em produção, cookies de sessão sempre precisam Secure. Em desenvolvimento local sobre http://localhost, é possível omiti-lo — os navegadores fazem uma exceção para localhost.

SameSite

SameSite controla quando o navegador inclui um cookie em solicitações entre sites. Essa é a principal defesa contra ataques CSRF. Três valores:

• Strict — o cookie nunca é enviado em solicitações entre sites. Mais seguro, mas os usuários que clicam em um link de e-mail acabam deslogados (o cookie não é enviado nessa navegação inicial).
• Lax — o cookie é enviado em navegações de nível superior (solicitações GET) de sites externos, mas não em solicitações embutidas entre sites ou POSTs entre sites. Isso é a configuração padrão dos cookies sem um atributo explícito SameSite .
• None — o cookie é enviado em todas as solicitações entre sites. Obrigatório para cookies de terceiros (fluxos OAuth, widgets embutidos). Deve ser combinado com Secure.

# Third-party / cross-site cookie (e.g., OAuth callback)
Set-Cookie: token=xyz; SameSite=None; Secure

Se você enviar SameSite=None sem Secure, os navegadores modernos rejeitam o cookie inteiramente. Para a maioria dos cookies de sessão, use SameSite=Lax — ele equilibra segurança com uma experiência de login útil.

Escopo: Domínio e Caminho

Domínio

O Domain atributo especifica quais nomes de domínio recebem o cookie.

Set-Cookie: user=alice; Domain=example.com

Com Domain=example.com, o cookie é enviado para example.com e todos os subdomínios (api.example.com, app.example.com). Sem um atributo Domain , o cookie é enviado apenas para a origem exata que o definir — não para subdomínios.

Conceito comum: definir Domain=example.com não não restringe o cookie apenas a example.com. Ele amplia o escopo para incluir subdomínios. Omita o atributo se quiser um cookie de único domínio.

Caminho

Path limita quais caminhos de URL desencadeiam o envio do cookie.

Set-Cookie: adminToken=xyz; Path=/admin

Este cookie acompanha apenas solicitações para /admin e caminhos abaixo dele. Uma solicitação para / ou /api não incluiria esse cookie. O padrão é /, o que significa todos os caminhos.

Max-Age vs Expires

Ambos controlam quando o cookie expira. Prefira Max-Age.

• Expires aceita uma data absoluta no formato HTTP date. Isso é relativo ao relógio do cliente, que você não controla.
• Max-Age aceita um número de segundos a partir do momento atual: Max-Age=86400 para 24 horas. Relativo à intenção do servidor, não ao relógio do cliente.

Quando ambos estão presentes, Max-Age tem prioridade. Um cookie sem nenhum atributo é um cookie de sessão — desaparece quando o navegador é fechado.

Referência de Atributos de Cookie

Atributo	O que faz	Padrão	Recomendação
HttpOnly	Bloqueia o acesso do JavaScript ao cookie	Não definido	Sempre definido para cookies de autenticação
Secure	Transmissão apenas por HTTPS	Não definido	Sempre definido em produção
SameSite	Controla o envio entre sites	Lax (navegadores modernos)	Lax para sessões; Nenhum + Seguro para terceiros
Domain	Define o escopo do nome do host	Somente o host atual	Omita a menos que seja necessário acesso entre subdomínios
Path	Define o escopo do caminho	/	Deixe como / a menos que seja necessário isolar tokens de administração
Max-Age	Segundos até a expiração	Cookie de sessão	Prefira sobre Expires
Expires	Data absoluta de expiração	Cookie de sessão	Use Max-Age em vez disso

Definindo Cookies no Código

Node.js (Express)

app.post('/login', (req, res) => {
  // ... verify credentials ...

  res.cookie('sessionId', token, {
    httpOnly: true,
    secure: process.env.NODE_ENV === 'production',
    sameSite: 'lax',
    maxAge: 86400 * 1000, // milliseconds in Express
    path: '/',
  });

  res.json({ ok: true });
});

Python (FastAPI)

from fastapi import FastAPI, Response

app = FastAPI()

@app.post("/login")
def login(response: Response):
    # ... verify credentials ...

    response.set_cookie(
        key="sessionId",
        value=token,
        httponly=True,
        secure=True,
        samesite="lax",
        max_age=86400,
        path="/",
    )
    return {"ok": True}

Parseando Cabeçalhos de Cookie Manualmente

O Cookie cabeçalho que o servidor recebe contém apenas name=value pares, separados por ; :

Cookie: sessionId=abc123; theme=dark; lang=en

Para interpretar manualmente: divida por ; (vírgula + espaço), depois divida cada par pela primeira apenas. Casos especiais para saber: = Os valores podem conter

• (strings base64 comuns) — sempre divida pela primeira = apenas = Os nomes de cookie são sensíveis a maiúsculas e minúsculas
• Espaços ao redor do separador podem variar — trime ambas as partes com cuidado
• Em vez de escrever a lógica de divisão por si mesmo, use o

para decodificar qualquer IO Tools Parser de Cookie cabeçalho e inspecionar cada valor, ou o Cookie IO Tools Construtor de Cookie para construir um cabeçalho válido de cookie com os atributos corretos. Cookies e CSRF Set-Cookie O Cross-Site Request Forgery explora o fato de que os navegadores incluem automaticamente cookies em solicitações a um domínio, mesmo quando iniciadas por um site diferente. Uma página maliciosa em

pode enviar um formulário para

, e se o usuário estiver logado, o navegador envia seu cookie de sessão junto com a solicitação falsa. evil.com defende a maioria dos vetores CSRF porque as solicitações entre sites — o padrão de ataque — não incluem o cookie. bank.com/transferé ainda mais abrangente, mas pode afetar a usabilidade.

SameSite=Lax Tokens CSRF permanecem válidos como defesa em camadas, especialmente para operações de alto risco e quando SameSite=Strict é exigida para contexto de terceiros. As duas defesas se complementam.

Cookies HTTP: Como Construir e Interpretar Eles Corretamente 2 SameSite=None Cookies HTTP: Como Construir e Interpretar Eles Corretamente 1

Você também pode gostar