Analisador de Cabeçalho Cookie

O Analisador de Cabeçalho de Cookie decodifica cabeçalhos Cookie enviados por navegador e cabeçalhos Set-Cookie enviados por servidor em formatos estruturados e legíveis, extraindo nomes de cookie, valores e atributos de segurança como HttpOnly, Secure, SameSite, expiração, escopo de domínio e caminho. Cole um cabeçalho como session_id=abc123; Path=/; HttpOnly; Secure; SameSite=Strict e obtenha um desmembramento claro de cada atributo com explicações do que cada um faz.

Compreendendo Cookies HTTP

Cookies são o mecanismo principal da web para manter estado entre requisições. HTTP em si é stateless -- cada requisição é independente, e o servidor não tem forma embutida de lembrar que duas requisições vieram do mesmo usuário. Cookies resolvem isso deixando o servidor armazenar um pequeno pedaço de dados no navegador, que o navegador então envia de volta com cada requisição subsequente. É assim que sessões de login funcionam, como carrinhos de compras persistem através de carregamentos de página, e como sites lembram suas preferências de idioma.

O ciclo de vida do cookie começa quando um servidor inclui um cabeçalho Set-Cookie em uma resposta HTTP. Este cabeçalho contém o nome e valor do cookie, mais atributos opcionais que controlam sua lifetime, escopo e propriedades de segurança. O navegador armazena o cookie e o inclui no cabeçalho Cookie de futuras requisições para aquele domínio. Um único cabeçalho Set-Cookie define um cookie, mas um único cabeçalho Cookie pode carregar muitos cookies, separados por ponto-e-vírgula.

O que torna cookies tricky é o número de atributos que afetam seu comportamento. Os atributos Domain e Path controlam quais URLs recebem o cookie. A flag Secure restringe transmissão a HTTPS. A flag HttpOnly previne JavaScript de ler o cookie, protegendo contra ataques cross-site scripting (XSS). O atributo SameSite controla se o cookie é enviado com requisições cross-origin, que é a defesa primária contra cross-site request forgery (CSRF). Acertar esses atributos é crítico tanto para funcionalidade como para segurança, e esse analisador ajuda você a verificá-los exibindo cada atributo com uma explicação em linguagem simples do que faz.

Como Analisar um Cabeçalho de Cookie

1. Cole um valor de cabeçalho Cookie ou Set-Cookie no campo de entrada.
2. Selecione o tipo de cabeçalho (Cookie para cabeçalhos de requisição, Set-Cookie para cabeçalhos de resposta).
3. Clique em Analisar para extrair todos os cookies e seus atributos em uma visão estruturada.
4. Revise os valores decodificados, explicações de atributo e quaisquer recomendações de segurança.

Exemplos de Análise de Cabeçalho de Cookie

Analisando um Cabeçalho Cookie de Navegador

Entrada (cabeçalho Cookie):

session_id=abc123def456; theme=dark; lang=en-US; _ga=GA1.2.123456789.1609459200

Saída Analisada:

Analisando um Cabeçalho Set-Cookie de Resposta

Entrada (cabeçalho Set-Cookie):

session_id=abc123def456; Path=/; Domain=.example.com; Expires=Thu, 01 Jan 2026 00:00:00 GMT; HttpOnly; Secure; SameSite=Strict

Saída Analisada:

Quando Usar o Analisador de Cabeçalho de Cookie

• Depurando problemas de autenticação -- Inspecione cookies de sessão para verificar se estão sendo definidos corretamente com valores apropriados de domínio, caminho e expiração.
• Auditando segurança de cookie -- Verifique que cookies de sessão têm flags HttpOnly, Secure e SameSite definidas para prevenir ataques XSS e CSRF.
• Analisando cookies de terceiros -- Identifique cookies de rastreamento de analytics, publicidade e widgets de mídia social e compreenda seu escopo.
• Resolvendo problemas de cookies entre domínios -- Verifique configurações de Domain e SameSite quando cookies não estão sendo enviados em requisições cross-origin.
• Revisão de conformidade -- Inventarie todos os cookies que um site define, seus propósitos e suas lifetimes para documentação GDPR ou CCPA.
• Resposta a incidentes -- Durante um incidente de segurança, analise rapidamente todos os cookies para identificar tokens de sessão, seu escopo e se estão apropriadamente segurados.

Como Cabeçalhos de Cookie Funcionam

Cookie vs. Set-Cookie

Esses dois cabeçalhos servem direções opostas do fluxo de cookie HTTP:

• Set-Cookie é enviado pelo servidor em uma resposta para criar ou atualizar um cookie no navegador. Cada cabeçalho Set-Cookie define um cookie com seus atributos.
• Cookie é enviado pelo navegador em uma requisição, contendo todos os cookies que combinam com o domínio e caminho da URL atual. Múltiplos cookies são separados por ponto-e-vírgula.

Referência de Atributo de Cookie

Valores de Atributo SameSite

• Strict -- Cookie nunca é enviado em requisições entre sites. Melhor para cookies de sessão sensíveis.
• Lax -- Cookie é enviado em navegação de nível superior (clicar um link) mas não em subrequisições entre sites (imagens, iframes, AJAX). Esse é o padrão do navegador.
• None -- Cookie é enviado em todas as requisições entre sites. Requer a flag Secure.

Limites de Tamanho e Contagem de Cookie

Navegadores impõem limites em cookies que você deveria estar ciente:

Quando esses limites são excedidos, navegadores silenciosamente descartam os cookies mais antigos. Se sua aplicação subitamente perde estado de sessão, exceder limites de cookie é uma causa comum mas frequentemente negligenciada.

Dicas Práticas para Segurança de Cookie

A regra mais importante para cookies de sessão é sempre definir todas as três flags de segurança: HttpOnly, Secure e SameSite. A flag HttpOnly previne JavaScript de acessar o cookie via document.cookie, o que significa uma vulnerabilidade XSS não pode roubar seu token de sessão. A flag Secure garante o cookie nunca é enviado sobre HTTP não-criptografado, mesmo se um usuário acidentalmente visita a versão HTTP do seu site. E SameSite=Strict (ou no mínimo Lax) previne o cookie de ser enviado em requisições entre sites, que é a defesa primária contra ataques CSRF. Omitir qualquer uma dessas flags deixa uma brecha em sua postura de segurança.

Escopo de domínio de cookie é outra área onde erros são comuns. Se você define Domain=.example.com (com o ponto liderante), o cookie é enviado para example.com e cada subdomínio -- incluindo evil.example.com se um atacante puder registrar um subdomínio. Para cookies de sessão, é mais seguro omitir o atributo Domain inteiramente, que restringe o cookie à exata origin que o definiu. Apenas use escopo de domínio quando você genuinamente precisa compartilhar cookies em subdomínios, tal como para single sign-on entre app.example.com e api.example.com.

Observe a interação entre SameSite=None e a flag Secure. Navegadores modernos requerem Secure quando SameSite=None é definido -- se você omite Secure, o cookie é silenciosamente rejeitado. Esse requisito existe porque SameSite=None diz ao navegador para enviar o cookie em requisições entre sites, e fazer assim sobre HTTP não-criptografado exporia o cookie a sniffers de rede. Se seu cookie de terceiros está sendo silenciosamente descartado, verifique que ambos os atributos estão presentes.

Perguntas Frequentes

Por que meu cabeçalho Set-Cookie não tem efeito?

Causas comuns incluem: flag Secure faltando quando usando SameSite=None, definindo Domain para um domínio diferente da origem da resposta, o navegador bloqueando cookies de terceiros, ou Path sendo definido para um caminho que não combina com a página atual.

Qual é a diferença entre Expires e Max-Age?

Expires usa uma data absoluta (Thu, 01 Jan 2026 00:00:00 GMT), enquanto Max-Age especifica segundos a partir de agora (3600 = 1 hora). Quando ambos estão presentes, Max-Age tem precedência. Se nenhum é definido, o cookie é um cookie de sessão e é deletado quando o navegador fecha.

Como posso dizer se um cookie é um cookie de rastreamento?

Indicadores comuns incluem: nomes começando com _ga, _gid (Google Analytics), _fbp, _fbc (Facebook), ou _uet (Bing). Cookies com Domain definido para um domínio de terceiros e valores longos de Max-Age (frequentemente 1-2 anos) são tipicamente cookies de rastreamento.

Por que meus cookies não são enviados em requisições de API entre origens?

Requisições entre origens requerem configuração específica tanto no cliente como no servidor. O cliente deve definir credentials: 'include' nas opções fetch, e o servidor deve responder com Access-Control-Allow-Credentials: true e uma origem específica (não *) em Access-Control-Allow-Origin. O cookie também precisa SameSite=None; Secure para ser enviado entre origens.

O que acontece quando o limite de cookie de um navegador é atingido?

Navegadores silenciosamente removem os cookies mais antigos ou menos recentemente usados para fazer espaço para novos. Não há erro ou aviso. Se sua aplicação depende de muitos cookies, considere consolidá-los em um único cookie codificado JSON ou mover estado para sessões lado-servidor.

Como prefixos de cookie como __Secure- e __Host- funcionam?

Esses são prefixos de nome de cookie que executam requisitos de segurança adicionais. Um cookie nomeado __Secure-session deve ter a flag Secure. Um cookie nomeado __Host-session deve ter ambas Secure e Path=/, e não deve ter um atributo Domain. Esses prefixos fornecem defesa em profundidade contra ataques de manipulação de cookie.

Ferramentas Relacionadas

• Formatador de Cabeçalho HTTP - Analise e formate cabeçalhos HTTP incluindo Set-Cookie
• Explicador de Cabeçalho CORS - Compreenda cabeçalhos CORS que afetam transmissão de cookie em requisições entre origens
• Lookup de Código de Status HTTP - Procure códigos de status para respostas que definem cookies
• Analisador de User-Agent - Analise strings User-Agent para compreender qual navegador enviou os cookies
• Construtor de Comando curl - Construa comandos curl com cabeçalhos de cookie para testes