Atributos de cookie: Secure, HttpOnly, SameSite, Domain, Path e o prefixo __Host-

O que é

Um cabeçalho Set-Cookie contém um nome, um valor e atributos. A RFC 6265 e o draft que a sucede (rfc6265bis, que acrescenta SameSite e prefixos) os definem:

• Domain: se for omitido, o cookie volta apenas ao host de origem (host-only). Se for definido como example.com, é enviado a esse host e a todos os subdomínios. Um valor que não abranja a origem é rejeitado, e a RFC 6265 observa que muitos user agents rejeitam também sufixos públicos como co.uk.
• Path: por padrão assume o diretório do caminho da requisição; a correspondência é feita por prefixo. A RFC 6265 afirma que "não se pode confiar nele para segurança".
• Secure: o cookie só é enviado por canais seguros. A RFC 6265 avisa que protege a confidencialidade, não a integridade; o draft acrescenta que origens não seguras não podem sobrescrever um cookie seguro já existente.
• HttpOnly: o cookie fica fora do alcance de APIs que não sejam HTTP, como document.cookie, mas continua sendo enviado com fetch e XMLHttpRequest.
• SameSite: Strict envia apenas em requisições do mesmo site; Lax envia também em navegações de nível superior entre sites com métodos seguros; None envia em todos os casos e é rejeitado, a menos que Secure também esteja definido. A MDN observa que alguns navegadores tratam a ausência do atributo como Lax.
• Max-Age e Expires: Max-Age prevalece quando ambos estão presentes; sem nenhum dos dois, o cookie é de sessão.
• Prefixos: um nome que começa com __Secure- só é aceito com Secure; __Host- exige adicionalmente Path=/ e ausência de Domain, de modo que o cookie fica preso a um único host. O draft afirma que as portas são a única parte do modelo de origem que os cookies __Host- continuam ignorando.

Por que importa

Os cookies não estão vinculados a origens. A RFC 6265 afirma que não oferecem isolamento nem por porta nem por esquema; um subdomínio pode definir um cookie para o domínio pai e ocultar o cookie do próprio pai. O cabeçalho de requisição Cookie não transporta atributos, por isso o servidor não consegue saber como o cookie foi definido; os prefixos existem para lhe dar essa certeza.

Como aplicar

• Cookie de sessão: __Host-session=<id>; Secure; HttpOnly; SameSite=Lax; Path=/; Max-Age=<seconds>.
• Omita Domain, a menos que os subdomínios precisem compartilhar o cookie; nesse caso, aceite que qualquer subdomínio pode sobrescrevê-lo.
• SameSite=Strict para cookies usados apenas dentro da aplicação; Lax para logins que precisam sobreviver à chegada por um link externo; None apenas para uso incorporado entre sites, sempre com Secure.
• Não separe duas aplicações no mesmo host por meio de Path; dê a elas hosts distintos.
• Para apagar, defina o cookie novamente com o mesmo nome, Domain e Path e com Max-Age=0.

Armadilhas

Um ponto inicial em Domain é ignorado; um ponto final faz com que o atributo seja ignorado. A RFC 6265 diz que os user agents de uso geral devem suportar pelo menos 4096 bytes por cookie e 50 cookies por domínio; acima desses limites, os cookies podem ser descartados silenciosamente. Dois serviços em portas diferentes do mesmo host veem os cookies um do outro.