Schemeful Same-Site

A definição de "mesmo site" está evoluindo para incluir o esquema de URL. Portanto, os links entre as versões HTTP e HTTPS de um site agora são considerados solicitações entre diferentes sites. Faça upgrade para HTTPS por padrão para evitar problemas sempre que possível ou continue lendo para saber quais valores do atributo SameSite são necessários.

Schemeful Same-Site modifica a definição de um site (da Web) do domínio registrável para o esquema + domínio registrável. Confira mais detalhes e exemplos em Entenda o que é "mesmo site" e "mesma origem".

A boa notícia é que, se o site já estiver totalmente atualizado para HTTPS, você não precisará se preocupar com nada. Nada vai mudar para você.

Se você ainda não fez upgrade total do seu site, essa deve ser a prioridade. No entanto, se houver casos em que os visitantes do seu site alternarem entre HTTP e HTTPS, alguns desses cenários comuns e o comportamento associado do cookie SameSite serão descritos mais adiante neste artigo.

É possível ativar essas mudanças para testes no Chrome e no Firefox.

  • No Chrome 86, ative about://flags/#schemeful-same-site. Acompanhe o progresso na página de status do Chrome.
  • No Firefox 79, defina network.cookie.sameSite.schemeful como true usando about:config. Acompanhe o progresso usando o problema do Bugzilla.

Uma das principais razões para a mudança para SameSite=Lax como padrão para cookies foi proteger contra falsificação de solicitações entre sites (CSRF, na sigla em inglês). No entanto, o tráfego HTTP não seguro ainda oferece uma oportunidade para que invasores de rede adultem cookies que serão usados na versão HTTPS segura do site. A criação desse limite adicional entre sites entre esquemas oferece mais defesa contra esses ataques.

Cenários comuns entre esquemas

Antes, a navegação entre versões de esquema cruzado de um site (por exemplo, vinculação de http://site.example para https://site.example) permitia o envio de cookies SameSite=Strict. Isso agora é tratado como uma navegação entre sites, o que significa que os cookies SameSite=Strict serão bloqueados.

Uma navegação entre esquemas acionada ao seguir um link na versão HTTP não segura de um site para a versão HTTPS segura. Cookies SameSite=Strict bloqueados, SameSite=Lax e SameSite=None; cookies Secure permitidos.
Navegação entre esquemas de HTTP para HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bloqueado ⛔ Bloqueado
SameSite=Lax ✓ Permitido ✓ Permitido
SameSite=None;Secure ✓ Permitido ⛔ Bloqueado

Carregando subrecursos

Todas as mudanças feitas aqui devem ser consideradas uma correção temporária enquanto você trabalha para fazer upgrade para o HTTPS completo.

Exemplos de subrecursos incluem imagens, iframes e solicitações de rede feitas com XHR ou Fetch.

Anteriormente, o carregamento de um subrecurso de esquema cruzado em uma página permitia que os cookies SameSite=Strict ou SameSite=Lax fossem enviados ou definidos. Agora, isso é tratado da mesma forma que qualquer outro subrecurso de terceiros ou entre sites, o que significa que todos os cookies SameSite=Strict ou SameSite=Lax serão bloqueados.

Além disso, mesmo que o navegador permita que recursos de esquemas não seguros sejam carregados em uma página segura, todos os cookies serão bloqueados nessas solicitações, já que os cookies de terceiros ou entre sites exigem Secure.

Um subrecurso de esquema cruzado resultante de um recurso da versão HTTPS segura do site que está sendo incluído na versão HTTP não segura. Cookies SameSite=Strict e SameSite=Lax bloqueados, e cookies SameSite=None; Secure permitidos.
Uma página HTTP que inclui um subrecurso de esquema cruzado via HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bloqueado ⛔ Bloqueado
SameSite=Lax ⛔ Bloqueado ⛔ Bloqueado
SameSite=None;Secure ✓ Permitido ⛔ Bloqueado

POSTar um formulário

Antes, a postagem entre versões de esquema cruzado de um site permitia que os cookies definidos com SameSite=Lax ou SameSite=Strict fossem enviados. Agora isso é tratado como um POST entre sites. Somente cookies SameSite=None podem ser enviados. Você pode encontrar esse cenário em sites que apresentam a versão não segura por padrão, mas fazem upgrade dos usuários para a versão segura no envio do formulário de fechamento de sessão ou de finalização de compra.

Assim como nos subrecursos, se a solicitação for de um contexto seguro (por exemplo, HTTPS) para um inseguro (por exemplo, HTTP), todos os cookies serão bloqueados nessas solicitações, já que os cookies de terceiros ou entre sites exigem Secure.

Um envio de formulário cross-scheme resultante de um formulário na versão HTTP não segura do site sendo enviado para a versão HTTPS segura. Cookies SameSite=Strict e SameSite=Lax bloqueados, e cookies SameSite=None; Secure permitidos.
O envio de formulários entre esquemas de HTTP para HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bloqueado ⛔ Bloqueado
SameSite=Lax ⛔ Bloqueado ⛔ Bloqueado
SameSite=None;Secure ✓ Permitido ⛔ Bloqueado

Como posso testar meu site?

As ferramentas e mensagens para desenvolvedores estão disponíveis no Chrome e no Firefox.

No Chrome 86, a guia Issue no DevTools vai incluir problemas Schemeful Same-Site. Talvez você encontre os seguintes problemas destacados no seu site.

Problemas de navegação:

  • "Migrar totalmente para HTTPS para continuar recebendo cookies em solicitações do mesmo site": um aviso de que o cookie será bloqueado em uma versão futura do Chrome.
  • "Migrar totalmente para HTTPS para que os cookies sejam enviados em solicitações do mesmo site": um aviso de que o cookie foi bloqueado.

Problemas de carregamento de subrecursos:

  • "Migrar totalmente para HTTPS para continuar recebendo cookies para recursos secundários do mesmo site" ou "Migrar totalmente para HTTPS para continuar permitindo que cookies sejam definidos por recursos secundários do mesmo site": avisos de que o cookie será bloqueado em uma versão futura do Chrome.
  • "Migrar totalmente para HTTPS para que os cookies sejam enviados para recursos secundários do mesmo site" ou "Migrar totalmente para HTTPS para permitir que os cookies sejam definidos por recursos secundários do mesmo site": avisos de que o cookie foi bloqueado. O último aviso também pode aparecer ao enviar um formulário.

Mais detalhes estão disponíveis em Dicas de teste e depuração para Schemeful Same-Site.

No Firefox 79, com network.cookie.sameSite.schemeful definido como true por meio de about:config, o console vai mostrar uma mensagem para problemas de Schemeful Same-Site. Você pode encontrar o seguinte no seu site:

  • "O cookie cookie_name em breve será tratado como cookie entre sites contra http://site.example/ porque o esquema não corresponde."
  • "O cookie cookie_name foi tratado como cross-site em relação a http://site.example/ porque o esquema não corresponde."

Perguntas frequentes

Meu site já está totalmente disponível em HTTPS. Por que estou tendo problemas nas Ferramentas do desenvolvedor do meu navegador?

É possível que alguns dos seus links e subrecursos ainda apontem para URLs não seguros.

Uma maneira de corrigir esse problema é usar o HTTP Strict-Transport-Security (HSTS) e a diretiva includeSubDomain. Com a HSTS + includeSubDomain, mesmo se uma das suas páginas incluir acidentalmente um link não seguro, o navegador vai usar automaticamente a versão segura.

E se eu não puder fazer upgrade para HTTPS?

Recomendamos que você faça upgrade do seu site para HTTPS para proteger seus usuários. Se não for possível, sugerimos conversar com seu provedor de hospedagem para saber se ele pode oferecer essa opção. Se você hospedar por conta própria, a Let's Encrypt (link em inglês) vai fornecer várias ferramentas para instalar e configurar um certificado. Você também pode investigar a migração do seu site para um CDN ou outro proxy que possa fornecer a conexão HTTPS.

Se isso ainda não for possível, tente relaxar a proteção SameSite nos cookies afetados.

  • Nos casos em que apenas os cookies SameSite=Strict estão sendo bloqueados, é possível reduzir a proteção para Lax.
  • Nos casos em que os cookies Strict e Lax estão sendo bloqueados e seus cookies estão sendo enviados para (ou definidos a partir de) um URL seguro, é possível reduzir as proteções para None.
    • Essa solução alternativa não vai funcionar se o URL para o qual você está enviando cookies (ou em que os está definindo) não for seguro. Isso ocorre porque SameSite=None exige o atributo Secure em cookies, o que significa que esses cookies não podem ser enviados ou definidos em uma conexão não segura. Nesse caso, não será possível acessar esse cookie até que o site seja atualizado para HTTPS.
    • Isso é apenas temporário, já que os cookies de terceiros serão desativados por completo.

Como isso afeta meus cookies se eu não especificar um atributo SameSite?

Cookies sem um atributo SameSite são tratados como se tivessem especificado SameSite=Lax, e o mesmo comportamento entre esquemas também se aplica a esses cookies. A exceção temporária para métodos não seguros ainda se aplica. Consulte a mitigação Lax + POST nas perguntas frequentes do Chromium SameSite para mais informações.

Como os WebSockets são afetados?

As conexões WebSocket ainda serão consideradas do mesmo site se tiverem o mesmo nível de segurança da página.

No mesmo site:

  • Conexão wss:// de https://
  • Conexão ws:// de http://

Entre sites:

  • Conexão wss:// de http://
  • Conexão ws:// de https://

Foto de Julissa Capdevilla no Unsplash