Validador de prefixos de cookies HTTP｜Regras __Host- e __Secure- linha a linha

Cole seus cabeçalhos Set-Cookie e a ferramenta verifica cada linha conforme as regras do RFC 6265bis para os prefixos __Host- e __Secure-. Cada linha recebe um selo PASS / FAIL, e as linhas com falha apontam qual requisito foi quebrado ao lado de uma tabela com os atributos analisados: Path, Domain, Secure, HttpOnly, SameSite. Sem servidor: basta colar e ler.

💡 Sobre esta ferramenta

__Host- e __Secure- são prefixos de cookie: prefixos especiais no nome que fazem o navegador exigir certos atributos. Se o nome de um cookie começa por um deles e os requisitos não são atendidos, o navegador ignora silenciosamente todo o cabeçalho Set-Cookie. Esse descarte silencioso é justamente o que transforma um "configurei __Host-session mas o usuário nunca faz login" numa tarde inteira de depuração.

Os dois prefixos pedem coisas diferentes. __Secure- exige apenas o atributo Secure. __Host- é mais rígido: além de Secure, requer Path=/ (exatamente a raiz) e nenhum atributo Domain. Remover Domain fixa o cookie ao host exato que o emitiu, o que bloqueia o cookie tossing entre subdomínios: um atacante em evil.example.com não consegue gravar um cookie que chegue a app.example.com. No momento em que se coloca um CDN ou um balanceador na frente de uma arquitetura multi-host, é essa distinção que mais passa despercebida.

A ferramenta recebe um lote inteiro de linhas Set-Cookie, detecta o prefixo de cada uma e aplica somente as regras que aquele prefixo ativa. As linhas com falha trazem motivos como "__Host- não pode ter o atributo Domain", então dá para colar uma cópia dos seus cabeçalhos de produção diretamente, ou levar a mesma checagem mental para uma revisão de código antes de chegar à CI.

🧐 Perguntas frequentes

Qual a diferença entre __Host- e __Secure-? O rigor. __Secure- precisa só do atributo Secure. __Host- precisa de Secure mais Path=/ exato e sem atributo Domain. __Host- oferece a maior garantia de vínculo a um host.

Os prefixos diferenciam maiúsculas de minúsculas? Não. O navegador trata __Host- e __host- (minúsculo) como o mesmo prefixo e aplica as mesmas regras. O RFC 6265bis passou a comparar sem diferenciar maiúsculas para fechar um bypass: um servidor que compara nomes de cookie sem diferenciar maiúsculas poderia ser enganado por uma variante minúscula enviada sem Secure. A ferramenta também aplica as regras sem diferenciar maiúsculas.

Por que um cookie __Host- com Path=/api falha? __Host- exige Path=/, exatamente a raiz. Um subcaminho como /api quebra o requisito e o navegador descarta o cookie. Se precisa restringir o caminho, use __Secure-.

Como são tratadas as linhas sem prefixo? Uma linha sem prefixo privilegiado não tem requisito a verificar, então é marcada como PASS e rotulada "(sem prefixo)". A tabela de atributos é exibida mesmo assim para conferir o que foi de fato configurado.

Algo que eu colo sai da minha máquina? Não. Cada linha é analisada no seu navegador e os cabeçalhos Set-Cookie que você cola nunca são enviados a um servidor, então colar nomes e valores reais de produção permanece local.

📚 Por que a regra mora no nome, e não num atributo

O truque por trás de __Host- e __Secure- é que o requisito está embutido no nome em vez de ser carregado como atributo. Um cabeçalho Set-Cookie vai do servidor ao navegador com todos os seus atributos, mas quando o navegador depois devolve o cookie (o cabeçalho de requisição Cookie), só o nome e o valor viajam: Secure, Path e os demais sumiram. Por isso o servidor não consegue inspecionar um cookie recebido e confirmar que ele foi guardado com Secure. O prefixo fecha essa brecha: codifique o requisito no nome, e a simples chegada de um cookie chamado __Host-session é a prova de que o navegador impôs Secure e vínculo ao host ao guardá-lo, porque a especificação obriga o navegador a descartar em silêncio qualquer Set-Cookie não conforme. Garantir segurança por uma convenção de nomes em vez de um atributo novo é também a razão de os prefixos terem sido implantados de forma retrocompatível: eles se apoiam no formato de cookie existente sem mudar um único byte da sua gramática.