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.
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
comotrue
viaabout: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
Navegação
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.
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
.
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
.
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 ahttp://site.example/
porque o esquema não corresponde." - "O cookie
cookie_name
foi tratado como entre sites em relação ahttp://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 paraLax
. - Nos casos em que os cookies
Strict
eLax
estão sendo bloqueados e eles estão sendo enviados (ou definidos) para um URL seguro, você pode reduzir as proteções paraNone
.- 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 atributoSecure
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.
- 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
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 dispositivohttps://
- Conexão
ws://
do dispositivohttp://
Entre sites:
- Conexão
wss://
do dispositivohttp://
- Conexão
ws://
do dispositivohttps://
Foto de Julissa Capdevilla no Unsplash (em inglês)