Schemeful Same-Site

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

Steven Bingler

Rowan Merewood

O Schemeful Same-Site modifica a definição de um site (da Web) de apenas o domínio registrável para o esquema + domínio registrável. Confira mais detalhes e exemplos em Noções básicas sobre "mesmo site" e "mesma origem".

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

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

Você pode ativar essas mudanças para testes no Chrome e no Firefox.

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

Um dos principais motivos da mudança para SameSite=Lax como padrão para cookies foi a proteção contra falsificação de solicitações entre sites (CSRF). No entanto, o tráfego HTTP não seguro ainda oferece uma oportunidade para que invasores de rede adulterem cookies que serão usados na versão HTTPS segura do site. A criação dessa fronteira adicional entre esquemas oferece mais defesa contra esses ataques.

Cenários comuns entre esquemas

Navegação

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

Carregamento de sub-recursos

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

Exemplos de sub-recursos incluem imagens, iframes e solicitações de rede feitas com XHR ou busca.

O carregamento de um sub-recurso entre esquemas em uma página permitia que cookies SameSite=Strict ou SameSite=Lax fossem enviados ou definidos. Agora, isso é tratado da mesma forma que qualquer outro sub-recurso 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.

Postagem de um formulário

A postagem entre versões de esquema cruzado de um site permitia que cookies definidos com SameSite=Lax ou SameSite=Strict fossem enviados. Agora, isso é tratado como uma postagem entre sites. Somente cookies SameSite=None podem ser enviados. Esse cenário pode ocorrer 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 login ou check-out.

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

Como posso testar meu site?

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

No Chrome 86 e versões mais recentes, a guia "Problema" nas Ferramentas para desenvolvedores inclui problemas do Schemeful Same-Site. Você pode ver 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 sub-recursos:

• "Migrar totalmente para HTTPS para continuar recebendo cookies para sub-recursos do mesmo site" ou "Migrar totalmente para HTTPS para continuar permitindo que cookies sejam definidos por sub-recursos 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 sub-recursos do mesmo site" ou "Migrar totalmente para HTTPS para permitir que os cookies sejam definidos por sub-recursos do mesmo site": avisos de que o cookie foi bloqueado. O último aviso também pode aparecer ao postar um formulário.

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

No Firefox 79 e versões mais recentes, com network.cookie.sameSite.schemeful definido como true usando about:config, o console vai mostrar uma mensagem para problemas do Schemeful Same-Site. Você pode ver o seguinte no seu site:

• "O cookie cookie_name será tratado em breve como um cookie entre sites em relação a http://site.example/, porque o esquema não corresponde."
• "O cookie cookie_name foi tratado como entre sites 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 vendo problemas nas Ferramentas para desenvolvedores do navegador?

É possível que alguns dos seus links e sub-recursos 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 o HSTS + includeSubDomain, mesmo que uma das suas páginas inclua 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?

Embora recomendemos que você faça upgrade do seu site para HTTPS para proteger seus usuários, se não for possível fazer isso sozinho, sugerimos que você fale com seu provedor de hospedagem para saber se ele pode oferecer essa opção. Se você tiver auto-hospedagem, então Let's Encrypt vai fornecer várias ferramentas para instalar e configurar um certificado. Você também pode investigar a movimentação do seu site por trás de uma 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 cookies SameSite=Strict estão sendo bloqueados, você pode diminuir 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 em) um URL seguro, você pode diminuir as proteções para None.
  • Essa solução alternativa falhará se o URL para o qual você está enviando cookies (ou definindo-os) 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, você não poderá acessar esse cookie até que seu site seja atualizado para HTTPS.
  • Lembre-se de que isso é apenas temporário, já que os cookies de terceiros serão eliminados completamente.

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

Os 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 como bem. A exceção temporária aos métodos não seguros ainda se aplica. Consulte a mitigação de Lax + POST nas Perguntas frequentes sobre SameSiteChromium para mais informações.

Como os WebSockets são afetados?

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

Mesmo site:

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

Entre sites:

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