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.
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
comotrue
viaabout: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.
![Uma navegação em vários esquemas acionada ao seguir um link na versão HTTP não segura de um site para a versão HTTPS segura. SameSite=Strict cookies bloqueados, SameSite=Lax e SameSite=None; Cookies seguros são permitidos.](https://web.dev/static/articles/schemeful-samesite/image/a-cross-scheme-navigation-209071cf80318.png?authuser=5&hl=pt-br)
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 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
.
![Um sub-recurso entre esquemas resultante de um recurso da versão HTTPS segura do site que foi incluído na versão HTTP não segura. Cookies SameSite=Strict e SameSite=Lax bloqueados e SameSite=None; Cookies seguros são permitidos.](https://web.dev/static/articles/schemeful-samesite/image/a-cross-scheme-subresourc-ee291fec730b8.png?authuser=5&hl=pt-br)
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ Bloqueado | ⛔ Bloqueado |
SameSite=Lax
|
⛔ Bloqueado | ⛔ Bloqueado |
SameSite=None;Secure
|
✓ Permitido | ⛔ Bloqueado |
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
.
![Um envio de formulário em vários esquemas resultante de um formulário sobre a versão HTTP não segura do site que está sendo enviado para a versão HTTPS segura. Cookies SameSite=Strict e SameSite=Lax bloqueados e SameSite=None; Cookies seguros são permitidos.](https://web.dev/static/articles/schemeful-samesite/image/a-cross-scheme-form-submi-528e4c1eb4c83.png?authuser=5&hl=pt-br)
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" (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 contrahttp://site.example/
porque o esquema não corresponde." - "O cookie
cookie_name
foi tratado como "entre sites" em relaçãohttp://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 paraLax
. - Nos casos em que os cookies
Strict
eLax
forem bloqueados e sua os cookies estão sendo enviados para (ou definidos a partir de) um URL seguro que você pode diminuir a paraNone
.- 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
requerSecure
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.
- 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
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://
dehttps://
- Conexão
ws://
dehttp://
Entre sites:
- Conexão
wss://
dehttp://
- Conexão
ws://
dehttps://
Foto de Julissa Capdevilla ativado Abrir a página