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

Maud Nalpas
Maud Nalpas
Twitter GitHub

Antes de começarmos:

  • Se você não souber a diferença entre "site" e "origin", confira este link.
  • Falta um R no cabeçalho Referer devido a um erro de ortografia original na especificação. O cabeçalho Referrer-Policy e o referrer em JavaScript e o DOM estão escritos corretamente.

Resumo

  • Os navegadores estão evoluindo em direção a políticas de referenciador padrão que melhoram a privacidade, para fornecer um bom substituto quando um site não tiver uma política definida.
  • O Chrome planeja ativar gradualmente a strict-origin-when-cross-origin como a política padrão na versão 85. Isso pode afetar os casos de uso que dependem do valor do referenciador de outra origem.
  • Esse é o novo padrão, mas os sites ainda podem escolher a política que preferirem.
  • Para testar a mudança no Chrome, ative a flag em chrome://flags/#reduced-referrer-granularity. Confira também esta demonstração para ver a mudança em ação.
  • Além da política de referenciadores, a maneira como os navegadores lidam com referenciadores pode mudar. Fique de olho nela.

O que vai mudar e por quê?

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

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

Diagrama: referenciador enviado em uma solicitação.
Política de referenciador e referenciador.

Quando nenhuma política for definida, o padrão do navegador será usado. Os sites geralmente seguem o padrão do navegador.

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

Até recentemente, a no-referrer-when-downgrade é uma política padrão generalizada em todos os navegadores. No entanto, agora muitos navegadores estão em algum estágio de mudança 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, a partir da 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. Observe que você ainda pode definir uma política que quiser. Essa mudança só terá efeito em sites que não têm nenhuma política definida.

O que essa mudança significa?

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

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

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

Exemplo:

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

  • Com no-referrer-when-downgrade: Referência: https://site-one.example/stuff/detail?tag=red.
  • Com strict-origin-when-cross-origin: Referência: 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 seu site usar HTTPS (se não for, definir como uma prioridade), os URLs dele não vazarão em solicitações que não sejam HTTPS, porque qualquer pessoa na rede pode vê-los. Isso exporia os usuários a ataques "man-in-the-middle".
  • Na mesma origem, o valor do cabeçalho Referer é o URL completo.

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

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

Qual é o impacto?

Com base em conversas com outros navegadores e na própria experimentação do Chrome executada no Chrome 84, espera-se que as falhas visíveis ao usuário sejam limitadas.

A geração de registros ou análises do lado do servidor que dependem da disponibilidade do URL completo do referenciador provavelmente serão afetadas pela granularidade reduzida nessas informações.

O que você precisa fazer?

O Chrome planeja 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 a entrada de status do Chrome.

Entender e detectar a mudança

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

Ela também pode ser usada para detectar qual política é aplicada na instância do Chrome que você está executando.

Teste a mudança e descubra se ela 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 sinalização estiver ativada, todos os sites sem uma política usarão o novo padrão strict-origin-when-cross-origin.

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

Agora é possível verificar o comportamento do site e do back-end.

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

Alguns recursos do seu site podem apresentar falhas ou se comportar de maneira diferente se você usar o referenciador de solicitações de outra origem para seu site (mais especificamente, o caminho e/ou a string de consulta) E se a origem usar a política de referenciador padrão do navegador (ou seja, não tiver nenhuma 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 de 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 de CSRF, geração de registros e outros casos de uso. Confira Referência e política do referenciador: práticas recomendadas.
  • Você pode se alinhar com os parceiros em relação a uma política específica, se necessário, e ser transparente para os usuários. O controle de acesso, quando o referenciador é usado por sites para conceder acesso específico aos recursos a outras origens, pode ser nesse caso, 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á caminhando em uma direção semelhante em relação ao referenciador. Consulte os padrões do navegador e as evoluções deles em Referer and Referrer-Policy: best Practices.

Implemente uma política explícita de melhoria de privacidade em todo o site

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

Mesmo com a mudança do Chrome em mente, é recomendável definir uma política explícita de melhoria da privacidade como strict-origin-when-cross-origin ou mais rigorosa agora.

Isso protege os usuários e faz com que seu site tenha um comportamento mais previsível em todos os navegadores. Na maioria das vezes, ele dá a você o controle, em vez de fazer com que seu site dependa dos padrões do navegador.

Consulte Referenciador e política do referenciador: práticas recomendadas para mais detalhes sobre como definir uma política.

Sobre o Chrome Enterprise

A política do Chrome Enterprise 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. Assim, as empresas têm mais tempo para testar e atualizar os aplicativos.

Essa política será removida no Chrome 88.

Enviar feedback

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

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

Recursos