Práticas recomendadas para referências e políticas de referenciadores

Nesta página, descrevemos algumas práticas recomendadas para definir a política do referenciador e usar o referenciador em solicitações recebidas.

Resumo

• O vazamento inesperado de informações de origem cruzada prejudica a privacidade dos usuários da Web. Uma política de proteção de referenciador pode ajudar.
• Defina uma política de referenciador de strict-origin-when-cross-origin. Ela preserva a maior parte da utilidade do referenciador e reduz o risco de vazamento de dados entre origens cruzadas.
• Não use referenciadores para a proteção contra falsificação de solicitações entre sites (CSRF, na sigla em inglês). Em vez disso, use tokens CSRF e outros cabeçalhos como uma camada extra de segurança.

Referência e política de referenciadores

As solicitações HTTP podem incluir um cabeçalho Referer opcional, que indica a origem ou o URL da página da Web em que a solicitação foi feita. O cabeçalho Referrer-Policy define quais dados são disponibilizados no cabeçalho Referer.

No exemplo a seguir, o cabeçalho Referer inclui o URL completo da página em site-one de onde a solicitação foi feita.

O cabeçalho Referer pode estar presente em diferentes tipos de solicitações:

• Solicitações de navegação, quando um usuário clica em um link.
• Solicitações de recursos secundários, quando um navegador solicita imagens, iframes, scripts e outros recursos necessários para uma página.

Para navegações e iframes, você também pode acessar esses dados com JavaScript usando document.referrer.

É possível aprender muito com os valores de Referer. Por exemplo, um serviço de análise pode usá-las para determinar que 50% dos visitantes em site-two.example vieram de social-network.example. No entanto, quando o URL completo, incluindo o caminho e a string de consulta, é enviado no Referer entre origens, isso pode colocar em risco a privacidade do usuário e criar riscos de segurança:

Os URLs 1 a 5 contêm informações particulares e, às vezes, informações confidenciais ou de identificação. O vazamento silenciosamente das origens pode comprometer a privacidade dos usuários da Web.

O URL 6 é um URL de recurso. Se alguém além do usuário pretendido receber a mensagem, um usuário mal-intencionado pode assumir o controle da conta.

Para restringir quais dados do referenciador são disponibilizados para solicitações do seu site, defina uma política de referenciador.

Quais políticas estão disponíveis e quais as diferenças entre elas?

É possível selecionar uma das oito políticas. Dependendo da política, os dados disponíveis no cabeçalho Referer (e document.referrer) podem ser:

• Nenhum dado (nenhum cabeçalho Referer está presente)
• Apenas o valor origin
• URL completo: origem, caminho e string de consulta

Algumas políticas foram projetadas para se comportarem de maneira diferente dependendo do contexto: solicitação de origem cruzada ou da mesma origem, se o destino da solicitação é tão seguro quanto a origem ou ambos. Isso é útil para limitar a quantidade de informações compartilhadas entre origens ou para origens menos seguras, mantendo a riqueza do referenciador no seu próprio site.

A tabela a seguir mostra como as políticas do referenciador restringem os dados de URL disponíveis no cabeçalho Referer e no document.referrer:

Escopo da política	Nome da política	Referenciador: sem dados	Referenciador: somente origem	Referenciador: URL completo
Não considera o contexto da solicitação	no-referrer	cheque
	origin		cheque
	unsafe-url			cheque
Foco em segurança	strict-origin	Solicitação de HTTPS para HTTP	Solicitação de HTTPS para HTTPS ou de HTTP para HTTP
	no-referrer-when-downgrade	Solicitação de HTTPS para HTTP		Solicitação de HTTPS para HTTPS ou de HTTP para HTTP
Foco na privacidade	origin-when-cross-origin		Solicitação de origem cruzada	Solicitação de mesma origem
	same-origin	Solicitação de origem cruzada		Solicitação de mesma origem
Foco em privacidade e segurança	strict-origin-when-cross-origin	Solicitação de HTTPS para HTTP	Solicitação de origem cruzada de HTTPS para HTTPS ou HTTP para HTTP	Solicitação de mesma origem

O MDN fornece uma lista completa de políticas e exemplos de comportamento.

Veja alguns pontos a serem considerados ao definir uma política de referenciador:

• Todas as políticas que consideram o esquema (HTTPS versus HTTP) (strict-origin, no-referrer-when-downgrade e strict-origin-when-cross-origin) tratam solicitações de uma origem HTTP para outra origem HTTP da mesma forma que solicitações de uma origem HTTPS para outra origem HTTPS, mesmo que o HTTP seja menos seguro. Isso porque, para essas políticas, o que importa é se ocorre um downgrade de segurança, ou seja, se a solicitação pode expor dados de uma origem criptografada para uma não criptografada, como em solicitações HTTPS → HTTP. Uma solicitação HTTP → HTTP não está criptografada, então não há downgrade.
• Se uma solicitação tiver a mesma origem, isso significa que o esquema (HTTPS ou HTTP) é o mesmo, e não há downgrade de segurança.

Políticas de referenciador padrão em navegadores

Em outubro de 2021

Se nenhuma política do referenciador for definida, o navegador usará a política padrão.

Práticas recomendadas para definir a política do referenciador

Há formas diferentes de definir políticas de referenciadores para seu site:

• Como um cabeçalho HTTP
• No seu HTML
• Usando JavaScript por solicitação

É possível definir políticas diferentes para páginas, solicitações ou elementos diferentes.

O cabeçalho HTTP e o elemento meta estão no nível da página. A ordem de prioridade para determinar a política efetiva de um elemento é a seguinte:

1. Política no nível do elemento
2. Política no nível da página
3. Padrão do navegador

Exemplo:

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />

A imagem é solicitada com uma política no-referrer-when-downgrade, e todas as outras solicitações de sub-recursos desta página seguem a strict-origin-when-cross-origin.

Como ver a política do referenciador?

securityheaders.com é útil para determinar qual política uma página ou um site específico está usando.

Também é possível usar as ferramentas para desenvolvedores no Chrome, Edge ou Firefox para conferir a política do referenciador usada para uma solicitação específica. No momento em que este artigo foi escrito, o Safari não mostrava o cabeçalho Referrer-Policy, mas mostra o Referer que foi enviado.

Qual política você deve definir para seu site?

É altamente recomendável definir explicitamente uma política de melhoria de privacidade, como strict-origin-when-cross-origin (ou mais rigorosa).

Por que "explicitamente"?

Se você não definir uma política do referenciador, a política padrão do navegador será usada. Na verdade, os sites geralmente adotam o padrão do navegador. Mas isso não é o ideal, porque:

• Navegadores diferentes têm políticas padrão distintas. Portanto, se você usa os padrões do navegador, seu site não se comportará de maneira previsível em todos eles.
• Os navegadores estão adotando padrões mais rigorosos, como strict-origin-when-cross-origin, e mecanismos como o corte do referenciador para solicitações de origem cruzada. A ativação explícita de uma política de melhoria de privacidade antes da mudança nos padrões do navegador oferece controle e ajuda você a executar testes conforme achar necessário.

Por que strict-origin-when-cross-origin (ou uma opção mais rigorosa)?

Você precisa de uma política segura, que aprimore a privacidade e útil. O que significa "útil" depende do que você quer do referenciador:

• Seguro: se o site usa HTTPS (se não for, defina-o como uma prioridade), você não quer que os URLs do site vazem em solicitações não HTTPS. Como qualquer pessoa na rede tem acesso a esses dados, os vazamentos expõem seus usuários a ataques "person-in-the-middle". As políticas no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer e strict-origin resolvem esse problema.
• Melhoria de privacidade: para uma solicitação de origem cruzada, o no-referrer-when-downgrade compartilha o URL completo, o que pode causar problemas de privacidade. strict-origin-when-cross-origin e strict-origin compartilham apenas a origem, e no-referrer não compartilha nada. Isso deixa com strict-origin-when-cross-origin, strict-origin e no-referrer como opções de melhoria de privacidade.
• Útil: no-referrer e strict-origin nunca compartilham o URL completo, mesmo para solicitações de mesma origem. Se você precisar do URL completo, strict-origin-when-cross-origin é uma opção melhor.

Tudo isso significa que strict-origin-when-cross-origin geralmente é uma escolha adequada.

Exemplo: como definir uma política strict-origin-when-cross-origin

index.html:

<meta name="referrer" content="strict-origin-when-cross-origin" />

Ou no lado do servidor, por exemplo no Express:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

E se a strict-origin-when-cross-origin (ou uma configuração mais rigorosa) não puder acomodar todos os seus casos de uso?

Nesse caso, adote uma abordagem progressiva: defina uma política de proteção como strict-origin-when-cross-origin para o site e, se necessário, uma política mais permissiva para solicitações específicas ou elementos HTML.

Exemplo: política no nível do elemento

index.html:

<head>
  <!-- document-level policy: strict-origin-when-cross-origin -->
  <meta name="referrer" content="strict-origin-when-cross-origin" />
  <head>
    <body>
      <!-- policy on this <a> element: no-referrer-when-downgrade -->
      <a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
      <body></body>
    </body>
  </head>
</head>

O Safari/WebKit pode limitar document.referrer ou o cabeçalho Referer para solicitações entre sites. Confira mais detalhes.

Exemplo: política no nível da solicitação

script.js:

fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});

O que mais você deveria considerar?

Sua política precisa depender do site e dos casos de uso, conforme determinado por você, sua equipe e sua empresa. Se alguns URLs tiverem dados sensíveis ou de identificação, defina uma política de proteção.

Práticas recomendadas para solicitações recebidas

Veja algumas diretrizes sobre o que fazer se seu site usar o URL referenciador de solicitações recebidas.

Proteja os dados dos usuários

O Referer pode conter dados particulares, pessoais ou de identificação. Portanto, trate isso dessa maneira.

Os referenciadores recebidos podem mudar {referer-can-change}

O uso do referenciador de solicitações de origem cruzada recebidas tem algumas limitações:

• Se você não tiver controle sobre a implementação do emissor da solicitação, não poderá fazer suposições sobre o cabeçalho Referer (e document.referrer) recebido. O emissor de solicitação pode mudar para uma política no-referrer a qualquer momento ou, de forma mais geral, para uma política mais rigorosa do que a usada antes. Isso significa que você recebe menos dados do Referer do que antes.
• Os navegadores usam cada vez mais a política de referenciador strict-origin-when-cross-origin por padrão. Isso significa que agora você poderá receber apenas a origem, em vez de um URL referenciador completo, em solicitações de origem cruzada recebidas se o site remetente não tiver uma política definida.
• Os navegadores podem mudar a forma como gerenciam o Referer. Por exemplo, alguns desenvolvedores de navegador podem decidir sempre cortar os referenciadores de origens em solicitações de sub-recursos de origem cruzada para proteger a privacidade do usuário.
• O cabeçalho Referer (e document.referrer) pode conter mais dados do que o necessário. Por exemplo, ele pode ter um URL completo quando você só quer saber se a solicitação é de origem cruzada.

Alternativas a Referer

Talvez seja necessário considerar alternativas se:

• Um recurso essencial do seu site usa o URL do referenciador das solicitações de origem cruzada recebidas.
• Seu site não recebe mais a parte do URL do referenciador necessária em uma solicitação de origem cruzada. Isso acontece quando o emissor da solicitação muda a política ou quando não há uma política definida e a política padrão do navegador é alterada, como no Chrome 85.

Para definir alternativas, primeiro analise qual parte do referenciador você está usando.

Se você só precisa da origem

• Se você estiver usando o referenciador em um script com acesso de nível superior à página, o window.location.origin será uma alternativa.
• Se disponíveis, cabeçalhos como Origin e Sec-Fetch-Site fornecem o Origin ou descrevem se a solicitação é de origem cruzada, o que pode ser exatamente o que você precisa.

Se você precisar de outros elementos do URL (caminho, parâmetros de consulta etc.)

• Os parâmetros de solicitação podem abordar seu caso de uso, o que economiza o trabalho de análise do referenciador.
• Se você estiver usando o referenciador em um script com acesso de nível superior à página, window.location.pathname poderá funcionar como alternativa. Extraia apenas a seção do caminho do URL e transmita-a como um argumento para que qualquer informação potencialmente sensível nos parâmetros de URL não seja transmitida.

Se não for possível usar essas alternativas, faça o seguinte:

• Verifique se é possível alterar seus sistemas para esperar que o emissor de solicitação (por exemplo, site-one.example) defina explicitamente as informações necessárias em algum tipo de configuração.
  • Pró: mais explícito, mais que preserva a privacidade para os usuários do site-one.example, mais preparado para o futuro.
  • Desvantagem: possivelmente mais trabalho da sua parte ou para os usuários do sistema.
• Confira se o site que emite as solicitações pode concordar em definir uma política do referenciador por elemento ou por solicitação de no-referrer-when-downgrade.
  • Desvantagem: possivelmente menos preservar a privacidade para usuários site-one.example, possivelmente não compatível com todos os navegadores.

Proteção contra falsificação de solicitações entre sites (CSRF, na sigla em inglês)

Um emissor de solicitação sempre pode decidir não enviar o referenciador definindo uma política no-referrer, e um agente malicioso pode até mesmo falsificar o referenciador.

Use tokens CSRF como proteção principal. Para ter mais proteção, use o SameSite. Em vez de Referer, use cabeçalhos como Origin (disponível em solicitações POST e CORS) e Sec-Fetch-Site, se disponível.

Registrar e depurar

Proteja os dados pessoais ou sensíveis dos usuários que possam estar no Referer.

Se você estiver usando apenas a origem, verifique se pode usar o cabeçalho Origin como alternativa. Isso pode fornecer as informações necessárias para fins de depuração de uma maneira mais simples e sem a necessidade de analisar o referenciador.

Pagamentos

Os provedores de pagamento podem depender do cabeçalho Referer das solicitações recebidas para verificações de segurança.

Exemplo:

• O usuário clica no botão Comprar no online-shop.example/cart/checkout.
• online-shop.example redireciona para payment-provider.example para gerenciar a transação.
• payment-provider.example verifica o Referer dessa solicitação em relação a uma lista de valores de Referer permitidos configurados pelos comerciantes. Se não corresponder a nenhuma entrada na lista, payment-provider.example rejeitará a solicitação. Se houver correspondência, o usuário poderá prosseguir para a transação.

Práticas recomendadas para verificações de segurança do fluxo de pagamento

Como provedor de pagamento, você pode usar o Referer como uma verificação básica contra alguns ataques. No entanto, o cabeçalho Referer por si só não é uma base confiável para uma verificação. O site solicitante, seja ele um comerciante legítimo ou não, pode definir uma política no-referrer que torne as informações de Referer indisponíveis para o provedor de pagamento.

Analisar o Referer pode ajudar os provedores de pagamento a detectar invasores ingênuos que não definiram uma política de no-referrer. Se você usar Referer como primeira verificação:

• Não espere que o Referer esteja sempre presente. Se estiver presente, verifique apenas os dados mínimos que podem ser incluídos, que são a origem.
  • Ao definir a lista de valores de Referer permitidos, inclua apenas a origem e nenhum caminho.
  • Por exemplo, os valores permitidos de Referer para online-shop.example precisam ser online-shop.example, não online-shop.example/cart/checkout. Ao esperar nenhum valor de Referer ou um valor de Referer que seja apenas a origem do site solicitante, você evita erros que podem resultar de suposições sobre Referrer-Policy do comerciante.
• Se a Referer estiver ausente ou se estiver presente e a verificação básica de origem da Referer for bem-sucedida, você poderá usar outro método de verificação mais confiável.

Para verificar pagamentos de maneira mais confiável, permita que o solicitante faça hash dos parâmetros da solicitação com uma chave exclusiva. Os provedores de pagamento podem calcular o mesmo hash e só aceitar a solicitação se ela corresponder ao cálculo.

O que acontece com o Referer quando um site de comerciante HTTP sem política de referenciador redireciona para um provedor de pagamento HTTPS?

Nenhum Referer está visível na solicitação para o provedor de pagamento HTTPS porque a maioria dos navegadores usa strict-origin-when-cross-origin ou no-referrer-when-downgrade por padrão quando um site não tem uma política definida. A alteração do Chrome para uma nova política padrão não mudará esse comportamento.

Conclusão

Uma política de referenciador protetor é uma ótima maneira de dar mais privacidade aos seus usuários.

Para saber mais sobre diferentes técnicas para proteger seus usuários, consulte nossa coleção Segurança e proteção.

Recursos

• O que são "same-site" e "same-origin"
• Um novo cabeçalho de segurança: política do referenciador (2017)
• Política de referenciadores no MDN
• Cabeçalho de referência: preocupações com privacidade e segurança no MDN
• Mudança do Chrome: pisque a intent para implementar
• Mudança do Chrome: piscar intent para enviar
• Alteração no Chrome: entrada de status
• Mudança no Chrome: postagem do blog sobre a versão 85 Beta (em inglês)
• Corte de referência da linha de execução do GitHub: o que diferentes navegadores fazem (link em inglês)
• Especificação da política do referenciador

Agradecemos muito as contribuições e o feedback a todos os revisores, especialmente Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck e Kayce Basques.