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çalhoReferrer-Policy
e oreferrer
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.
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.
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çalhoReferer
edocument.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
.
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
eSec-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 emdocument.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.