Receitas de cookies primários

Saiba como definir cookies primários para garantir segurança, compatibilidade com vários navegadores e minimizar as chances de falhas quando os cookies de terceiros forem desativados.

Milica Mihajlija

Os cookies podem ser primários ou de terceiros em relação ao contexto do usuário. dependendo do site em que o usuário está no momento. Se o domínio registrável e o esquema do cookie corresponderem à página de nível superior atual, ou seja, ao que aparece na barra de endereço do navegador, o cookie será considerado do mesmo site que a página e geralmente é chamado de cookie primário.

Os cookies de domínios que não são o site atual geralmente são chamados de cookies de terceiros.

Se o cookie configurado não for usado entre sites (por exemplo, para gerenciar sessões no site e nunca em um iframe entre sites), ele será sempre usado em um contexto próprio.

Por padrão, os cookies podem ser compartilhados entre sites, acessados por JavaScript e enviados por conexões HTTP, o que traz alguns riscos de privacidade e segurança. Embora exista um trabalho contínuo para melhorar o comportamento padrão, com o Sandbox de privacidade e outras propostas, como cookies vinculados à origem, você pode fazer muito mais definindo atributos adicionais nos cookies.

A configuração a seguir é a prática recomendada, garantindo segurança e compatibilidade entre navegadores para a maioria dos cookies primários. Ele vai proporcionar uma base segura, que pode ser ajustada para liberar permissões apenas quando necessário. Este artigo também aborda variações de receitas para alguns casos de uso específicos.

A receita

Set-Cookie:
__Host-cookie-name=cookie-value;
Secure;
Path=/;
HttpOnly;
Max-Age=7776000;
SameSite=Lax;
Detalhes

Host é um prefixo opcional que torna alguns atributos obrigatórios e proíbe outros:

  • Secure precisa estar presente
  • Domain precisa ser omitido
  • Path precisa ser /

Com Host adicionado, você pode confiar no navegador para verificar se esses atributos estão definidos de acordo com as regras do __Host e rejeitar o cookie se não estiverem.

O Secure protege os cookies contra roubo em redes não seguras porque permite o envio de cookies apenas por conexões HTTPS. Se você não migrou totalmente seu site para HTTPS, defina isso como uma prioridade.

O atributo Domain especifica quais hosts podem receber um cookie. A omissão dele restringe o cookie ao host atual do documento, excluindo subdomínios: o cookie de example.com será enviado em todas as solicitações para example.com, mas não para images.example.com. Se você tiver diferentes apps em execução em subdomínios diferentes, isso reduzirá o risco de um domínio comprometido permitir a entrada de outros.

Path indica o caminho que precisa existir no URL solicitado para o navegador enviar o cabeçalho Cookie. Definir Path=/ significa que o cookie será enviado para todos os caminhos de URL nesse domínio. A combinação de nenhum Domain e Path=/ torna o cookie vinculado à origem o mais próximo possível. Assim, ele se comporta de maneira semelhante a outro armazenamento do lado do cliente, como LocalStorage. Não há confusão de que example.com/a pode receber valores diferentes para example.com/b.

O atributo HttpOnly adiciona proteção contra scripts maliciosos de terceiros nos seus sites restringindo o acesso ao JavaScript. Ele permite que um cookie seja enviado somente nos cabeçalhos da solicitação e os torna indisponíveis para JavaScript usando document.cookie.

O Max-Age limita a vida útil de um cookie, já que as sessões do navegador podem durar muito tempo, e você não quer que os cookies obsoletos fiquem para sempre. Ela é boa para cookies de curto prazo, como sessões do usuário, ou até mesmo mais curtos, como tokens para envio de formulário. Max-Age é definido em segundos e no exemplo anterior como 7776.000 segundos, ou seja, 90 dias. Esse é um padrão razoável, que pode ser alterado dependendo do seu caso de uso.

O SameSite=Lax restringe o envio do cookie apenas para solicitações no mesmo site. Ou seja, quando a solicitação corresponde ao contexto de navegação atual, ou seja, o site de nível superior que o usuário está visitando no momento, que é exibido na barra de localização dele. SameSite=Lax é o padrão em navegadores modernos, mas é recomendável especificá-lo para compatibilidade com navegadores que podem ter padrões diferentes. Ao marcar explicitamente o cookie como somente do mesmo site, você o restringe aos seus contextos primários e não precisa fazer alterações nesse cookie quando os cookies de terceiros forem desativados.

Para saber mais sobre diferentes atributos de cookies, confira a Set-Cookie documentação sobre MDN.

Se você tiver um site com subdomínios e quiser ter uma sessão em todos eles, o prefixo Host poderá ser muito restritivo. Por exemplo, news.site pode ter subdomínios para temas como finance.news.site e sport.news.site, e você gostaria de ter uma sessão de usuário em todos eles. Nesse caso, use o prefixo __Secure em vez de __Host e especifique Domain.

A receita

Set-Cookie:
__Secure-cookie-name=cookie-value;
Secure;
Domain=news.site;
Path=/;
HttpOnly;
Max-Age=7776000;
SameSite=Lax;
Detalhes

Secure é um prefixo opcional que declara menos requisitos do que Host: ele exige apenas que o cookie seja definido com o atributo Secure.

Embora os cookies SameSite=Lax não sejam enviados em subsolicitações entre sites (por exemplo, ao carregar imagens incorporadas ou iframes em um site de terceiros), eles são enviados quando um usuário está navegando para o site de origem (por exemplo, ao seguir um link de um site diferente).

É possível restringir ainda mais o acesso a cookies e não permitir o envio deles junto com solicitações iniciadas em sites de terceiros com SameSite=Strict. Isso é útil quando você tem cookies relacionados a funcionalidades que sempre estarão por trás de uma navegação inicial, como a alteração de uma senha ou a realização de uma compra.

A receita

Set-Cookie:
__Host-cookie-name=cookie-value;
Secure;
Path=/;
HttpOnly;
Max-Age=7776000;
SameSite=Strict;