Referrer-Policy: todos os valores comparados e a regra que ninguém conta

O que o cabeçalho Referrer-Policy faz

Quando um navegador segue um link ou busca um recurso, normalmente ele conta ao destino de onde a requisição veio, num cabeçalho chamado Referer. Referrer-Policy é como um site controla quanto disso entrega: a URL inteira com caminho e query, só a origem, ou nada. São oito valores, e a especificação define cada um diante de três situações: uma requisição para a mesma origem, uma para outra origem, e uma que sai de uma página segura para um destino inseguro.

Se você não manda cabeçalho nenhum, o que vale é strict-origin-when-cross-origin. Isso manda a URL completa dentro do seu próprio site, só a origem ao sair dele, e nada quando o destino cai para HTTP puro. É um padrão sensato, e vale conhecer, porque um cabeçalho que o navegador não consegue interpretar deixa você exatamente com isso e mais nada.

Um detalhe que a própria especificação aponta sobre o nome dela: o cabeçalho não repete o famoso erro de grafia. O cabeçalho de requisição é Referer, com um r só, um erro de digitação velho o bastante para ser permanente. O cabeçalho de resposta que o controla é Referrer-Policy, escrito certo. Trocar os dois é um jeito comum de escrever um cabeçalho que, em silêncio, não faz nada.

Como usar

1. Cole o seu cabeçalho. Um por linha se você manda mais de um — um navegador lê vários cabeçalhos Referrer-Policy como uma única lista separada por vírgulas. O painel abaixo mostra cada valor e diz qual ele vai realmente usar.
2. Coloque as duas URLs. A página que faz o link e o destino. As duas precisam de esquema, porque é o esquema que decide se a requisição é de mesma origem, de outra origem, ou um rebaixamento — e essas três são as únicas distinções que qualquer das políticas faz.
3. Leia a linha do Referer. Ela mostra o cabeçalho exato que a requisição levaria, ou diz que nenhum é mandado. A tabela no fim põe as oito políticas lado a lado, com a que está em vigor destacada.

Por que o último valor vence, e por que isso é útil

Esta é a parte que pega as pessoas, e está escrita com clareza. A especificação diz que valores de política desconhecidos são ignorados, e que quando várias fontes especificam uma política de referenciador, usa-se o valor da última. Não o da primeira. O algoritmo de análise tem três passos: comece com nada e, para cada token do cabeçalho, se for uma política que você reconhece, defina a política como ela. O último que você reconheceu é com o que você fica.

Isso inverte o instinto habitual. Um valor de cabeçalho com cara de lista normalmente significa alternativas em ordem de preferência, e o jeito natural de escrever um parser é pegar a primeira coisa que você entende e parar. Aqui é preciso continuar, e um parser que para cedo dá a resposta errada no próprio exemplo da especificação.

O motivo é implantação. A especificação trabalha o caso ela mesma: mande origin seguido de unsafe-url e um navegador velho demais para conhecer unsafe-url ignora e usa origin, enquanto um atual vai até o fim e usa unsafe-url. Então Referrer-Policy: origin, unsafe-url não é um erro nem uma linha duplicada — é a forma documentada de adotar um valor novo sem abandonar clientes antigos. A gramática foi feita para isso: a especificação permite um token desconhecido justamente para que um navegador não falhe ao analisar o cabeçalho inteiro ao encontrar um.

A mesma regra tem um lado mais afiado. Se nada no seu cabeçalho for reconhecido — um erro de digitação, um valor tirado de um post que nunca chegou a existir, um nome de política com underscore — o navegador fica com a string vazia e recorre ao padrão dele. O cabeçalho não fez nada, e nada na resposta te avisa. É isso que o painel acima relata primeiro.

O que cada política realmente manda

A tabela de oito por três desta página é transcrita da frase da especificação que define cada política, e não montada de memória nem tirada das tabelas dos outros. Duas linhas merecem ser lidas duas vezes, porque são as mais confundidas.

origin e strict-origin parecem quase iguais — as duas mandam só a origem — e diferem em exatamente uma casa. origin manda para todo lado, inclusive para HTTP puro; strict-origin cala nesse rebaixamento. A especificação é explícita sobre o motivo: nota que origin permite que a origem de referenciadores HTTPS trafegue pela rede dentro de requisições HTTP não criptografadas, e que strict-origin resolve essa preocupação. O mesmo par se repete um nível acima: origin-when-cross-origin e strict-origin-when-cross-origin só diferem na coluna do rebaixamento.

Há também um caso que surpreende quem pensa em origens como uma questão de nomes de domínio. Uma origem inclui o esquema, então ir de http para https no mesmo host é uma requisição de outra origem, não da mesma — a especificação cita explicitamente as atualizações de protocolo. Uma porta diferente faz o mesmo. Se uma política se comporta de forma estranha numa requisição que nem sai do seu domínio, normalmente é por isso.

E unsafe-url significa o que diz. A especificação acrescenta uma nota que quase soa como desculpa: o nome da política não mente, ela é insegura, e vai vazar origens e caminhos de recursos seguros para origens inseguras. O exemplo dela usa um documento chamado sekrit.html por algum motivo.

O que isto não vai te dizer

Isto descobre o que uma política significa. Não sabe o que o seu servidor manda. Um navegador não consegue ler os cabeçalhos de resposta de outro site para você, então o cabeçalho na caixa é o que você digitou, não o que está em produção — confira isso no painel de rede do navegador ou com uma requisição pela linha de comando.

A classificação de um destino como seguro ou não é uma simplificação, e vale dizer. A especificação delega a outro padrão o que conta como URL potencialmente confiável, e aquele algoritmo cobre mais coisa do que esta página implementa: aqui https, wss e file, mais localhost e os endereços de loopback, são tratados como confiáveis e todo o resto não. Isso cobre todos os exemplos da especificação e tudo o que você provavelmente vai digitar, mas um esquema que um navegador ou um aplicativo empacotado registre como confiável será julgado errado.

A política de uma página também não é a única coisa em jogo. Um único link pode sobrescrevê-la com um atributo referrerpolicy, rel=noreferrer remove o referenciador por completo, um iframe pode definir o seu, e um redirecionamento pode mudar a política no meio de uma requisição. Esta página responde à pergunta para uma política e um par de URLs, que é do que o cabeçalho trata; o resto são decisões por elemento tomadas na sua marcação.

Por fim, nada disto é garantia de privacidade. Suprimir o cabeçalho Referer corta um vazamento específico; não faz nada quanto a uma URL que você passou numa query string, a um script que informa a localização por conta própria, ou ao que o destino consiga inferir da requisição por outras vias. É um controle útil, não uma cortina.

Por que é grátis?

Ler um cabeçalho e comparar duas URLs é trabalho de texto e roda no seu navegador. Não há servidor envolvido, então não há nada para cobrar nem conta para criar.

Nada é enviado e nada é guardado. Recarregue a página e ela terá esquecido as URLs que você digitou.