O que é Referrer-Policy?

O cabeçalho HTTP Referrer-Policy controla quanta informação sobre a página de origem é incluída no cabeçalho de requisição Referer quando um usuário navega do seu site para outro, ou quando sua página carrega recursos de fontes externas. Toda vez que alguém clica em um link, toda vez que uma imagem é carregada de uma CDN, toda vez que um script de analytics é disparado, o navegador potencialmente envia a URL da página atual para o servidor de destino. O Referrer-Policy permite decidir quanto dessa URL compartilhar.

(Uma observação rápida sobre a grafia: o cabeçalho HTTP é escrito "Referer" com um "r" só, devido a um erro de grafia na especificação HTTP original do início dos anos 1990. O cabeçalho de política usa a grafia correta "Referrer" com dois "r". Ambas as grafias são intencionais.)

O que o cabeçalho Referer contém e quando é enviado

Por padrão (sem um Referrer-Policy), o navegador envia a URL completa da página atual como cabeçalho Referer na maioria das requisições de saída. Isso inclui:

• Navegação: quando um usuário clica em um link para outro site, o destino recebe a URL completa da página de onde ele veio.
• Requisições de subrecursos: quando sua página carrega imagens, scripts, folhas de estilo ou fontes de domínios externos, cada requisição inclui o cabeçalho Referer.
• Envios de formulário: quando um formulário envia dados para uma URL externa, o cabeçalho Referer é incluído.
• Requisições AJAX e Fetch: chamadas de API a serviços externos também incluem o cabeçalho Referer por padrão.

Suponha que um visitante esteja nesta URL no seu site WordPress:

https://yoursite.com/members/dashboard?session=abc123&plan=premium

Se essa página contém uma imagem incorporada de um provedor de analytics externo ou de uma rede de publicidade, o servidor desse provedor recebe a URL completa no cabeçalho Referer, incluindo os parâmetros de consulta com o token de sessão e as informações do plano. Essa é a preocupação de privacidade que o Referrer-Policy resolve.

Todos os valores do Referrer-Policy explicados

O cabeçalho Referrer-Policy suporta oito valores distintos. Cada um define um nível diferente de compartilhamento de informação:

• no-referrer: nunca enviar o cabeçalho Referer. O destino não recebe nenhuma informação sobre a origem da requisição. É a opção mais privada, mas pode quebrar funcionalidades que dependem do referrer (algumas proteções CSRF, por exemplo).
• no-referrer-when-downgrade: enviar a URL completa, mas remover o Referer ao navegar de HTTPS para HTTP (um "downgrade"). Esse foi o padrão dos navegadores por muitos anos. Protege contra vazamento de URLs ao sair de um contexto seguro, mas compartilha tudo em navegação HTTPS-para-HTTPS.
• origin: enviar somente a origem (esquema, host e porta), mas não o caminho ou query string. Assim, https://yoursite.com/members/dashboard?session=abc123 vira apenas https://yoursite.com/. O destino sabe de qual site o visitante veio, mas não qual página específica.
• origin-when-cross-origin: enviar a URL completa para requisições de mesma origem (links dentro do seu próprio site), mas apenas a origem para requisições cross-origin. Isso dá às suas próprias ferramentas de analytics e internas dados completos de referrer enquanto limita o que sites externos enxergam.
• same-origin: enviar a URL completa apenas para requisições de mesma origem. Para requisições cross-origin, não enviar nenhum Referer. Isso é bem privado para navegação externa, mas significa que serviços externos recebem zero dados de referrer.
• strict-origin: enviar somente a origem (como o valor origin), mas remover o Referer totalmente em downgrades de HTTPS para HTTP. Combina a privacidade de origin com a proteção de downgrade de no-referrer-when-downgrade.
• strict-origin-when-cross-origin: o valor mais comumente recomendado. Envia a URL completa para requisições de mesma origem, apenas a origem para requisições cross-origin HTTPS-para-HTTPS, e nada para downgrades de HTTPS para HTTP. É o melhor equilíbrio entre privacidade, segurança e funcionalidade. Navegadores modernos (Chrome 85+, Firefox 87+) adotaram esse valor como padrão, mesmo quando nenhum cabeçalho Referrer-Policy está presente.
• unsafe-url: sempre enviar a URL completa, independentemente do destino ou contexto de segurança. Chama-se "unsafe" por uma razão. Envia parâmetros de consulta, caminhos e tudo o mais até para destinos HTTP. Nunca use isso, a menos que tenha uma necessidade muito específica e entenda os riscos.

Implicações de privacidade do cabeçalho Referer

O cabeçalho Referer é uma preocupação significativa de privacidade que muitos proprietários de sites ignoram. Considere quais informações suas URLs podem conter:

• Consultas de busca: se o seu site tem uma função de busca, a URL pode ser /search?q=tema+sensivel+de+saude. Qualquer recurso externo carregado na página de resultados recebe essa consulta.
• Identificadores de usuário: URLs como /user/john-doe/profile ou /order/12345 vazam informações de usuário e pedido para terceiros.
• Tokens e dados de sessão: alguns aplicativos colocam tokens em URLs para redefinição de senha, confirmações por e-mail ou links de compartilhamento. Eles podem vazar pelo cabeçalho Referer.
• Estrutura interna de URLs: até mesmo a estrutura do caminho (/wp-admin/, /members-only/, /internal-dashboard/) revela informações sobre a arquitetura do seu site.

Cada recurso de terceiros na sua página é um potencial destinatário dessa informação: Google Fonts, scripts de analytics, botões de redes sociais, vídeos incorporados, redes de publicidade, bibliotecas hospedadas em CDNs e imagens externas. Cada um deles recebe o cabeçalho Referer com suas requisições.

Relevância para GDPR e proteção de dados

Sob o GDPR e regulamentações similares de privacidade, URLs que contêm identificadores pessoais ou informações sensíveis podem constituir dados pessoais. Se suas URLs contêm nomes de usuário, endereços de e-mail ou outras informações identificáveis, compartilhar essas URLs via cabeçalho Referer com terceiros pode ser uma questão de proteção de dados.

Definir um Referrer-Policy é uma medida técnica direta que reduz o compartilhamento desnecessário de dados com terceiros. Embora não seja explicitamente exigido pelo GDPR, alinha-se aos princípios de minimização de dados (Artigo 5(1)(c)) e privacy by design (Artigo 25). Se o seu encarregado de proteção de dados ou auditoria de privacidade perguntar quais medidas técnicas você tem para limitar o vazamento de dados, um Referrer-Policy adequado é um item concreto que você pode apontar.

Comportamento padrão do WordPress e plugins comuns

O núcleo do WordPress não define um cabeçalho Referrer-Policy por padrão. Isso significa que seu site depende do padrão embutido no navegador. Para navegadores modernos, esse padrão é strict-origin-when-cross-origin, que é, na verdade, uma política razoável. No entanto, há algumas observações:

• Navegadores antigos ainda podem ter como padrão no-referrer-when-downgrade, que envia a URL completa em todas as requisições HTTPS-para-HTTPS.
• Definir o cabeçalho explicitamente é melhor do que confiar nos padrões do navegador, porque comunica sua intenção claramente e cobre todas as versões de navegador.
• Alguns plugins de segurança do WordPress (como Sucuri ou iThemes Security) incluem uma opção de Referrer-Policy em suas configurações de hardening.
• O WordPress 4.7.4 introduziu melhorias na função wp_get_referer(), mas essa é uma função do lado do servidor que lê o cabeçalho Referer para proteção CSRF. Ela não está relacionada ao cabeçalho de resposta Referrer-Policy.

Impacto sobre as ferramentas de analytics do site

A escolha do Referrer-Policy afeta diretamente quais dados de referrer suas ferramentas de analytics recebem, e quais dados outros sites recebem sobre o tráfego vindo do seu site:

• Seu próprio analytics: se você usa Google Analytics, Matomo ou ferramenta similar com um script de rastreamento no seu site, requisições de mesma origem sempre incluirão o referrer completo, independente da política (a maioria das políticas só restringe referrers cross-origin). Portanto, os dados de analytics do seu próprio site não são afetados pela maioria dos valores de política.
• Rastreamento de tráfego de entrada: o Referrer-Policy que você define afeta o que outros sites enxergam quando seus visitantes vêm do seu site. Não afeta o que você enxerga sobre o tráfego que chega ao seu site (isso depende da política do site referenciador).
• Rastreamento de afiliados e parceiros: se você administra um programa de afiliados ou precisa rastrear cliques de saída, uma política muito restritiva como no-referrer quebrará o rastreamento baseado em referrer. O recomendado strict-origin-when-cross-origin envia a origem (domínio) aos parceiros, o que costuma ser suficiente para atribuição.

Configurando Referrer-Policy para WordPress

O valor recomendado para a maioria dos sites WordPress é strict-origin-when-cross-origin:

Referrer-Policy: strict-origin-when-cross-origin

Para definir no Apache:

Header always set Referrer-Policy "strict-origin-when-cross-origin"

No nginx:

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Via PHP:

add_action('send_headers', function() {
    header('Referrer-Policy: strict-origin-when-cross-origin');
});

Se o seu site lida com dados particularmente sensíveis (informações médicas, registros financeiros, documentos jurídicos), você pode considerar uma política mais estrita como same-origin ou no-referrer. Apenas tenha em mente que isso removerá a informação de referrer de todas as requisições cross-origin, o que pode afetar serviços externos que dependem dela.

O que o InspectWP verifica

O InspectWP verifica se o seu site WordPress envia um cabeçalho Referrer-Policy e relata o valor configurado. Se o cabeçalho estiver ausente, seu site depende do padrão do navegador de cada visitante, que varia entre versões de navegador. Definir explicitamente um Referrer-Policy garante comportamento consistente e demonstra que você tomou uma decisão deliberada sobre quanta informação de URL seu site compartilha com terceiros. Para a grande maioria dos sites WordPress, strict-origin-when-cross-origin é o valor recomendado.