Antes de começar:
- Se você não tiver certeza da diferença entre "site" e "origem", leia Noções básicas sobre "mesmo site" e "mesma origem".
- O cabeçalho
Referernão contém um R devido a um erro original de ortografia na especificação. O cabeçalhoReferrer-Policye oreferrerno JavaScript e no DOM estão escritos corretamente.
Resumo
- Os navegadores estão evoluindo para políticas de referenciadores padrão que aumentam a privacidade e oferecem uma boa alternativa quando um site não tem uma política definida.
- O Chrome planeja ativar gradualmente a
strict-origin-when-cross-origincomo 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 quiserem.
- Para testar a mudança no Chrome, ative a sinalização 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. Portanto, fique de olho.
O que vai mudar e por quê?
As solicitações HTTP podem incluir o cabeçalho Referer opcional, que indica a
origem ou o URL 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 que são enviadas no cabeçalho Referer de uma solicitação do seu site são determinadas pelo cabeçalho Referrer-Policy definido por você.
Quando nenhuma política é definida, o padrão do navegador é usado. Os sites costumam usar 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é pouco tempo atrás,
no-referrer-when-downgrade
era uma política padrão generalizada em todos os navegadores. No entanto, 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 o site, o Chrome vai usar
strict-origin-when-cross-origin por padrão. Ainda é possível definir a política que você quiser. Essa alteração só terá efeito em sites que não tenham uma política definida.
O que essa mudança significa?
O strict-origin-when-cross-origin oferece mais privacidade. Com essa política, apenas o
origin é enviado no cabeçalho Referer das
solicitações de origem cruzada.
Isso evita vazamentos de dados particulares que podem ser acessados por outras partes do URL completo, como o caminho e a string de consulta.
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: 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çalhoRefereredocument.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 (caso contrário, defina-o como uma prioridade), os URLs dele não vão vazar em solicitações não HTTPS, porque qualquer pessoa na rede pode vê-los, e isso expõe 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 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 execução de experimentos do próprio Chrome no Chrome 84, é esperado 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 do referenciador completo 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 referenciadores padrão em 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 o novo padrão muda na prática, confira esta demonstração.
Também é possível usar esta demonstração para detectar qual política é aplicada à instância do Chrome que você está executando.
Teste a alteração 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 sinalização. Quando essa sinalização estiver ativada, todos os sites sem uma política usarão o novo padrão da strict-origin-when-cross-origin.
Agora você pode verificar como seu site e back-end se comportam.
Outra ação para detectar o impacto é verificar se a base de código do seu site usa o referenciador, seja pelo cabeçalho Referer das solicitações recebidas no servidor ou de document.referrer no JavaScript.
Certos recursos no seu site podem falhar 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 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 impactar seu site, considere alternativas
Se estiver usando o referenciador para acessar o caminho completo ou a string de consulta para solicitações ao site, você terá algumas opções:
- Use técnicas e cabeçalhos alternativos, como
OrigineSec-fetch-Site, para proteção do CSRF, geração de registros e outros casos de uso. Confira a Política de referenciadores e referenciadores: práticas recomendadas. - Você pode se alinhar com os parceiros sobre uma política específica se necessário e 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 acontecer. No entanto, com a mudança do Chrome, a origem ainda será
compartilhada no cabeçalho
Referer(e nodocument.referrer).
A maioria dos navegadores está caminhando em uma direção semelhante quando se trata do referenciador. Veja os padrões do navegador e as evoluções deles em Referer and Referrer-Policy: best practices.
Implementar uma política explícita que melhora a privacidade no seu site
Qual Referer deve ser enviado em solicitações originadas do seu site, ou seja, qual política você precisa definir para ele?
Mesmo com a mudança do Chrome em mente, ainda é bom definir uma política explícita que melhora a privacidade, como strict-origin-when-cross-origin ou mais rigorosa.
Isso protege os usuários e faz com que o site se comporte de maneira mais previsível em todos os navegadores. Em geral, ele oferece controle, em vez de fazer com que o site dependa dos padrões do navegador.
Consulte Referenciador e política do referenciador: práticas recomendadas para detalhes sobre como definir uma política.
Sobre o Chrome Enterprise
A política corporativa ForceLegacyDefaultReferrerPolicy do Chrome 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 comentários para compartilhar ou informar algo? Compartilhe feedback sobre a intenção de envio do Chrome ou tuíte suas perguntas para @maudnals.
Agradecemos muito pelas contribuições e pelo feedback a todos os revisores, especialmente Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck e Kayce Basques.