Schemeful Same-Site

A definição de "mesmo site" está evoluindo para incluir o esquema de URL, então 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 para saber quais valores de atributo do SameSite são necessários.

Steven Bingler
Steven Bingler

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

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

Se você ainda não atualizou totalmente 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 do cookie SameSite associado estã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. Acompanhe o progresso na página de Status do Chrome.
  • No Firefox 79, defina network.cookie.sameSite.schemeful como true via about:config. Monitore o progresso com o problema Bugzilla (em inglês).

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

Cenários comuns de vários esquemas

A navegação entre versões de um site com diferentes esquemas (por exemplo, a vinculação de http://site.example para https://site.example) permitiria anteriormente o envio de cookies SameSite=Strict. Essa navegação agora é tratada como uma navegação entre sites, o que significa que os cookies SameSite=Strict serão bloqueados.

Navegação de esquema cruzado acionada ao seguir um link na versão HTTP não segura de um site para a versão HTTPS segura. SameSite=Cookies estritos bloqueados, SameSite=Lax e SameSite=None; Cookies seguros são permitidos.
Navegação de esquema cruzado de HTTP para HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bloqueado ⛔ Bloqueado
SameSite=Lax ✓ Permitido ✓ Permitido
SameSite=None;Secure ✓ Permitido ⛔ Bloqueado

Carregando sub-recursos

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

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

O carregamento de um sub-recurso de esquemas cruzados em uma página permitia anteriormente o envio ou a definição de cookies SameSite=Strict ou SameSite=Lax. 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, porque cookies de terceiros ou entre sites exigem Secure.

Um sub-recurso de esquemas cruzados que resulta 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 SameSite=None; Cookies seguros são permitidos.
Uma página HTTP que inclui um sub-recurso de esquemas cruzados via HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bloqueado ⛔ Bloqueado
SameSite=Lax ⛔ Bloqueado ⛔ Bloqueado
SameSite=None;Secure ✓ Permitido ⛔ Bloqueado

Como POSTAR um formulário

A postagem entre versões de um site com esquemas cruzados permitia o envio de cookies definidos com SameSite=Lax ou SameSite=Strict. Agora isso é tratado como um POST entre sites, apenas 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 os usuários fazem upgrade para a versão segura após o envio do formulário de login ou check-out.

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

Um envio de formulário com vários esquemas que resulta 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 SameSite=None; Cookies seguros são permitidos.
Envio de formulário com esquemas cruzados 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" do DevTools vai incluir problemas do Schemeful Same-Site. Os seguintes problemas podem ser destacados no seu site.

Problemas de navegação:

  • "Migrar totalmente para HTTPS para continuar a receber cookies nas 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 cookies sejam enviados nas 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 a ter cookies enviados para sub-recursos do mesmo site" ou "Migrar totalmente para HTTPS para continuar permitindo que cookies sejam definidos por subrecursos do mesmo site": avisos de que o cookie será bloqueado em uma versão futura do Chrome.
  • "Migrar totalmente para HTTPS para que cookies sejam enviados a sub-recursos do mesmo site" ou "Migrar totalmente para HTTPS para permitir que os cookies sejam definidos por subrecursos do mesmo site": avisos de que o cookie foi bloqueado. O último aviso também pode aparecer ao fazer o POST de 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 pelo about:config, o console vai mostrar mensagens sobre problemas do Schemeful Same-Site. Você poderá encontrar 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 tendo problemas nas DevTools do meu 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 HTTP Strict-Transport-Security (HSTS) e a diretiva includeSubDomain. Com HSTS + includeSubDomain, mesmo que uma das suas páginas inclua acidentalmente um link não seguro, o navegador usará automaticamente a versão segura.

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

Recomendamos que você faça upgrade completo do seu site para HTTPS a fim de proteger os usuários. No entanto, se você não conseguir fazer isso, sugerimos que entre em contato com seu provedor de hospedagem para verificar se ele pode oferecer essa opção. Se você hospedar por conta própria, o Let's Encrypt (em inglês) fornece várias ferramentas para instalar e configurar um certificado. Você também pode investigar mover seu site para 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 reduzir a proteção para Lax.
  • Nos casos em que os cookies Strict e Lax estão sendo bloqueados e eles estão sendo enviados (ou definidos) para um URL seguro, você pode reduzir as proteções para None.
    • Essa solução alternativa falhará se o URL para o qual (ou a partir de onde você está enviando cookies) não for seguro. Isso ocorre porque SameSite=None exige o atributo Secure nos cookies, o que significa que esses cookies não podem ser enviados ou definidos em uma conexão sem segurança. Nesse caso, você só vai poder acessar esse cookie depois de fazer upgrade do seu site para HTTPS.
    • Lembre-se, isso é apenas temporário, já que os cookies de terceiros serão totalmente desativados.

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

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

Como os WebSockets são afetados?

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

Mesmo site:

  • Conexão wss:// do dispositivo https://
  • Conexão ws:// do dispositivo http://

Entre sites:

  • Conexão wss:// do dispositivo http://
  • Conexão ws:// do dispositivo https://

Foto de Julissa Capdevilla no Unsplash (em inglês)