Define um Referrer-Policy estrito

O que esta verificação faz

Inspeciona os cabeçalhos da resposta à procura de uma diretiva Referrer-Policy e verifica se o valor é uma das políticas mais seguras: strict-origin-when-cross-origin (o padrão por defeito dos navegadores modernos), strict-origin, same-origin, no-referrer ou no-referrer-when-downgrade. A verificação falha quando o cabeçalho está ausente ou definido para uma política com fugas (unsafe-url, origin-when-cross-origin sem strict-).

Porque é importante

O cabeçalho de pedido Referer (sim, mal escrito no RFC original e ficámos com isso) diz a cada site para onde clicas de qual URL vieste. Sem uma política, o navegador envia o URL completo — incluindo caminho, query string e fragmento.

É um buraco de privacidade maior do que a maioria das pessoas imagina.

• Fuga de tokens. Ligações de recuperação de palavra-passe, URLs de magic-login, callbacks OAuth e URLs “partilha com esta ligação privada” carregam todos segredos no caminho ou query. Cada recurso externo na página (analytics, fontes, scripts de terceiros, imagens incorporadas, ligações de saída) recebe o URL completo como Referer.
• Fuga de dados pessoais. URLs como /users/jane-patel@example.com/profile ou /checkout?email=… fazem fuga de dados pessoais para redes de anúncios e ferramentas de analytics.
• Descoberta de caminhos de admin. Um clique de /admin/users/42 para uma imagem externa anuncia silenciosamente a existência de /admin/ a cada serviço externo.
• Exposição ao RGPD. Enviar dados pessoais para uma rede de anúncios sediada nos EUA sem consentimento é uma violação do RGPD, independentemente da intenção. Uma política estrita de referrer é uma mitigação barata.

Os navegadores modernos (Chrome 85+, Firefox 87+, Safari 14+) trazem strict-origin-when-cross-origin como padrão, mas apenas quando a página não devolve nenhuma política. Navegadores antigos e casos limite (origens file://, navegações http→http) continuam a ter fugas a menos que definas o cabeçalho explicitamente.

Como corrigir

Escolhe uma das políticas seguras e define-a nos cabeçalhos de resposta:

Política	Mesma origem	Origem cruzada	Downgrade entre origens (https→http)
no-referrer	nada	nada	nada
same-origin	URL completo	nada	nada
strict-origin	só origem	só origem	nada
strict-origin-when-cross-origin (recomendado)	URL completo	só origem	nada

strict-origin-when-cross-origin é o padrão moderno: as tuas próprias navegações internas recebem URLs completos (útil para analytics), as ligações externas só recebem a origem (https://example.com/), e os downgrades para HTTP não enviam nada.

nginx:

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

Apache:

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

Caddy:

header Referrer-Policy "strict-origin-when-cross-origin"

Cloudflare — Rules → Transform Rules → Modify Response Header, define globalmente.

Next.js (next.config.js):

module.exports = {
  async headers() {
    return [{
      source: "/(.*)",
      headers: [
        { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
      ],
    }];
  },
};

Express com Helmet:

import helmet from "helmet";
app.use(helmet.referrerPolicy({ policy: "strict-origin-when-cross-origin" }));

Sobreposição por ligação. Se uma ligação específica precisa de comportamento de referrer diferente, usa o atributo referrerpolicy em <a> ou <img>:

<a href="https://partner.example.com/" referrerpolicy="no-referrer">Partner</a>

Audita por ti:

curl -sI https://teudominio.com/ | grep -i referrer-policy

Espera uma única linha com a política escolhida. Se o grep não retorna nada, o cabeçalho está em falta.

Perguntas frequentes

Isto vai partir o meu analytics?

Não, desde que o teu analytics seja same-origin (a correr no teu domínio) ou self-hosted. Ferramentas de analytics cross-origin que dependem de URLs de referrer completos (algumas ferramentas de atribuição) podem ver menos dados com strict-origin-when-cross-origin, mas continuam a receber a origem — normalmente suficiente para atribuir a visita.

Devo usar no-referrer para máxima segurança?

no-referrer é o mais seguro mas parte muitos fluxos legítimos: gateways de pagamento muitas vezes verificam o referrer para confirmar que um checkout teve origem num site de comerciante real; fornecedores OAuth por vezes registam o referrer para deteção de fraude; o analytics parte. strict-origin-when-cross-origin é o padrão correto.

Isto afeta o SEO?

Não. Os motores de busca não lêem o referrer policy. O cabeçalho só afeta cliques de saída e carregamento de recursos. Para SEO é neutro; para privacidade é uma melhoria significativa.