FreeToGenerate.com

As regras que os navegadores aplicam estão num rascunho que expirou em junho de 2026.

O cabeçalho Set-Cookie

O que um navegador faz com isso

Um navegador vai rejeitar este cookie de saída

Ele não é armazenado e nenhum erro aparece. A requisição seguinte simplesmente vai sem cookie, e por isso esse tipo de falha costuma surgir como um login que para de funcionar sem explicação.

Nome do cookie
__Host-session
Prefixo do nome
__Host-
  • Um cookie __Host- precisa de Path=/ exatamente. Qualquer outro caminho, ou nenhum Path, significa rejeição.

De onde vêm as regras

atributos
8
na RFC publicada
6
só no rascunho
1
definidos em outro lugar
1

A RFC 6265, o padrão publicado em 2011, contém a palavra SameSite exatamente zero vezes, e nem __Host- nem __Secure- aparecem nela. Os três estão em draft-ietf-httpbis-rfc6265bis, um Internet-Draft que nunca virou RFC — e a revisão 22, a atual, traz a data de expiração de 4 de junho de 2026. Os navegadores implementam mesmo assim. Esse é o estado real da padronização de cookies, e dá para conferir em dois documentos.

Os prefixos são aplicados por rejeição, não por aviso. Um cookie __Host- precisa de Secure, precisa de Path=/ e não pode ter Domain; um __Secure- só precisa de Secure. Errando um deles, o cookie é descartado em silêncio, então a falha parece um bug do seu aplicativo e não um problema de cabeçalho.

Os atributos e qual documento define cada um

AtributoValorDefinido em
ExpiresLeva umRFC 6265
Max-AgeLeva umRFC 6265
DomainLeva umRFC 6265
PathLeva umRFC 6265
SecureNenhumRFC 6265
HttpOnlyNenhumRFC 6265
SameSiteLeva um6265bis (rascunho)
PartitionedNenhumOutro rascunho

Regras citadas da RFC 6265 e do draft-ietf-httpbis-rfc6265bis-22. Nada é enviado — a análise acontece nesta aba.

Também disponível em: English · Español · Français · العربية

Cabeçalho Set-Cookie: atributos, SameSite e o prefixo __Host-

Monte um cabeçalho de cookie ou cole um, e descubra se o navegador vai guardá-lo ou jogá-lo fora sem dizer nada.

O que é o cabeçalho Set-Cookie?

Set-Cookie é como um servidor pede ao navegador que lembre de algo. O cabeçalho é um nome e um valor seguidos de atributos que decidem quanto tempo o cookie vive, quais requisições o levam e se o script pode lê-lo: Expires, Max-Age, Domain, Path, Secure, HttpOnly e SameSite.

Onde essas regras estão escritas surpreende mais do que as próprias regras. A RFC 6265, o padrão publicado em 2011, define os seis primeiros. Ela contém a palavra SameSite exatamente zero vezes, e nem __Host- nem __Secure- aparecem nela. Os três estão em draft-ietf-httpbis-rfc6265bis, um Internet-Draft que nunca virou RFC — e a revisão 22, a atual, traz a data de expiração de 4 de junho de 2026.

Todos os navegadores implementam o rascunho. Então as regras que decidem se o seu cookie de sessão é seguro estão, formalmente, num documento expirado, enquanto o que é padrão não diz nada sobre elas. As duas coisas dá para conferir em dois arquivos, e esta página marca de qual documento vem cada atributo.

Como usar

  1. Digite ou cole o cabeçalho. Só o valor do campo, sem o prefixo Set-Cookie:. Os botões de atributo e o campo de texto são a mesma coisa, então mexer num reescreve o outro.
  2. Leia o veredito primeiro. A linha de cima diz se o navegador vai guardar o cookie ou rejeitá-lo, porque esses são os dois únicos desfechos que importam e o segundo é invisível em execução.
  3. Se for rejeitado, use o botão de correção. Ele reescreve o cookie com o prefixo __Host- e os três atributos que esse prefixo exige, que é a forma mais forte que um cookie pode ter.

Os prefixos são aplicados no silêncio

Um cookie cujo nome começa com __Host- precisa ter Secure, precisa ter Path=/ exatamente e não pode ter atributo Domain. Um que começa com __Secure- só precisa de Secure. Erre qualquer um deles e o navegador não avisa nem registra nada — ele simplesmente se recusa a guardar o cookie, e a próxima requisição chega sem ele. É por isso que esse tipo de erro costuma aparecer como um login que parou de funcionar, e não como um problema de cabeçalho.

Os dois prefixos não são a mesma regra, e tratá-los igual é o erro comum. __Secure- permite Domain e qualquer Path; __Host- proíbe o Domain justamente porque é isso que prende o cookie a um host exato em vez de compartilhá-lo com todos os subdomínios. Se um subdomínio que você não controla totalmente pode setar cookies, essa diferença é toda a fronteira de segurança.

Os prefixos também diferenciam maiúsculas de minúsculas, nas palavras da própria especificação. Um nome começando com __host- em minúsculas não recebe proteção alguma enquanto aparenta exatamente o contrário, então esta página relata isso como achado próprio em vez de ficar calada.

SameSite=None segue o mesmo padrão: exige Secure, e sem ele o cookie é rejeitado. Isso pega fluxos incorporados e entre sites o tempo todo, porque o valor que soa mais permissivo é o que tem uma exigência extra grudada.

O que esta página não faz

Ela confere um cabeçalho isolado. Não tem como saber se você está em HTTPS, e cookies Secure são descartados em HTTP puro por mais correto que o cabeçalho pareça; nem conhece o seu domínio, então não pode dizer se o Domain que você definiu é um que você tem permissão de definir.

Ela também não impõe Partitioned, o atributo do CHIPS. Partitioned aparece zero vezes na revisão 22 da 6265bis — está num rascunho separado —, então esta página o lista como definido em outro lugar em vez de fingir que ele pertence ao mesmo documento que o resto.

E ela apresenta o que as especificações dizem, não o que o seu framework faz. A maioria seta cookies por um auxiliar com padrões próprios, e vários setam SameSite=Lax por você, pedindo ou não. Conferir o cabeçalho que você realmente envia é o passo útil; esta página diz o que aquele cabeçalho significa.

Por que é grátis?

As regras são uma tabela pequena e a análise acontece no seu próprio navegador. Nada do que você digita é enviado, nada é registrado e não há conta a criar.

Sem cadastro, sem limites e sem marca d'água em nada que você copiar.