Por que o cabeçalho Set-Cookie foi configurado com sucesso mas o navegador não salvou meu Cookie?
Este é o problema mais comum: o navegador não retorna erro ativamente, apenas descarta silenciosamente Cookies não conformes. Causas comuns são: SameSite=None sem Secure, Cookie Secure definido em página HTTP (exceto localhost), prefixos __Host-/__Secure- não atendem restrições, incompatibilidade de Domain/Path, excede limite de 4KB, Max-Age é 0 ou negativo. Recomenda-se primeiro colar o Set-Cookie nesta ferramenta para localizar o motivo específico pelos selos de aviso, depois abra Chrome DevTools → Application → Cookies, verifique sob o domínio correspondente se há um triângulo amarelo de aviso — ao passar o mouse você verá o motivo específico da rejeição.
Qual a diferença entre Strict, Lax e None do SameSite? Quando usar cada um?
Strict não permite envio cross-site de forma alguma, é o mais seguro mas o usuário aparecerá deslogado ao clicar em links de outros sites, adequado para Cookies de operações sensíveis como pagamentos/alteração de senha. Lax é o valor padrão do Chrome 80+, permite envio em navegação GET de nível superior (clicar em link de outro site voltando ao seu site) mas não em sub-recursos como iframe/img/script/XHR/formulários POST, sendo o valor recomendado para a maioria dos cenários. None permite envio em todos os cenários cross-site (usado para SSO login único, incorporações terceiras em iframe, chamadas de API cross-site) mas requer Secure configurado ao mesmo tempo, caso contrário o navegador rejeita imediatamente.
Por que SameSite=None deve ser acompanhado de Secure?
Esta é uma regra imposta pelo Chrome a partir da versão 80 (fevereiro de 2020), seguida por Firefox, Edge e Safari. Como SameSite=None permite explicitamente envio cross-site de Cookies, atacantes têm mais facilidade para lançar CSRF ou espionagem em cenários cross-site, sendo necessário acompanhar Secure (transmissão criptografada HTTPS) para reduzir riscos. Se seu Cookie SameSite=None for definido em HTTP, o navegador o descartará sem armazenar. Esta ferramenta detecta a combinação SameSite=None sem Secure e marca com aviso em vermelho.
Qual usar: Max-Age ou Expires? Qual a diferença?
Priorize Max-Age. Max-Age é tempo relativo (expira após quantos segundos), não depende do relógio do cliente, o navegador inicia contagem regressiva ao receber; Expires é um ponto no tempo absoluto, depende do horário local do computador do usuário (se o usuário mudar o relógio para 1970 o Cookie expira imediatamente). Quando ambos existem, Max-Age tem maior prioridade (especificado explicitamente pelo RFC 6265). Se nenhum for configurado, o Cookie se torna um «Cookie de Sessão» que expira ao fechar o navegador. Esta ferramenta dá uma dica quando Expires é configurado mas Max-Age não, recomendando adicionar Max-Age. Observe que a unidade de Max-Age é segundos, não milissegundos.
Qual a diferença entre Path=/ e não configurar Path?
Path determina em quais caminhos URL o navegador enviará o Cookie ao fazer requisições. Quando Path não é configurado, o navegador usa por padrão «o caminho da URL de resposta removendo o último segmento». Por exemplo, ao definir Cookie a partir de /api/user/login, o Path padrão é /api/user/, então requisições no caminho / e /order/ não enviarão este Cookie. Configurar Path=/ explicitamente faz com que o Cookie valha para todo o site. Observe que a correspondência de Path é correspondência de prefixo — Path=/api também corresponderá a /api/, /api/user, /api/v2/abc, etc. Cookies com prefixo __Host- exigem obrigatoriamente Path=/.
Qual a diferença entre Domain com ponto no início (como .example.com) e sem ponto?
Em navegadores modernos (versões recentes de Chrome, Firefox, Edge, Safari) os dois já são equivalentes: ambos fazem com que o Cookie valha para example.com e todos os seus subdomínios (a.example.com, b.c.example.com). O ponto no início era uma sintaxe antiga da época do RFC 2109 — o RFC 6265 já especifica que o ponto inicial é ignorado. No entanto, para legibilidade recomenda-se escrever sem ponto. Esta ferramenta dá uma dica quando Domain tem ponto inicial (não é erro, mas é uma sintaxe legada). Observe: quando Domain não é configurado o Cookie vale apenas para o host atual (subdomínios não o enviam), ao configurar Domain passa a valer para subdomínios.
O que são os prefixos __Host- e __Secure-? Posso não usar prefixos?
São prefixos de segurança de nome de Cookie introduzidos pelo RFC 6265bis para aplicar restrições rigorosas a Cookies de alta segurança: quando o navegador vê que o nome do Cookie começa com __Host-, ele exige obrigatoriamente Secure, Path=/ e nenhum Domain configurado — se qualquer condição não for atendida, ele rejeita o armazenamento imediatamente; o prefixo __Secure- exige que Secure seja configurado, podendo ter outros atributos. Não usar prefixos também funciona (a maioria dos Cookies não usa prefixos), mas para Cookies de alta segurança como identificadores de sessão, Tokens de autorização recomenda-se fortemente usar o prefixo __Host-, pois ele previne ataques de injeção de Cookie em nível de subdomínio/caminho. Esta ferramenta detecta automaticamente a conformidade de ambos os prefixos.
Cookie HttpOnly é realmente seguro? Previne XSS e CSRF?
HttpOnly impede que JavaScript leia valores de Cookie por document.cookie, sendo uma importante linha de defesa para <strong>mitigar roubo de sessão por XSS</strong>, mas não é uma solução milagrosa: atacantes XSS ainda conseguem fazer requisições no navegador do usuário (requisições levam Cookie automaticamente) para executar ações (isso é escopo de CSRF); HttpOnly também não defende contra ataques CSRF (requer SameSite ou CSRF Token). O conjunto triplo HttpOnly+Secure+SameSite=Lax/Strict usado simultaneamente é que atinge um nível básico de segurança. Cookies sensíveis (session, JWT, access_token) devem ser HttpOnly, não dê acesso ao JS do front-end sem necessidade. Esta ferramenta marca aviso para Cookies sem HttpOnly.
O que é Cookie Partitioned (CHIPS)? Quando preciso usar?
Partitioned é um novo atributo lançado pelo Chrome em resposta à eliminação de Cookies de terceiros, com nome completo Cookies Having Independent Partitioned State (CHIPS). Cookies de terceiros tradicionais (como os de publicidade/serviços incorporados definidos em vários sites) são compartilhados globalmente e podem ser usados para rastrear usuários cross-site. Com Partitioned, o navegador armazena o Cookie de terceiro separadamente por site de nível superior: o Cookie de terceiro que o usuário vê no Site A é completamente independente do visto no Site B, não podendo compartilhar identidade cross-site. Cenários de uso: componentes incorporados de vídeo/mapa/pagamento, plugins de atendimento terceiros, SSO cross-site incorporado em iframe. O uso de Partitioned requer Secure configurado ao mesmo tempo, recomendado com prefixo __Host-.
Quanto um Cookie consegue armazenar no máximo? Quantos Cookies cabem por domínio?
De acordo com RFC 6265, navegadores suportam pelo menos 4096 bytes por Cookie (incluindo nome, valor e atributos), e os navegadores principais (Chrome/Firefox/Safari/Edge) seguem esse limite — o conteúdo excedente é truncado ou descartado silenciosamente. Limites de quantidade variam por navegador: Chrome tem cerca de 180 por domínio, Firefox cerca de 150, Safari cerca de 600 (e é afetado pela política de limpeza de 7 dias do ITP); ao exceder, o navegador elimina os Cookies mais antigos por política LRU. Recomenda-se que Cookies armazenem apenas identificadores de sessão, não coloque grandes blocos de dados de negócio em Cookies (dados de negócio coloque em localStorage ou Sessão no servidor).
A ferramenta suporta copiar Set-Cookie diretamente do Chrome DevTools para analisar? Preciso remover o prefixo manualmente?
Suporta totalmente, sem necessidade de processamento manual. Você pode clicar na requisição alvo no painel Network do Chrome DevTools, clicar com o botão direito no valor de Set-Cookie na área Response Headers para copiar diretamente (para múltiplas linhas, Ctrl/⌘+clique para seleção múltipla ou copie o bloco inteiro) e colar na área de entrada desta ferramenta. A ferramenta remove automaticamente o prefixo Set-Cookie: do início de cada linha (case-insensitive), processa automaticamente espaços em branco no início/fim das linhas, lida corretamente com caracteres especiais como vírgulas e ponto e vírgula em datas Expires, e também processa corretamente valores de Cookie com aspas duplas.
Por que caracteres chineses ou especiais em valores de Cookie ficam na forma %XX?
RFC 6265 exige que valores de Cookie usem apenas um subconjunto seguro do conjunto de caracteres ASCII, não podendo conter diretamente caracteres chineses, espaços, vírgulas, ponto e vírgula, etc. Muitos frameworks de servidor ao definir Cookies fazem automaticamente codificação URL (encodeURIComponent/Percent-encoding) em caracteres não ASCII — por exemplo, «Olá» é codificado como %E4%BD%A0%E5%A5%BD. Os navegadores também mantêm a forma codificada ao devolver. Quando esta ferramenta detecta que o valor contém codificação %XX, ela exibe automaticamente o texto original decodificado por decodeURIComponent ao lado do valor bruto com uma seta verde, facilitando a visualização do conteúdo real.
Qual a diferença entre Set-Cookie e o cabeçalho de requisição Cookie?
São cabeçalhos de direções completamente diferentes: Set-Cookie é cabeçalho de resposta (servidor→navegador), aparece apenas em respostas, pode aparecer múltiplas vezes, cada vez define um Cookie com atributos completos (Secure/HttpOnly/Path/Domain, etc.); Cookie é cabeçalho de requisição (navegador→servidor), aparece apenas uma vez por requisição, contendo todos os pares name=value de Cookies que correspondem ao escopo atual de forma plana (name1=v1; name2=v2), sem nenhuma informação de atributos. Ou seja, o servidor não consegue saber na requisição se um Cookie tem HttpOnly ou Secure configurado — informações de atributos só são mantidas pelo navegador no armazenamento local. Para analisar o cabeçalho Cookie de requisição use o <a href='/network/http-cookie-parser/'>Analisador de Cabeçalho Cookie</a> complementar.
Por que meus Cookies desaparecem depois de alguns dias no Safari?
Isto é o mecanismo de Prevenção de Rastreamento Inteligente (ITP: Intelligent Tracking Prevention) do Safari agindo. A partir do ITP 2.1, se o usuário não interagir diretamente com o domínio em 7 dias (ou seja, não acessou diretamente o site do domínio), o Safari limpa todos os Cookies e dados de sites sob esse domínio, independentemente de quanto tempo Max-Age/Expires estejam configurados. Isto afeta mais serviços incorporados de terceiros, enquanto Cookies do site principal não são afetados enquanto o usuário continua acessando. Além disso, as restrições do Safari a Cookies de terceiros são mais rigorosas que as do Chrome. Soluções incluem: usar atributo Partitioned, solicitar permissão por Storage Access API ou renovar o Cookie quando o usuário acessar o site principal. A seção de solução de problemas desta ferramenta tem orientações mais detalhadas para depuração no Safari.
A ferramenta suporta análise em lote de múltiplos Set-Cookie? O conteúdo do Cookie é enviado para servidores?
Suporta análise em lote. A área de entrada suporta colar qualquer quantidade de linhas de Set-Cookie (como colar um bloco inteiro de cabeçalhos de resposta de uma vez), cada Set-Cookie é analisado com numeração independente, com múltiplos cartões de atributos exibindo atributos e avisos separadamente. Todo o processo de análise é feito totalmente localmente no seu navegador (processamento JavaScript puro no front-end), o conteúdo do Cookie não é enviado para nenhum servidor, nem são feitas requisições de rede — informações sensíveis como Session/Token que você cola não saem do seu computador, pode usar com tranquilidade.
