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 redirecionamento e usar o redirecionador 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 proteção do referenciador pode ajudar.
• Considere definir uma política de referenciador de strict-origin-when-cross-origin. Ele preserva a maior parte da utilidade do referente, reduzindo o risco de vazamento de dados entre origens.
• Não use referências para proteção contra falsificação de solicitações entre sites (CSRF). Use tokens CSRF em vez disso e outros cabeçalhos como uma camada extra de segurança.

Introdução ao Referrer e à política de referência

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 cabeçalho Referer.

No exemplo a seguir, o cabeçalho Referer inclui o URL completo da página em site-one em que 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 subrecurso, 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.

Você pode 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, 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, sensíveis ou de identificação. O vazamento silencioso deles em várias origens pode comprometer a privacidade dos usuários da Web.

O URL no 6 é um URL de recurso. Se alguém diferente do usuário pretendido receber isso, um agente mal-intencionado poderá assumir o controle da conta desse usuário.

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

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

Você pode 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)
• Somente o parâmetro origin
• 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 de mesma origem ou entre origens, 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 do cabeçalho de referenciador e document.referrer:

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

Confira alguns pontos a serem considerados ao definir uma política de referrer:

• Todas as políticas que consideram o esquema (HTTPS ou HTTP) (strict-origin, no-referrer-when-downgrade e strict-origin-when-cross-origin) tratam as solicitações de uma origem HTTP para outra da mesma forma que as solicitações de uma origem HTTPS para outra origem HTTPS, embora o HTTP seja menos seguro. Isso ocorre porque, para essas políticas, o que importa é se um downgrade de segurança ocorre, 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 é totalmente criptografada. Portanto, não há downgrade.
• Se uma solicitação for de mesma origem, isso significa que o esquema (HTTPS ou HTTP) será o mesmo, então não haverá downgrade de segurança.

Políticas de referenciador padrão nos navegadores

Desde 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 referenciadores 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 distintos.

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 subrecursos desta página seguem a política strict-origin-when-cross-origin.

Como consultar a política de referenciador?

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

Você também pode usar as ferramentas para desenvolvedores no Chrome, Edge ou Firefox para conferir a política de referrer usada para uma solicitação específica. No momento da criação deste codelab, 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 de melhoria da privacidade, como a strict-origin-when-cross-origin (ou mais rigorosa).

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 geralmente deferem para o padrão do navegador. Mas isso não é ideal porque:

• Navegadores diferentes têm políticas padrão diferentes. Portanto, se você depender dos padrões do navegador, o comportamento do site não será previsível em todos os navegadores.
• Os navegadores estão adotando padrões mais rígidos, como strict-origin-when-cross-origin, e mecanismos como o recorte de referenciador para solicitações de origem cruzada. Ativar explicitamente uma política de melhoria de privacidade antes que as configurações padrão do navegador mudem dá a você controle e ajuda a executar testes como você achar melhor.

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

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

• Seguro: se o site usa HTTPS (se não, priorize isso), você não quer que os URLs do site vazem em solicitações que não sejam HTTPS. Como qualquer pessoa na rede pode ver esses dados, os vazamentos expõem os usuários a ataques de homem-no-meio. As políticas no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer e strict-origin resolvem esse problema.
• Aprimoramento da 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 você com strict-origin-when-cross-origin, strict-origin e no-referrer como opções para melhorar 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 é a melhor opção.

Isso significa que o strict-origin-when-cross-origin é geralmente uma escolha sensata.

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

index.html:

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

Ou do 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 rigoroso) não acomodar todos os 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 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ê precisa considerar?

A política precisa 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 de proteção.

Práticas recomendadas para solicitações recebidas

Confira algumas diretrizes sobre o que fazer se o site usar o URL de referência das solicitações recebidas.

Proteger os dados dos usuários

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

Os referenciadores de entrada podem mudar {referer-can-change}

O uso do referrer de solicitações entre origens diferentes tem algumas limitações:

• Se você não tiver controle sobre a implementação do emissor de solicitações, não poderá fazer suposições sobre o cabeçalho Referer (e document.referrer) que recebe. O emissor da solicitação pode mudar para uma política no-referrer a qualquer momento ou, de modo mais geral, para uma política mais rígida do que a anterior. Isso significa que você recebe menos dados do Referer do que antes.
• Os navegadores usam cada vez mais a strict-origin-when-cross-origin de política de referenciador 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 forma como gerenciam Referer. Por exemplo, alguns desenvolvedores de navegadores podem decidir sempre cortar os remetentes para origens em solicitações de subrecursos entre origens diferentes 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 é entre origens diferentes.

Alternativas a Referer

Talvez seja necessário considerar alternativas se:

• Um recurso essencial do seu site usa o URL de referência de solicitações entre origens diferentes.
• Seu site não recebe mais a parte do URL de referenciador necessária em uma solicitação entre origens. Isso acontece quando o emissor de solicitações 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 referente em um script com acesso de nível superior à página, window.location.origin é uma alternativa.
• Se disponível, cabeçalhos como Origin e Sec-Fetch-Site fornecerão o Origin ou descreverão 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 atender ao seu caso de uso, o que economiza o trabalho de análise do referenciador.
• Se você estiver usando o referrer em um script com acesso de nível superior à página, window.location.pathname pode ser uma alternativa. Extraia apenas a seção do caminho do URL e transmita-a como um argumento para que informações potencialmente sensíveis nos parâmetros de URL não sejam transmitidas.

Se não for possível usar essas alternativas:

• Verifique se é possível mudar seus sistemas para que o emissor de solicitações (por exemplo, site-one.example) defina explicitamente as informações necessárias em algum tipo de configuração.
  • Vantagem: mais explícito, mais preservação de privacidade para usuários do site-one.example, mais resistente ao futuro.
  • Desvantagem: mais trabalho do seu lado ou para os usuários do sistema.
• Verifique se o site que emite as solicitações pode definir uma Referrer-Policy por elemento ou por solicitação de no-referrer-when-downgrade.
  • Desvantagem: potencialmente menos preservação de privacidade para usuários do site-one.example, possivelmente sem suporte em todos os navegadores.

Proteção contra falsificação de solicitações entre sites (CSRF)

Um emissor de solicitações sempre pode decidir não enviar o referente definindo uma política no-referrer, e um usuário mal-intencionado pode até mesmo falsificar o referente.

Use os tokens CSRF como sua proteção principal. Para proteção extra, 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 cabeçalho Origin como alternativa. Isso pode fornecer as informações necessárias para fins de depuração de maneira mais simples e sem precisar analisar o referenciador.

Pagamentos

Os provedores de pagamentos podem usar o 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 uma lista de valores de Referer permitidos configurada pelos comerciantes. Se não corresponder a nenhuma entrada na lista, o payment-provider.example vai rejeitar a solicitação. Se ele coincidir, 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 de Referer indisponíveis para o provedor de pagamentos.

Analisar o Referer pode ajudar os provedores de pagamento a capturar invasores ingênuos que não definiram uma política 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 ele pode incluir, que é a origem.
  • Ao definir a lista de valores de Referer permitidos, inclua apenas a origem e nenhum caminho.
  • Por exemplo, os valores Referer permitidos para online-shop.example devem ser online-shop.example, e não online-shop.example/cart/checkout. Ao esperar nenhum Referer ou um valor de Referer que seja apenas a origem do site que fez a solicitação, você evita erros que podem ocorrer ao fazer suposições sobre o Referrer-Policy do comerciante.
• Se a Referer estiver ausente ou se ela estiver presente e a verificação básica de origem da Referer for bem-sucedida, será possível usar outro método de verificação mais confiável.

Para verificar os pagamentos com mais confiabilidade, permita que o solicitante crie um hash dos parâmetros da solicitação com uma chave exclusiva. Os provedores de pagamento poderão calcular o mesmo hash da sua parte e aceitar a solicitação somente se ela corresponder ao seu cálculo.

O que acontece com o Referer quando um site do 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 mudança do Chrome para uma nova política padrão não mudará esse comportamento.

Conclusão

Uma política de referrer de proteção é uma ótima maneira de dar mais privacidade aos seus usuários.

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

Recursos

• Entenda "mesmo site" e "mesma origem"
• Um novo cabeçalho de segurança: política de referenciador (2017)
• Política de referenciadores no MDN
• Cabeçalho do referenciador: questões de privacidade e segurança no MDN
• Mudança no Chrome: intent de piscar para implementar
• Mudança do Chrome: Blink intent to ship (link em inglês)
• Mudança no Chrome: entrada de status
• Mudança do Chrome: blogpost da versão 85 Beta
• Fórum do GitHub sobre o corte de referrers: o que diferentes navegadores fazem
• Especificação da política de referência

Agradecemos 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.