Cada cookie contém um par de chave-valor e vários atributos que controlam quando e onde ele é usado.
A introdução do atributo SameSite
(definido na
RFC6265bis)
permite declarar se o cookie é restrito a um contexto primário ou
do mesmo site. É útil entender exatamente o que "site" significa aqui.
O site é a combinação do sufixo do domínio e da parte do domínio logo
antes dele. Por exemplo, o domínio www.web.dev
faz parte do site web.dev
.
Termo-chave: se o usuário estiver em www.web.dev
e solicitar uma imagem de
static.web.dev
, essa será uma solicitação do mesmo site.
A lista de sufixos públicos define quais páginas são consideradas
como estando no mesmo site. Ele 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 que
your-project.github.io
e my-project.github.io
sejam contabilizados como sites separados.
Termo-chave: se o usuário estiver em your-project.github.io
e solicitar uma imagem de
my-project.github.io
, essa será 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 usar
Strict
ou Lax
para limitar o cookie a solicitações do mesmo site.
Se você definir SameSite
como Strict
, o cookie só poderá ser enviado em um
contexto próprio, ou seja, se o site do cookie corresponder ao site mostrado
na barra de endereço do navegador. Portanto, se o cookie promo_shown
for 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, como esperado.
No entanto, se o usuário clicar em um link para acessar seu site, o cookie
não será enviado nessa solicitação inicial.
Isso é bom para cookies relacionados a recursos que estão sempre por trás de uma navegação
inicial, como alterar uma senha ou fazer uma compra, mas é muito
restritivo para um cookie como promo_shown
. Se o leitor clicar no link
para o site, ele vai querer que o cookie seja enviado para que a preferência seja aplicada.
O SameSite=Lax
permite que o navegador envie o cookie com essas navegações
de nível superior. Por exemplo, se outro site referenciar o conteúdo do seu site, nesse
caso, usando a foto do seu gato e fornecendo um link para o artigo,
como este:
<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 o
link para cat.html
no seu site, essa solicitação inclui o cookie.
Recomendamos o uso de SameSite
dessa forma, definindo cookies que afetam a
exibição do site como Lax
e cookies relacionados às ações do usuário como Strict
.
Também é possível definir SameSite
como None
para indicar que você quer que o cookie seja
enviado em todos os contextos. Se você oferece um serviço que outros sites consomem, como
widgets, conteúdo incorporado, programas de afiliados, publicidade ou login em
vários sites, use None
para garantir que sua intent esteja clara.
Mudanças no comportamento padrão sem SameSite
Compatibilidade com navegadores
O atributo SameSite
tem suporte amplo, mas não foi amplamente adotado.
No passado, a configuração de cookies sem SameSite
definia o envio deles em
todos os contextos, o que deixa os usuários vulneráveis a CSRF e vazamento
não intencional de informações. Para incentivar os desenvolvedores a declarar a intenção
e oferecer aos usuários uma experiência mais segura, a proposta do IETF,
Incrementally Better Cookies
apresenta duas mudanças importantes:
- Cookies sem um atributo
SameSite
são tratados comoSameSite=Lax
. - Os cookies com
SameSite=None
também precisam especificarSecure
, o que significa que eles exigem um contexto seguro.
Essas duas mudanças são compatíveis com versões anteriores de navegadores que implementaram corretamente
a versão anterior do atributo SameSite
, bem como
com navegadores que não oferecem suporte a versões anteriores de SameSite
. O objetivo é
reduzir a dependência dos desenvolvedores do comportamento padrão dos navegadores, tornando o comportamento
e o uso pretendido do cookie explícitos. Todos os clientes que não reconhecerem
SameSite=None
precisam ignorá-lo.
SameSite=Lax
por padrão
Se você enviar um cookie sem especificar o atributo SameSite
, o navegador
vai tratar esse cookie como se ele estivesse definido como SameSite=Lax
. Ainda recomendamos
definir SameSite=Lax
explicitamente para tornar a experiência do usuário mais consistente
em todos os navegadores.
SameSite=None
precisa ser seguro
Ao criar cookies entre sites usando SameSite=None
, você também precisa defini-los
como 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, no Firefox 69,
definindo network.cookie.sameSite.noneRequiresSecure
em
about:config
.
Também recomendamos atualizar os cookies atuais para Secure
assim que possível.
Se você usa serviços que fornecem conteúdo de terceiros no seu site, verifique se
o provedor de serviços atualiza os cookies e atualize todos os snippets ou
dependências no seu site para garantir que ele use o novo comportamento.
SameSite
receitas de biscoitos
Para mais detalhes sobre como atualizar os cookies para processar essas
mudanças em SameSite=None
e as diferenças no comportamento do navegador, consulte o
artigo de acompanhamento Receitas de cookies SameSite.
Agradecemos as contribuições e o feedback de Lily Chen, Malte Ubl, Mike West, Rob Dodson, Tom Steiner e Vivek Sekhar.
Imagem principal do cookie de Pille-Riin Priske no Unsplash