Cada cookie contém um par de chave-valor com diversos atributos que controlam quando e onde esse cookie é usado.
A introdução do atributo SameSite
(definido em
RFC6265bis)
permite declarar se o cookie está restrito a um contexto primário ou
do mesmo site. Aqui é útil entender exatamente o que significa "site".
O site é a combinação do sufixo de domínio com a 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 está no www.web.dev
e solicita uma imagem do
static.web.dev
, essa é uma solicitação do mesmo site.
A lista de sufixos públicos define quais páginas contam como
estando no mesmo site. Ela 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 contados como sites separados.
Termo-chave: se o usuário está em your-project.github.io
e solicita uma imagem de
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 usar Strict
ou Lax
para limitar o cookie a solicitações do mesmo site.
Se você definir SameSite
como Strict
, seu 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 estiver no site, o cookie será 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 será enviado nessa solicitação inicial.
Isso é bom para cookies relacionados a recursos que estão sempre atrás de uma navegação
inicial, como mudar uma senha ou fazer uma compra, mas é muito
restrito para um cookie como promo_shown
. Quando o leitor acessa o site, ele quer que o cookie seja enviado para que a preferência dele possa ser aplicada.
SameSite=Lax
permite que o navegador envie o cookie com essas navegações de nível superior. Por exemplo, se outro site fizer referência ao conteúdo do seu site,
neste caso, usando a foto do seu gato e fornecendo um link para o artigo da
seguinte maneira:
<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 site, essa solicitação inclui o cookie.
Recomendamos o uso de SameSite
dessa maneira, definindo cookies que afetam a exibição
do site como Lax
e cookies relacionados a 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ê fornece 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 seja clara.
Mudanças no comportamento padrão sem o SameSite
Compatibilidade com navegadores
- 80
- 86
- x
O atributo SameSite
é amplamente aceito, mas não foi amplamente adotado.
Antes, a definição de cookies sem SameSite
tinha como padrão o envio deles em
todos os contextos, o que deixava 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 fornecer aos usuários uma experiência mais segura, a proposta do IETF,
Cookies incrementalmente melhores (em inglês),
apresenta duas mudanças principais:
- Cookies sem um atributo
SameSite
são tratados comoSameSite=Lax
. - Cookies com
SameSite=None
também precisam especificarSecure
, o que significa que 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
, assim como
navegadores que não oferecem suporte a versões anteriores do SameSite
. O objetivo delas é reduzir a dependência dos desenvolvedores no comportamento padrão dos navegadores, tornando explícito o comportamento dos cookies e o uso pretendido. Todos os clientes que não reconhecem
SameSite=None
devem 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 explicitamente SameSite=Lax
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
Para testar esse comportamento a partir do Chrome 76, ative a
about://flags/#cookies-without-same-site-must-be-secure
. A partir do Firefox 69,
defina network.cookie.sameSite.noneRequiresSecure
em
about:config
.
Também recomendamos atualizar os cookies para Secure
assim que possível.
Se você depende de serviços que fornecem conteúdo de terceiros no seu site, confira se o provedor de serviços atualiza os cookies e os snippets ou dependências no seu site para garantir que ele use o novo comportamento.
SameSite
receitas de cookies
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 o
artigo a seguir, Receitas de cookies do SameSite.
Agradecemos as contribuições e o feedback de Lily Chen, Malte Ubl, Mike West, Rob Dodson, Tom Steiner e Vivek Sekhar.
Imagem principal de cookies por Pille-Riin Priske no Unsplash (links em inglês)