O Chrome, Firefox, Edge e outros estão mudando o comportamento padrão de acordo com a proposta do IETF, Cookies incrementalmente melhores para que:
- Cookies sem um atributo
SameSite
são tratados comoSameSite=Lax
, o que significa que o comportamento padrão é restringir cookies apenas a contextos primários. - Os cookies para uso entre sites precisam especificar
SameSite=None; Secure
para permitir a inclusão no contexto de terceiros.
Atualize os atributos dos cookies de terceiros para que não sejam bloqueados no futuro, caso ainda não tenha feito isso.
Casos de uso de cookies entre sites ou de terceiros
Há vários casos de uso e padrões comuns em que os cookies precisam ser enviados em um contexto de terceiros. Se você fornecer ou depender de um desses casos de uso, verifique se você ou o provedor estão atualizando os cookies para manter o funcionamento correto do serviço.
Conteúdo em uma <iframe>
O conteúdo de um site diferente exibido em um <iframe>
está em um contexto
de terceiros. Os casos de uso padrão incluem:
- Conteúdo incorporado de outros sites, como vídeos, mapas, exemplos de código e postagens em redes sociais.
- Widgets de serviços externos, como pagamentos, agendas, agendamentos e recursos de reserva
- Widgets, como botões de redes sociais ou serviços antifraude, que criam uma
<iframes>
menos óbvia.
Os cookies podem ser usados aqui para, entre outras coisas, manter o estado da sessão, armazenar preferências gerais, ativar estatísticas ou personalizar conteúdo para usuários com contas existentes.
![Diagrama de uma janela do navegador em que o URL do conteúdo incorporado não corresponde ao URL da página.](https://web.dev/static/articles/samesite-cookie-recipes/image/diagram-a-browser-window-809ed902fbce7.png?authuser=6&hl=pt)
Como a Web é inerentemente combinável, as <iframes>
também são usadas para incorporar
o conteúdo visualizado em um contexto próprio ou de nível superior. Todos os cookies exibidos no iframe são considerados cookies de terceiros. Se estiver criando sites que serão incorporados por outros e precisar de cookies para que eles funcionem, também será necessário garantir que eles sejam marcados para uso entre sites ou que você possa voltar sem problemas.
Solicitações "não seguras" entre sites
"Não seguro" pode parecer preocupante, mas se refere a qualquer solicitação que possa
mudar de estado. Na Web, trata-se principalmente de solicitações POST. Os cookies
marcados como SameSite=Lax
são enviados em navegações seguras de nível superior, como clicar em um
link para acessar outro site. No entanto, algo como o envio de <form>
para
um site diferente usando POST não inclui cookies.
![Diagrama de uma solicitação passando de uma página para outra.](https://web.dev/static/articles/samesite-cookie-recipes/image/diagram-a-request-moving-46b47373768e3.png?authuser=6&hl=pt)
Esse padrão é usado em sites que podem redirecionar o usuário a um serviço
remoto para executar alguma operação antes de retornar, por exemplo, redirecionar para
um provedor de identidade de terceiros. Antes de o usuário sair do site, um cookie é definido contendo um token de uso único com a expectativa de que esse token possa ser verificado na solicitação de retorno para reduzir ataques de falsificação de solicitações entre sites (CSRF, na sigla em inglês). Se essa solicitação de retorno vier por POST, marque os cookies como SameSite=None; Secure
.
Recursos remotos
Qualquer recurso remoto em uma página, como de tags <img>
ou <script>
, pode depender do envio de cookies com uma solicitação. Casos de uso comuns incluem
pixels de rastreamento e personalização de conteúdo.
Isso também se aplica às solicitações enviadas do seu JavaScript usando fetch
ou XMLHttpRequest
. Se fetch()
for chamado com a
opção credentials: 'include'
,
essas solicitações provavelmente incluirão cookies.
Para XMLHttpRequest
, os cookies esperados geralmente são indicados por um valor withCredentials
para true
. Esses cookies precisam ser marcados corretamente para serem incluídos em solicitações entre sites.
Conteúdo em uma WebView
Um WebView em um app específico da plataforma é alimentado por um navegador. Os desenvolvedores precisam testar se as restrições ou os problemas que afetam os apps também se aplicam às WebViews deles.
O Android também permite que apps específicos da plataforma definam cookies diretamente usando a
API CookieManager.
Assim como os cookies definidos usando cabeçalhos ou JavaScript, considere incluir
SameSite=None; Secure
se eles forem destinados ao uso entre sites.
Como implementar o SameSite
hoje mesmo
Marque os cookies que são necessários apenas em um contexto próprio como SameSite=Lax
ou SameSite=Strict
, dependendo das suas necessidades. Se você não marcar esses cookies e, em vez disso, confiar no comportamento padrão do navegador para processá-los, eles poderão se comportar de maneira inconsistente em todos os navegadores e acionar avisos no console para cada cookie.
Set-Cookie: first_party_var=value; SameSite=Lax
Marque todos os cookies necessários em um contexto de terceiros como
SameSite=None; Secure
. Ambos os atributos são obrigatórios. Se você apenas especificar None
sem Secure
, o cookie será rejeitado. Para considerar as diferenças
nas implementações do navegador, talvez seja necessário usar algumas das estratégias
de mitigação descritas em Gerenciar clientes incompatíveis.
Set-Cookie: third_party_var=value; SameSite=None; Secure
Processar clientes incompatíveis
Como essas mudanças para incluir None
e atualizar o comportamento padrão ainda são
relativamente novas, diferentes navegadores as processam de maneiras diferentes. Consulte a página de atualizações em chromium.org para consultar uma lista de problemas conhecidos, mas essa lista pode não estar completa.
Uma solução possível é definir cada cookie no estilo novo e no antigo:
Set-cookie: 3pcookie=value; SameSite=None; Secure
Set-cookie: 3pcookie-legacy=value; Secure
Os navegadores que implementam o comportamento mais recente definem o cookie com o valor SameSite
. Os navegadores que não implementam o novo comportamento ignoram esse valor e definem o cookie 3pcookie-legacy
. Ao processar os cookies incluídos, o site precisa verificar primeiro a presença do novo estilo de cookie e, em seguida, usar o cookie legado se não encontrar um novo.
O exemplo a seguir mostra como fazer isso no Node.js usando o framework Express e o middleware cookie-parser:
const express = require('express');
const cp = require('cookie-parser');
const app = express();
app.use(cp());
app.get('/set', (req, res) => {
// Set the new style cookie
res.cookie('3pcookie', 'value', { sameSite: 'none', secure: true });
// And set the same value in the legacy cookie
res.cookie('3pcookie-legacy', 'value', { secure: true });
res.end();
});
app.get('/', (req, res) => {
let cookieVal = null;
if (req.cookies['3pcookie']) {
// check the new style cookie first
cookieVal = req.cookies['3pcookie'];
} else if (req.cookies['3pcookie-legacy']) {
// otherwise fall back to the legacy cookie
cookieVal = req.cookies['3pcookie-legacy'];
}
res.end();
});
app.listen(process.env.PORT);
Essa abordagem exige que você faça um trabalho extra para definir cookies redundantes e fazer mudanças na configuração e na leitura do cookie. No entanto, ele precisa abranger todos os navegadores, independentemente do comportamento deles, e manter os cookies de terceiros funcionando.
Como alternativa, é possível detectar o cliente usando a string do user agent quando um
cabeçalho Set-Cookie
for enviado. Consulte a
lista de clientes incompatíveis
e use uma biblioteca de detecção de user agent apropriada para sua plataforma, por
exemplo, a biblioteca ua-parser-js
no Node.js. Essa abordagem requer apenas uma mudança, mas a detecção do user agent pode não capturar todos os usuários afetados.
Suporte para SameSite=None
em linguagens, bibliotecas e frameworks
A maioria das linguagens e bibliotecas é compatível com o atributo SameSite
para cookies. No entanto, como a adição de SameSite=None
ainda é relativamente
recente, talvez seja necessário solucionar algum comportamento padrão por enquanto.
Esses comportamentos estão documentados no
repositório de exemplos do SameSite
no GitHub.
Receber ajuda
Os cookies são usados em todos os lugares na Web, e é raro que uma equipe de desenvolvimento tenha conhecimento completo de onde os sites definem e usam esses cookies, especialmente em casos de uso entre sites. Quando você encontra um problema, pode ser a primeira vez que alguém o encontra, então não hesite em entrar em contato:
- Informe um problema no
repositório de exemplos do
SameSite
no GitHub (em inglês). - Faça uma pergunta na tag"samesite" no StackOverflow.
- Para problemas com o comportamento do Chromium, informe um bug no Issue Tracker do Chromium.
- Acompanhe o progresso do Chrome na
página de atualizações do
SameSite
.