Uma nova política de referenciador padrão para o Chrome: strict-origin-when-cross-origin

Maud Nalpas

Antes de começar:

  • Se você não tiver certeza da diferença entre "site" e "origem", consulte Noções básicas sobre "mesmo site" e "mesma origem".
  • O cabeçalho Referer não tem um "r" devido a um erro de ortografia original na especificação. O cabeçalho Referrer-Policy e referrer em JavaScript e no DOM estão escritos corretamente.

Resumo

  • Os navegadores estão evoluindo para políticas de referenciador padrão que melhoram a privacidade, oferecendo um bom substituto quando um site não tem uma política definida.
  • O Chrome planeja ativar gradualmente strict-origin-when-cross-origin como a política padrão na versão 85. Isso pode afetar casos de uso que dependem do valor do referenciador de outra origem.
  • Essa é a nova configuração padrão, mas os sites ainda podem escolher uma política de preferência.
  • Para testar a mudança no Chrome, ative a flag em chrome://flags/#reduced-referrer-granularity. Você também pode conferir esta demonstração para ver a mudança em ação.
  • Além da política de referenciador, a maneira como os navegadores lidam com os referenciadores pode mudar. Por isso, fique atento.

O que está mudando e por quê?

As solicitações HTTP podem incluir o cabeçalho opcional Referer, que indica a origem ou o URL da página da Web de onde a solicitação foi feita. O Referer-Policy cabeçalho define quais dados são disponibilizados no Referer cabeçalho e para navegação e iframes no document.referrer do destino.

As informações enviadas no cabeçalho Referer em uma solicitação do seu site são determinadas pelo cabeçalho Referrer-Policy definido.

Diagrama: referenciador enviado em uma solicitação.
Referrer-Policy e Referer.

Quando nenhuma política é definida, o padrão do navegador é usado. Os sites geralmente usam o padrão do navegador.

Para navegações e iframes, os dados presentes no cabeçalho Referer também podem ser acessados via JavaScript usando document.referrer.

Até recentemente, no-referrer-when-downgrade era uma política padrão generalizada em todos os navegadores. Mas agora muitos navegadores estão em algum estágio de migração para padrões que melhoram a privacidade.

O Chrome planeja mudar a política padrão de no-referrer-when-downgrade para strict-origin-when-cross-origin, começando na versão 85.

Isso significa que, se nenhuma política for definida para seu site, o Chrome usará strict-origin-when-cross-origin por padrão. Ainda é possível definir uma política de sua preferência. Essa mudança só terá efeito em sites que não têm uma política definida.

O que essa mudança significa?

strict-origin-when-cross-origin oferece mais privacidade. Com essa política, apenas a origem é enviada no cabeçalho Referer de solicitações entre origens.

Isso impede vazamentos de dados particulares que podem ser acessados em outras partes do URL completo, como o caminho e a string de consulta.

Diagrama: referenciador enviado dependendo da política, para uma solicitação entre origens.
Referenciador enviado (e document.referrer) para uma solicitação entre origens, dependendo da política.

Exemplo:

Solicitação entre origens, enviada de https://site-one.example/stuff/detail?tag=red para https://site-two.example/…:

  • Com no-referrer-when-downgrade: Referer: https://site-one.example/stuff/detail?tag=red.
  • Com strict-origin-when-cross-origin: Referer: https://site-one.example/.

O que permanece igual?

  • Assim como no-referrer-when-downgrade, strict-origin-when-cross-origin é seguro: nenhum referenciador (cabeçalho Referer e document.referrer) está presente quando a solicitação é feita de uma origem HTTPS (segura) para uma HTTP (não segura). Dessa forma, se o site usar HTTPS (se não, priorize isso), os URLs do site não serão vazados em solicitações não HTTPS, porque qualquer pessoa na rede pode vê-los. Isso exporia seus usuários a ataques man-in-the-middle.
  • Na mesma origem, o valor do cabeçalho Referer é o URL completo.

Exemplo: solicitação de mesma origem, enviada de https://site-one.example/stuff/detail?tag=red para https://site-one.example/…:

  • Com strict-origin-when-cross-origin: Referer: https://site-one.example/stuff/detail?tag=red

Qual é o impacto?

Com base em discussões com outros navegadores e na própria experimentação do Chrome executada na versão 84, espera-se que a quebra visível ao usuário seja limitada.

É provável que o registro ou a análise do lado do servidor que dependem da disponibilidade do URL completo do referenciador sejam afetados pela redução da granularidade dessas informações.

O que você precisa fazer?

O Chrome planeja começar a lançar a nova política de referenciador padrão na versão 85 (julho de 2020 para a versão Beta e agosto de 2020 para a versão estável). Consulte o status na entrada de status do Chrome.

Entender e detectar a mudança

Para entender o que as novas mudanças padrão fazem na prática, confira esta demonstração.

Você também pode usar essa demonstração para detectar qual política é aplicada na instância do Chrome em execução.

Teste a mudança e descubra se ela vai afetar seu site

Você já pode testar a mudança a partir do Chrome 81: acesse chrome://flags/#reduced-referrer-granularity no Chrome e ative a flag. Quando essa flag está ativada, todos os sites sem uma política usam o novo padrão strict-origin-when-cross-origin.

Captura de tela do Chrome: como ativar a flag chrome://flags/#reduced-referrer-granularity.
Ativação da flag.

Agora você pode verificar como seu site e back-end se comportam.

Outra coisa a fazer para detectar o impacto é verificar se a base de código do seu site usa o referenciador, seja pelo cabeçalho Referer de solicitações recebidas no servidor ou de document.referrer em JavaScript.

Alguns recursos do seu site podem quebrar ou se comportar de maneira diferente se você estiver usando o referenciador de solicitações de outra origem para seu site (mais especificamente o caminho e/ou a string de consulta) E essa origem usa a política de referenciador padrão do navegador (ou seja, não tem uma política definida).

Se isso afetar seu site, considere alternativas

Se você estiver usando o referenciador para acessar o caminho completo ou a string de consulta para solicitações ao seu site, terá algumas opções:

  • Use técnicas e cabeçalhos alternativos, como Origin e Sec-fetch-Site, para proteção CSRF, registro e outros casos de uso. Confira Referenciador e Referrer-Policy: práticas recomendadas.
  • Você pode se alinhar com parceiros em uma política específica, se isso for necessário e transparente para seus usuários. O controle de acesso, quando o referenciador é usado por sites para conceder acesso específico aos recursos deles a outras origens, pode ser um caso desse tipo, embora, com a mudança do Chrome, a origem ainda seja compartilhada no cabeçalho Referer (e em document.referrer).

A maioria dos navegadores está se movendo em uma direção semelhante quando se trata do referenciador. Consulte os padrões do navegador e as evoluções deles em Referenciador e Referrer-Policy: práticas recomendadas.

Implementar uma política explícita que melhora a privacidade em todo o site

Qual Referer deve ser enviado em solicitações originadas pelo seu site, ou seja, qual política você deve definir para seu site?

Mesmo com a mudança do Chrome em mente, é uma boa ideia definir uma política explícita que melhora a privacidade, como strict-origin-when-cross-origin ou mais rigorosa.

Isso protege seus usuários e faz com que seu site se comporte de maneira mais previsível em todos os navegadores. Principalmente, isso oferece controle, em vez de fazer com que seu site dependa dos padrões do navegador.

Consulte Referenciador e Referrer-Policy: práticas recomendadas para detalhes sobre como definir uma política.

Sobre o Chrome Enterprise

A política corporativa do Chrome ForceLegacyDefaultReferrerPolicy está disponível para administradores de TI que querem forçar a política de referenciador padrão anterior de no-referrer-when-downgrade em ambientes corporativos. Isso permite que as empresas tenham mais tempo para testar e atualizar os aplicativos.

Essa política será removida no Chrome 88.

Enviar feedback

Você tem feedback para compartilhar ou algo a relatar? Compartilhe feedback sobre a intenção de envio do Chrome ou envie suas perguntas por tweet para @maudnals.

Agradecemos muito as contribuições e o feedback de todos os revisores, especialmente Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck e Kayce Basques.

Recursos