Antes de começar:
- Se você não souber a diferença entre "site" e "origem", consulte Como entender "mesmo site" e "mesma origem".
- O cabeçalho
Referernão tem uma letra R, devido a um erro de ortografia na especificação. O cabeçalhoReferrer-Policyereferrerno 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, para oferecer uma boa alternativa quando um site não tiver 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 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.
- 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 referenciador, a maneira como os navegadores lidam com os referenciadores pode mudar. Fique de olho nisso.
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 de onde 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 enviadas no cabeçalho Referer de uma solicitação do seu site são determinadas
pelo cabeçalho Referrer-Policy definido.
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 por
JavaScript usando document.referrer.
Até pouco tempo atrás,
no-referrer-when-downgrade
era uma política padrão em todos os navegadores. No entanto, muitos navegadores estão em algum estágio de
mudança para padrões mais avançados de 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 vai usar
strict-origin-when-cross-origin por padrão. Você ainda pode definir uma política.
Essa mudança só vai afetar 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 evita vazamentos de dados particulares que podem ser acessados de outras partes do URL completo, como o caminho e a string de consulta.
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ç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 (se não, priorize o uso), os URLs dele não serão vazados em solicitações que não são HTTPS, porque qualquer pessoa na rede pode acessá-los. 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 nas discussões com outros navegadores e na própria experimentação do Chrome 84, espera-se que a quebra visível para o usuário seja limitada.
O registro ou a análise no servidor que dependem da disponibilidade do URL completo do referente provavelmente serão afetados pela granularidade reduzida 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). Confira o status na entrada de status do Chrome.
Entender e detectar a mudança
Para entender as novas mudanças padrão 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 que está 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 é
ativada, todos os sites sem uma política usam o novo strict-origin-when-cross-origin padrão.
Agora você pode conferir como seu site e o back-end se comportam.
Outra maneira de detectar o impacto é verificar se a base de código do seu site usa o referente, seja
pelo cabeçalho Referer das solicitações recebidas no servidor ou pelo document.referrer no
JavaScript.
Alguns recursos no seu site podem falhar ou se comportar de maneira diferente se você estiver usando o referrer 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 referrer 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 referrer 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
OrigineSec-fetch-Site, para proteção contra CSRF, registro e outros casos de uso. Confira Referrer e Referrer-Policy: práticas recomendadas. - Você pode se alinhar com os parceiros em uma política específica, se isso for 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
de outras origens, pode ser um desses casos, embora, com a mudança do Chrome, a origem ainda seja
compartilhada no cabeçalho
Referer(e emdocument.referrer).
A maioria dos navegadores está seguindo uma direção semelhante em relação ao referrer (confira os padrões do navegador e as evoluções deles em Referrer e Referrer-Policy: práticas recomendadas).
Implementar uma política explícita que melhore a privacidade em todo o site
Qual Referer precisa ser enviado em solicitações originadas pelo seu site, ou seja, qual política precisa
ser definida para seu site?
Mesmo com a mudança de ideia do Chrome, é recomendável definir uma política explícita de melhoria da 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 depender das configurações padrão do navegador.
Consulte Referrer 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 ou algo a informar? Compartilhe seu feedback sobre a intenção de lançamento do Chrome ou envie suas perguntas por tweet para @maudnals.
Agradecemos 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.