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.
Mudanças no comportamento padrão sem SameSite
Compatibilidade com navegadores
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 comoSameSite=Lax
. - Os cookies com
SameSite=None
também precisam especificarSecure
, 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.
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 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