Explicação sobre cookies SameSite

Compatibilidade com navegadores

  • Chrome: 51.
  • Borda: 16.
  • Firefox: 60.
  • Safari: 13

Origem

Cada cookie contém um par de chave-valor junto com alguns atributos que controlar quando e onde esse cookie é usado.

A introdução do atributo SameSite (definido em RFC6265bis). você pode declarar se o cookie está restrito a um contexto do mesmo site. É útil entender exatamente qual "site" significa. O site é a combinação do sufixo do domínio e da parte do domínio apenas antes dele. Por exemplo, o domínio www.web.dev faz parte do site web.dev.

Termo-chave: se o usuário estiver no www.web.dev e solicitar uma imagem do static.web.dev, é uma solicitação de mesmo site.

A lista de sufixos públicos define quais páginas contam como no mesmo site. Não depende apenas de domínios de nível superior, como .com, mas também pode incluir serviços como github.io. Isso permite your-project.github.io e my-project.github.io para serem considerados sites diferentes.

Termo-chave: se o usuário estiver no your-project.github.io e solicitar uma imagem do my-project.github.io que é uma solicitação entre sites.

Use o atributo SameSite para declarar o uso de cookies

O atributo SameSite em um cookie oferece três maneiras diferentes de controlar esse comportamento. Você pode optar por não especificar o atributo ou pode usar Strict ou Lax para limitar o cookie às solicitações do mesmo site.

Se você definir SameSite como Strict, o cookie só poderá ser enviado em uma contexto próprio ou seja, se o site do cookie corresponder ao site exibido na barra de endereço do navegador. Portanto, se o cookie promo_shown estiver definido da seguinte maneira:

Set-Cookie: promo_shown=1; SameSite=Strict

Quando o usuário está no seu site, o cookie é enviado com a solicitação conforme esperado. No entanto, se o usuário seguir um link para seu site a partir de outro, o cookie não é enviada na solicitação inicial. Isso é bom para cookies relacionados a recursos que estão sempre atrás de um de navegação, como alterar uma senha ou fazer uma compra, mas é muito restritiva para um cookie como promo_shown. Se o leitor seguir o link para o site, ela quer que o cookie seja enviado para que a preferência seja aplicada.

SameSite=Lax permite que o navegador envie o cookie com essas tags navegações. Por exemplo, se outro site fizer referência ao conteúdo do seu, na neste caso, usando a foto do seu gato e fornecendo um link para sua matéria, da seguinte forma:

<p>Look at this amazing cat!</p>
<img src="https://blog.example/blog/img/amazing-cat.png" />
<p>Read the <a href="https://blog.example/blog/cat.html">article</a>.</p>

Com um cookie definido como Lax da seguinte maneira:

Set-Cookie: promo_shown=1; SameSite=Lax

Quando o navegador solicita amazing-cat.png para o blog da outra pessoa, seu site não envia o cookie. No entanto, quando o leitor segue link para cat.html no seu site, essa solicitação incluirá o cookie.

Recomendamos usar o SameSite dessa forma, definindo cookies que afetam o site serão mostrados em Lax e os cookies relacionados às ações do usuário para Strict.

Também é possível definir SameSite como None para indicar que você quer que o cookie seja enviados em todos os contextos. Se você fornece um serviço que outros sites consomem, como widgets, conteúdo incorporado, programas de afiliados, publicidade ou login vários sites, use None para garantir que sua intenção seja clara.

Três cookies rotulados como &quot;Nenhum&quot;, &quot;Lax&quot; ou &quot;Restrito&quot; dependendo do contexto
Marque explicitamente o contexto de um cookie como None, Lax ou Strict.

Mudanças no comportamento padrão sem SameSite

Compatibilidade com navegadores

  • Chrome: 80.
  • Borda: 86.
  • Firefox: atrás de uma sinalização.
  • Safari: incompatível.

O atributo SameSite é amplamente aceito, mas não foi amplamente adotado. Antes, definir cookies sem SameSite era o envio por padrão em todos os contextos, o que deixa os usuários vulneráveis ao CSRF e à vazamento de informações. Incentivar os desenvolvedores a declarar a intenção e fornecer aos usuários uma experiência mais segura, a proposta IETF, Cookies cada vez melhores apresenta duas mudanças principais:

  • Cookies sem um atributo SameSite são tratados como SameSite=Lax.
  • Os cookies com SameSite=None também precisam especificar Secure, o que significa que eles exigem em um contexto seguro.

Essas duas alterações são compatíveis com versões anteriores de navegadores que foram implementaram a versão anterior do atributo SameSite, assim como navegadores que não são compatíveis com versões anteriores do SameSite. Eles têm como objetivo reduz o número de dependência de navegadores comportamento padrão, tornando o uso de cookies comportamento e uso pretendidos explícitos. Os clientes que não reconhecerem SameSite=None deve ignorá-lo.

SameSite=Lax por padrão

Se você enviar um cookie sem especificar o atributo SameSite, o navegador trata esse cookie como se estivesse definido como SameSite=Lax. Ainda recomendamos definir SameSite=Lax explicitamente para tornar a experiência do usuário mais consistente. em vários navegadores.

SameSite=None precisa ser seguro

Ao criar cookies entre sites usando SameSite=None, você também precisa defini-los para Secure para que o navegador os aceite:

Set-Cookie: widget_session=abc123; SameSite=None; Secure

É possível testar esse comportamento a partir do Chrome 76 ativando about://flags/#cookies-without-same-site-must-be-secure e do Firefox 69 definindo network.cookie.sameSite.noneRequiresSecure em about:config.

Também recomendamos atualizar os cookies existentes para Secure assim que possível. Se você depende de serviços que fornecem conteúdo de terceiros no seu site, verifique se seu provedor de serviços atualiza seus cookies e quaisquer snippets ou dependências em seu site para garantir que ele use o novo comportamento.

Para mais detalhes sobre como atualizar seus cookies para lidar com essas mudanças no SameSite=None e as diferenças no comportamento do navegador, consulte as artigo de acompanhamento, receitas de cookies SameSite.

Agradecemos as contribuições e o feedback de Lily Chen, Malte Ubl e Mike West, Rob Dodson, Tom Steiner e Vivek Sekhar.

Imagem principal do cookie por Pille-Riin Priske ativado Exibir