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

Maud Nalpas

Esta página descreve algumas práticas recomendadas para definir a política de referenciador e usar o referenciador em solicitações recebidas.

Resumo

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

Noções básicas sobre o referenciador e a política de referenciador

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

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 sub-recursos, quando um navegador solicita imagens, iframes, scripts e outros recursos de que uma página precisa.

Para navegações e iframes, também é possível 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á-los 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, ele pode colocar em risco a privacidade do usuário e criar riscos de segurança:

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

O URL 6 é um URL de capacidade. Se qualquer pessoa que não seja o usuário pretendido receber isso, um agente malicioso poderá assumir o controle da conta desse usuário.

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

Quais políticas estão disponíveis e como elas diferem?

É 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 a origem
• O URL completo: origem, caminho e string de consulta

Algumas políticas são projetadas para se comportar de maneira diferente, dependendo do contexto: solicitação entre origens ou de 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 de referenciador restringem os dados de URL disponíveis no cabeçalho de referenciador e document.referrer:

A MDN oferece uma lista completa de políticas e exemplos de comportamento exemplos.

Confira algumas coisas a serem consideradas 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 as solicitações de uma origem HTTP para outra origem HTTP da mesma forma que as solicitações de uma origem HTTPS para outra origem HTTPS, mesmo que o HTTP seja menos seguro. Isso ocorre 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 é totalmente não criptografada, então não há downgrade.
• Se uma solicitação for de mesma origem, isso significa que o esquema (HTTPS ou HTTP) é o mesmo, então não há downgrade de segurança.

Políticas de referenciador padrão em navegadores

Em outubro de 2021

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

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

Há diferentes maneiras de definir políticas de referenciador para seu site:

• Como um cabeçalho HTTP
• No seu HTML
• Do 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 eficaz 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 dessa página seguem a política strict-origin-when-cross-origin.

Como conferir a política de referenciador?

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

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

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

Recomendamos definir explicitamente uma política que melhore a privacidade, como strict-origin-when-cross-origin (ou mais restrita).

Por que "explicitamente"?

Se você não definir uma política de referenciador, a política padrão do navegador será usada. Na verdade, os sites costumam adiar para o padrão do navegador. No entanto, isso não é o ideal, porque:

• Navegadores diferentes têm políticas padrão diferentes. Portanto, se você confiar nos padrões do navegador, seu site não se comportará de maneira previsível em todos os navegadores.
• Os navegadores estão adotando padrões mais rigorosos, como strict-origin-when-cross-origin e mecanismos como o corte de referenciador para solicitações entre origens. A opção explícita por uma política que melhore a privacidade antes que os padrões do navegador mudem oferece controle e ajuda a executar testes conforme necessário.

Por que strict-origin-when-cross-origin (ou mais restrita)?

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

• Seguro: se o site usar HTTPS (se não, priorize isso), você não vai querer que os URLs do seu site vazem em solicitações não HTTPS. Como qualquer pessoa na rede pode vê-los, os vazamentos exporiam seus usuários a ataques man-in-the-middle. As políticas no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer, e strict-origin resolvem esse problema.
• Melhoria da privacidade: para uma solicitação entre origens, 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 você com strict-origin-when-cross-origin, strict-origin e no-referrer como opções que melhoram a 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 sensata.

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 strict-origin-when-cross-origin (ou mais restrita) não acomodar todos os seus casos de uso?

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

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 os detalhes.

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

script.js:

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

O que mais você deve considerar?

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

Práticas recomendadas para solicitações recebidas

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

Proteger os dados dos usuários

O Referer pode conter dados particulares, pessoais ou de identificação. Portanto, trate-o como tal.

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

O uso do referenciador de solicitações entre origens 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) que receber. O emissor da solicitação pode decidir mudar para uma política no-referrer a qualquer momento ou, de maneira mais geral, para uma política mais rigorosa do que a usada anteriormente. 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 você pode receber apenas a origem, em vez de um URL de referenciador completo, em solicitações entre origens recebidas, se o site do remetente não tiver uma política definida.
• Os navegadores podem mudar a maneira como gerenciam o Referer. Por exemplo, alguns desenvolvedores de navegadores podem decidir sempre cortar referenciadores para origens em solicitações de sub-recursos entre origens, para proteger a privacidade do usuário.
• O cabeçalho Referer (e document.referrer) pode conter mais dados do que você precisa. Por exemplo, ele pode ter um URL completo quando você só quer saber se a solicitação é entre origens.

Alternativas ao Referer

Talvez seja necessário considerar alternativas se:

• Um recurso essencial do seu site usa o URL de referenciador de solicitações entre origens recebidas.
• Seu site não está mais recebendo a parte do URL de referenciador de que precisa em uma solicitação entre origens. Isso acontece quando o emissor da solicitação muda a política ou quando não tem uma política definida e a política padrão do navegador muda (como no Chrome 85).

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

Se você precisar apenas da origem

• Se você estiver usando o referenciador em um script que tenha acesso de nível superior à página, window.location.origin será uma alternativa.
• Se disponíveis, cabeçalhos como Origin e Sec-Fetch-Site fornecem a Origin ou descrevem se a solicitação é entre origens, 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 resolver seu caso de uso, o que economiza o trabalho de analisar o referenciador.
• Se você estiver usando o referenciador em um script que tenha acesso de nível superior à página, window.location.pathname poderá funcionar como uma alternativa. Extraia apenas a seção de caminho do URL e transmita-a como um argumento. Assim, nenhuma informação potencialmente sensível nos parâmetros do URL será transmitida.

Se você não puder usar essas alternativas:

• Verifique se é possível mudar seus sistemas para esperar que o emissor da 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 preservação da privacidade para usuários de site-one.example, mais preparado para o futuro.
  • Contras: potencialmente mais trabalho da sua parte ou para os usuários do seu sistema.
• Verifique se o site que emite as solicitações pode concordar em definir uma política de referenciador por elemento ou por solicitação de no-referrer-when-downgrade.
  • Contras: potencialmente menos preservação da privacidade para usuários de site-one.example, potencialmente não compatível com todos os navegadores.

Proteção contra falsificação de solicitação 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 sua proteção principal. Para mais proteção, use SameSite e 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 é possível usar o Origin cabeçalho como uma alternativa. Isso pode fornecer as informações necessárias para fins de depuração de uma maneira mais simples e sem precisar analisar o referenciador.

Pagamentos

Os provedores de pagamento podem confiar no cabeçalho Referer de solicitações recebidas para verificações de segurança.

Por exemplo:

• O usuário clica em um botão Comprar em 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 uma lista de valores 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 um comerciante legítimo ou não, pode definir uma política no-referrer que torna as informações 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 no-referrer. Se você usar o Referer como uma primeira verificação:

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

Para verificar pagamentos de maneira mais confiável, permita que o solicitante gere o hash dos parâmetros da solicitação com uma chave exclusiva. Os provedores de pagamento podem calcular o mesmo hash do seu lado e aceitar a solicitação somente se ela corresponder ao seu 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 fica visível na solicitação ao 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 mudança do Chrome para uma nova política padrão não vai alterar esse comportamento.

Conclusão

Uma política de referenciador protetora é uma ótima maneira de oferecer mais privacidade aos usuários.

Para saber mais sobre diferentes técnicas para proteger seus usuários, consulte nossa Segura e protegida coleção

Recursos

• Entender "mesmo site" e "mesma origem"
• Um novo cabeçalho de segurança: política de referenciador (2017)
• Política de referenciador na MDN (link em inglês)
• Cabeçalho de referenciador: preocupações com privacidade e segurança na MDN (link em inglês)
• Mudança do Chrome: intenção do Blink de implementar (link em inglês)
• Mudança do Chrome: intenção do Blink de enviar (link em inglês)
• Mudança do Chrome: entrada de status (link em inglês)
• Mudança do Chrome: postagem no blog da versão Beta 85 (link em inglês)
• Thread do GitHub sobre o corte de referenciador: o que diferentes navegadores fazem (link em inglês)
• Especificação da política de referenciador (link em inglês)

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