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 contam como solicitações entre sites. Faça upgrade para HTTPS por padrão para evitar problemas sempre que possível ou leia mais detalhes sobre quais valores de atributo SameSite são necessários.

Steven Bingler

Rowan Merewood

Esquema Mesmo site modifica a definição de um (web) site apenas do domínio registrável para o e domínio registrável. Você pode encontrar mais detalhes e exemplos em Noções básicas sobre "mesmo site" e "same-origin".

A boa notícia é que, se o seu site já estiver totalmente atualizado para HTTPS, você 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 de HTTP para HTTPS, alguns desses cenários comuns e o cookie SameSite associado são descritos abaixo.

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

• No Chrome 86, ative a about://flags/#schemeful-same-site. Acompanhar o progresso na página Status do Chrome .
• No Firefox 79, defina network.cookie.sameSite.schemeful como true via about:config Acompanhe seu progresso pelo Bugzilla problema.

Um dos principais motivos para mudar o padrão para SameSite=Lax os cookies era 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 representa uma oportunidade para os invasores adulterar cookies que serão usados na versão segura HTTPS do site. Criar esse limite adicional entre sites entre esquemas oferece mais defesa contra esses ataques.

Cenários comuns de vários esquemas

Navegação

Navegar entre versões de um site em diferentes esquemas (por exemplo, vincular de http://site.example para https://site.example) permitiria anteriormente SameSite=Strict cookies a serem enviados. Agora, isso é tratado como uma migração o que significa que os cookies do SameSite=Strict serão bloqueados.

Carregando sub-recursos

Qualquer alteração feita aqui deve ser considerada apenas uma correção temporária enquanto você para realizar o upgrade para HTTPS completo.

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

Carregar um sub-recurso entre esquemas em uma página anteriormente permitiria Cookies SameSite=Strict ou SameSite=Lax a serem enviados ou definidos. Agora isso é tratados da mesma maneira que qualquer outro sub-recurso de terceiros ou entre sites, significa que todos os cookies SameSite=Strict ou SameSite=Lax serão bloqueados.

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

Como fazer POST de um formulário

Antes, a postagem entre versões de um site em vários esquemas permitia cookies definidos com SameSite=Lax ou SameSite=Strict para envio. Agora isso é tratado como um POST entre sites: apenas 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 atualizar os usuários para a versão segura após o envio do formulário de login ou formulário de finalização de compra.

Assim como nos sub-recursos, se a solicitação vier de um ambiente seguro, por exemplo, HTTP para um não seguro, por exemplo, HTTP, o contexto, 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, a guia "Issue" (Problemas) no DevTools incluem problemas do Schemeful Same-Site. Os seguintes problemas podem aparecer destacados para seu site.

Problemas de navegação:

• "Migre inteiramente para HTTPS para continuar a receber cookies no mesmo site". solicitações": um aviso de que o cookie será bloqueado em uma versão futura do Chrome.
• "Migrar inteiramente para HTTPS para que os cookies sejam enviados nas solicitações do mesmo site" - A informando que o cookie foi bloqueado.

Problemas de carregamento de recursos secundários:

• "Migre totalmente para HTTPS para continuar enviando cookies para o mesmo site" sub-recursos" ou "Migrar totalmente para HTTPS para continuar permitindo que cookies ser definido por sub-recursos do mesmo site": avisos de que o cookie será bloqueada em uma versão futura do Chrome.
• "Migre inteiramente para HTTPS para que os cookies sejam enviados aos sub-recursos do mesmo site" ou "Migrar totalmente para HTTPS para permitir que os cookies sejam definidos pelo mesmo site sub-recursos: avisa que o cookie foi bloqueado. A última opção também pode aparecer ao fazer POST de um formulário.

Mais detalhes estão disponíveis em Dicas de teste e depuração do Schemeful mesmo site.

Do Firefox 79, com network.cookie.sameSite.schemeful definido como true via about:config o console vai mostrar uma mensagem sobre problemas do Schemeful Same-Site. Você poderá ver o seguinte no seu site:

• "O cookie cookie_name será em breve tratado como cookie entre sites contra http://site.example/ porque o esquema não corresponde."
• "O cookie cookie_name foi tratado como "entre sites" em relação 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 DevTools do meu navegador?

É possível que alguns dos seus links e sub-recursos ainda apontem para conteúdo URLs.

Uma forma de corrigir esse problema é usar HTTP Segurança de transporte estrita (HSTS) e a diretiva includeSubDomain. Com HSTS + includeSubDomain se uma de suas páginas incluir um link não seguro acidentalmente, o navegador automaticamente a versão segura.

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

Embora seja altamente recomendado que você atualize seu site inteiramente para HTTPS, proteja os seus usuários. Se não puder fazer isso por conta própria, sugerimos que fale com seu provedor de hospedagem para saber se eles oferecem essa opção. Se você é auto-hospedado, o Let's Encrypt fornece várias ferramentas para para instalar e configurar um certificado. Você também pode investigar como mover 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 em cookies afetados.

• Nos casos em que apenas cookies SameSite=Strict estiverem sendo bloqueados, você poderá reduzir a proteção para Lax.
• Nos casos em que os cookies Strict e Lax forem bloqueados e sua os cookies estão sendo enviados para (ou definidos a partir de) um URL seguro que você pode diminuir a para None.
  • Essa solução alternativa falhará se o URL para o qual você está enviando cookies definir o escopo) não é segura. Isso ocorre porque o SameSite=None requer Secure nos cookies, o que significa que esses cookies não podem ser enviados ou por uma conexão sem segurança. 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, pois com o tempo os cookies de terceiros serão foi totalmente descontinuada.

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

Os cookies sem um atributo SameSite são tratados como se tivessem sido especificados SameSite=Lax e o mesmo comportamento em esquemas cruzados se aplica a esses cookies como muito bem. Observe que a exceção temporária a métodos não seguros ainda se aplica. Consulte a mitigação Lax + POST no Chromium SameSite Perguntas frequentes (em inglês) para mais informações.

Como os WebSockets são afetados?

As conexões WebSocket ainda serão consideradas do mesmo site se forem iguais a 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://

Foto de Julissa Capdevilla ativado Abrir a página