Como configurar Referrer-Policy em um site criado por IA — Blog

Quando alguém sai de um site criado por IA, carrega um recurso externo ou chama uma integração, o navegador pode enviar o header HTTP Referer. Dependendo da política ativa, o destino recebe a URL completa, apenas a origem ou nenhuma informação de referência.

Esse detalhe afeta privacidade, logs, Analytics, antifraude e integrações que usam a origem da visita como sinal. Uma política restritiva demais pode remover atribuição necessária; uma política permissiva pode expor caminhos e parâmetros que nunca deveriam sair do site.

Referrer-Policy permite declarar a fronteira. Este guia mostra como escolher uma política, aplicá-la no HTML ou na resposta, testar navegação e recursos e verificar a versão publicada.

Diferencie os dois nomes

O header enviado na requisição usa a grafia histórica Referer, com um único r no meio. O mecanismo que controla esse envio usa a grafia correta:

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

Não tente definir manualmente o valor de Referer no frontend. O navegador calcula a informação permitida com base no contexto, na URL, na política e em regras de Fetch.

A especificação Referrer Policy do W3C define as políticas e os mecanismos de entrega. A referência da MDN documenta o comportamento atual e registra strict-origin-when-cross-origin como padrão quando nenhuma política válida é declarada.

Mesmo assim, declare a intenção explicitamente. O padrão do navegador não substitui a decisão de produto nem documenta dependências de atribuição.

Descubra o que a URL pode revelar

Antes de escolher um valor, inventarie rotas e saídas:

rg -n \
  'Referrer-Policy|name=["'"']referrer|referrerpolicy=|fetch\(|<a |<img|<script|<iframe|url.searchParams' \
  src public

Revise especialmente URLs com:

termos de busca;
identificadores internos;
nomes de campanha;
e-mails ou outros dados pessoais;
tokens, códigos ou links de convite;
filtros que revelam contexto de negócio;
caminhos de área autenticada;
parâmetros gerados por terceiros.

A política não corrige dados sensíveis colocados na URL. Remova segredos e informações pessoais do endereço antes de tratar o referrer. Fragmentos não são enviados como referrer, mas isso também não transforma o fragmento em cofre para credenciais.

Mapeie consumidores legítimos:

destino:
mesma origem ou outra origem:
precisa da URL completa:
precisa apenas da origem:
pode funcionar sem Referer:
uso em Analytics, antifraude ou suporte:
dados potencialmente expostos:
política mínima suficiente:

Escolha a política pelo dado necessário

As opções mais úteis para uma landing moderna são:

Política	Mesma origem	Outra origem HTTPS	HTTPS para HTTP
`strict-origin-when-cross-origin`	URL permitida	somente origem	nada
`strict-origin`	somente origem	somente origem	nada
`same-origin`	URL permitida	nada	nada
`no-referrer`	nada	nada	nada

strict-origin-when-cross-origin costuma equilibrar navegação interna e atribuição cross-origin sem enviar caminho e query para outro site. Use esse comportamento como ponto de comparação, não como resposta automática.

Escolha same-origin quando destinos externos não precisam saber de qual origem a visita veio. Escolha no-referrer quando nenhuma referência deve sair, entendendo o impacto em métricas e integrações. strict-origin preserva a origem em destinos seguros, mas evita URL completa inclusive dentro da mesma origem.

Evite unsafe-url: ela pode enviar origem, caminho e query inclusive em situações nas quais essa exposição não é necessária. Não relaxe a política só para recuperar um relatório; confirme qual dado a ferramenta realmente exige.

Aplique uma política para a página inteira

Quando a camada que serve a resposta permite headers, prefira:

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

Em um artefato estático sem controle de headers, use uma meta tag no início do head:

<head>
  <meta name="referrer" content="strict-origin-when-cross-origin" />
  <!-- demais metadados -->
</head>

Coloque a política antes de recursos que possam disparar requisições. Assim, scripts, imagens e outros elementos posteriores herdam a decisão do documento.

Não mantenha valores diferentes em header e meta sem necessidade. A política efetiva depende dos mecanismos aplicáveis e pode ficar difícil de auditar. Defina uma fonte de verdade e teste a resposta final.

O contrato atual de Publicação envia os arquivos estáticos preparados pelo projeto. Um arquivo _headers dentro do pacote não é convertido automaticamente em headers HTTP. Portanto, a presença desse arquivo não prova que Referrer-Policy foi entregue. Quando o controle precisa viajar no próprio pacote, a meta tag é a opção verificável para o documento.

Use exceções por elemento com parcimônia

Alguns elementos aceitam referrerpolicy:

<a href="https://parceiro.exemplo/oferta" referrerpolicy="no-referrer"> Ver oferta </a>

O atributo também existe em recursos como img, script, iframe e link. Ele pode tornar uma requisição específica mais restritiva do que a regra geral.

Não espalhe exceções para compensar uma política global mal escolhida. Cada valor local precisa de um motivo:

link para destino que não deve receber atribuição;
imagem externa cujo fornecedor não precisa conhecer a origem;
frame com contrato de privacidade próprio;
script ou recurso com requisitos documentados.

rel="noreferrer" em um link também omite a referência e implica proteção de opener, mas tem semântica própria. Não adicione noreferrer a todos os links apenas para resolver Referrer-Policy. O guia de reverse tabnabbing separa essa decisão da proteção de janelas.

Preserve atribuição sem enviar detalhes

Campanhas e parceiros podem precisar saber que uma visita veio do seu domínio, mas raramente precisam receber o caminho completo com query. strict-origin-when-cross-origin ou strict-origin preserva a origem em navegações HTTPS cross-origin.

Se uma integração exige uma URL detalhada no Referer, pergunte:

qual decisão depende desse dado;
se um identificador de campanha explícito resolve;
se a informação pode ser enviada pelo backend;
por quanto tempo o destino armazena o log;
quais redirects e subfornecedores recebem o valor;
como a ausência do header é tratada.

Não use Referer como autenticação ou autorização. O header pode ser omitido por política, navegador, extensão, proxy ou configuração da pessoa. Uma integração crítica deve validar credenciais e estado por mecanismos próprios.

O guia de scripts de terceiros ajuda a inventariar fornecedores que recebem requisições a partir da página.

Teste navegações, recursos e redirects

Crie destinos de teste sob seu controle e registre apenas método, origem e Referer. Não envie URLs sensíveis para serviços públicos de inspeção.

Monte uma matriz:

Requisição	Evidência esperada
navegação para rota da mesma origem	valor conforme a regra same-origin
link para outra origem HTTPS	origem ou nada, conforme a política
imagem ou script externo	valor coerente com documento e exceção local
iframe externo	política aplicada ao carregamento do frame
redirect entre origens	nenhum detalhe além do permitido em cada etapa
destino HTTP a partir de HTTPS	nenhuma referência nas políticas estritas

No DevTools, abra Network, selecione a requisição e inspecione Request Headers. Confira também os logs do endpoint controlado para distinguir o que a interface exibe do que chegou ao servidor.

Teste ausência. Uma política que funciona apenas quando Referer está presente cria uma dependência frágil. Repita com navegação direta e com uma política local mais restritiva.

Verifique a URL publicada e os domínios próprios

Antes de publicar:

remova dados sensíveis das URLs;
escolha a política pelo menor dado necessário;
aplique header ou meta tag suportada;
documente exceções por elemento;
teste recursos, links e redirects;
valide Analytics e integrações sem transformar referrer em credencial.

Depois de publicar, inspecione o documento:

curl -sS -D - -o /dev/null https://exemplo.sitenoar.app \
  | rg -i '^referrer-policy:'

Se o controle estiver em meta, confira o HTML e o comportamento no navegador:

curl -sS https://exemplo.sitenoar.app \
  | rg -i '<meta[^>]+name=["'"']referrer["'"']'

Repita na URL padrão e em cada domínio próprio ativo. A origem enviada muda com esquema, host e porta; um domínio adicional pode alterar atribuição e allowlists de parceiros.

Se a política ou as URLs forem corrigidas, gere uma nova versão e republique o mesmo Site. Registre a evidência da versão pública, não apenas a configuração na fonte.

Prompt copiável para o agente

Revise e proponha uma Referrer-Policy para este site antes de publicar.

Pasta publicável: [caminho]
URL de teste: [URL]
Domínios finais: [lista]
Integrações e Analytics: [lista]

- Inventarie URLs, links, recursos externos, iframes e redirects.
- Remova segredos e dados pessoais de caminhos e queries.
- Identifique quem precisa da URL completa, apenas da origem ou de nada.
- Compare strict-origin-when-cross-origin, strict-origin, same-origin e no-referrer.
- Não use unsafe-url sem justificativa explícita.
- Aplique uma regra global por header ou meta suportada pelo artefato.
- Documente cada exceção referrerpolicy ou noreferrer.
- Não trate Referer como autenticação ou autorização.
- Teste navegações, recursos, redirects e ausência do header.
- Verifique a URL publicada e cada domínio próprio.
- Entregue política escolhida, impacto em atribuição e evidências.

Checklist final

Uma boa Referrer-Policy não tenta esconder toda navegação nem entregar contexto demais. Ela reduz cada requisição ao sinal que o destino realmente precisa e mantém essa decisão observável depois da publicação.