Referer

O cabeçalho Referer (sim, com erro ortográfico — a especificação HTTP de 1996 definiu a forma canônica como “Referer” e o erro tipográfico se tornou padrão) é enviado pelos navegadores na maioria das requisições, contendo a URL da página em que o usuário estava quando acionou a requisição.

Usado para:

• Análise web — “de onde veio esse tráfego?”
• Prevenção de hotlinking — hosts de imagens verificando que as requisições se originam de sites aprovados.
• Defesa em profundidade contra CSRF — alguns aplicativos verificam se Referer corresponde à origem esperada.
• Atribuição de afiliados — rastreando qual site parceiro gerou uma conversão.

Preocupação moderna com privacidade: a URL completa — incluindo tokens, consultas de pesquisa ou PII no caminho da URL — vaza para todos os recursos de terceiros que a página carrega. O cabeçalho de resposta Referrer-Policy (note: grafado corretamente desta vez) controla quanta informação de referência os navegadores enviam:

• no-referrer: nunca enviar um cabeçalho Referer.
• same-origin: enviar URL completa para requisições de mesma origem, nada para outras.
• strict-origin-when-cross-origin: enviar apenas a origem para requisições HTTPS de origens diferentes. Padrão moderno dos navegadores.
• unsafe-url: enviar sempre a URL completa. Evitar.

Para aplicativos sensíveis à privacidade, defina uma política estrita em cada resposta.

O famoso erro tipográfico: o cabeçalho foi originalmente proposto em 1995 por Phillip Hallam-Baker, e a especificação grafou erroneamente “Referrer” como “Referer” antes que o erro fosse percebido. Quando alguém notou, diversas implementações importantes já estavam em uso. O RFC 1945 congelou o erro ortográfico como canônico, e todos os navegadores desde então tiveram que usar a forma incorreta para compatibilidade com o protocolo HTTP. Quando o W3C adicionou um cabeçalho de política em 2014, eles deliberadamente grafaram corretamente (Referrer-Policy) para diferenciá-lo do cabeçalho de requisição legado.

O que os navegadores modernos enviam por padrão: a partir do Chrome 85 (ago 2020), Firefox 87 (mar 2021) e Safari 14, a política padrão é strict-origin-when-cross-origin. Requisições de origens diferentes agora recebem apenas a origem (https://example.com), não a URL completa. Requisições da mesma origem ainda recebem a URL completa. Essa única mudança eliminou uma década de vazamentos acidentais de tokens de URL para scripts de análise e adtech de terceiros. Para configurações de paranoia máxima (banco, saúde), defina Referrer-Policy: no-referrer em cada resposta — os cabeçalhos de produção da Convertitive usam strict-origin-when-cross-origin por padrão. Referência: W3C — Referrer Policy.

Exemplo prático: vazamento de URL de redefinição de senha

Um padrão comum de violação: um aplicativo envia por e-mail um link de redefinição de senha no formato https://app.example.com/reset?token=abc123def456.... O usuário clica; a página de redefinição carrega e inclui Google Analytics, Facebook Pixel e uma biblioteca de gráficos de um CDN. Com a política padrão anterior a 2020, cada requisição de terceiros carregava Referer: https://app.example.com/reset?token=abc123def456... — vazando o token de redefinição para os logs de servidor de quatro fornecedores diferentes. Com o padrão moderno strict-origin-when-cross-origin, as requisições de origens diferentes carregam apenas Referer: https://app.example.com e o token permanece privado. Melhor ainda, defina Referrer-Policy: no-referrer em cada resposta de fluxo sensível — a defesa em profundidade não custa nada.

O que ainda vaza apesar da política

Referrer-Policy governa apenas o cabeçalho Referer. Tokens de URL ainda aparecem no histórico do navegador, na propriedade JavaScript document.referrer visível para scripts de mesma origem, em instruções de log de window.location e em qualquer SDK de monitoramento de erros que capture URLs. A correção arquitetural é colocar tokens sensíveis no corpo da requisição ou em um cookie de curta duração definido imediatamente ao pousar, e então redirecionar para uma URL sem o token. Referência: RFC 9110 — HTTP Semantics §10.1.3 (Referer), que preserva o erro ortográfico original na reescrita canônica do HTTP de 2022.