Já enfrentou um erro "Referrer header is missing" ao depurar uma requisição cross-origin? Ou pior: decsobriu que dados sensíveis de usuários foram enviados para uma API de terceiros sem seu controle? Provavelmente o problema não está na lógica, mas em um parâmetro subestimado do Fetch API: referrerPolicy. Esse campo define como o cabeçalho Referer será enviado ou ocultado, impactando diretamente a privacidade dos dados. Vamos explorar detalhes técnicos e práticos para evitar vazamentos.

1. Entendendo o conceito: o que é referrerPolicy?

Antes de tudo, corrija um equívoco comum: no Fetch API não existe uma propriedade "referrer" (a menos que você esteja usando XMLHttpRequest, que tem setRequestHeader). O correto é referrerPolicy, que controla o comportamento do cabeçalho Referer. Ele informa ao navegador se deve ou não enviar a URL atual para o servidor de destino.

A importância? O Referer é usado por serviços de analytics, CDNs e APIs para identificar a origem da requisição. Mas uma configuração inadequada pode expor dados sensíveis, como tokens em URLs de login.

// Exemplo básico:
fetch('https://api.example.com/data', {
  referrerPolicy: 'no-referrer' // Bloqueia envio do cabeçalho
});

2. Os 8 valores do referrerPolicy: da segurança total ao risco extremo

A especificação define oito opções, mas cinco são mais comuns em aplicações reais. Veja uma análise comparativa:

Atenção: O valor unsafe-url é perigoso. Um exemplo real: uma aplicação de login que enviava tokens de autenticação em query strings para uma API de terceiros, resultando em vazamento de dados. Evite a todo custo.

3. Casos práticos: quando usar cada configuração

3.1 API de pagamento – segurança absoluta

// Erro comum: usar o padrão do navegador
fetch('https://payment-gateway.com/charge', { method: 'POST' });

// Correto: bloquear referrer
fetch('https://payment-gateway.com/charge', {
  method: 'POST',
  referrerPolicy: 'no-referrer'
});

Por quê? Uma URL de pagamento pode conter ?order_id=12345 ou ?token=abc. Com no-referrer, esses dados não vazam para terceiros.

3.2 API de mapas – equilíbrio entre privacidade e funcionalidade

fetch('https://maps-api.com/coordinates', {
  referrerPolicy: 'origin-when-cross-origin'
});

Nesse caso, o serviço de mapas precisa saber o domínio de origem (para analytics), mas não o caminho exato da página (ex: /checkout/payment).

3.3 Sistema corporativo – padrão restrito

fetch('https://internal-api.company.com/sync', {
  referrerPolicy: 'strict-origin-when-cross-origin'
});

Essa configuração garante que apenas conexões HTTPS enviem informações de origem, evitando vazamentos em páginas HTTP internas.

4. Três armadilhas comuns (e como evitá-las)

• Nunca use unsafe-url em produção: expõe query strings, cookies em URL e até tokens de autenticação. Se precisar de análise de tráfego, prefira origin.
• O padrão do navegador não é seguro: no-referrer-when-downgrade permite envio de referrer em conexões HTTPS→HTTP. Se sua página está em HTTPS e a API em HTTP, o cabeçalho será enviado. Sobrescreva com strict-origin-when-cross-origin.
• Não confunda com CORS: CORS controla permissões de acesso (ex: Access-Control-Allow-Origin), mas não bloqueia o envio do cabeçalho Referer. Mesmo com CORS configurado, um unsafe-url continua vazando dados.

5. Recomendações finais

Trate referrerPolicy como um requisito obrigatório, assim como Content-Type ou Authorization:

• Padrão seguro: no-referrer para dados críticos; strict-origin-when-cross-origin para a maioria dos casos.
• Escolha por contexto: use same-origin para chamadas internas e origin-when-cross-origin para APIs externas que exigem origem.
• Elimine unsafe-url do seu código: substitua por opções mais restritivas.

Pequenas configurações como essa fazem a diferença antre um sistema seguro e uma vulnerabilidade evitável. Aplique essas práticas e evite dores de cabeça futuras.