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

Maud Nalpas

Esta página descreve algumas práticas recomendadas para definir sua política do referenciador e usando o referenciador nas solicitações recebidas.

Resumo

• O vazamento inesperado de informações de origem cruzada prejudica os usuários da Web. privacidade. Um a política de referenciador de proteção.
• Considere definir uma política de referenciador de strict-origin-when-cross-origin. Ela preserva a maior parte da utilidade do referenciador, reduzindo o risco de vazando dados de diferentes origens.
• Não use referenciadores para proteção contra falsificação de solicitação entre sites (CSRF, na sigla em inglês). Usar Tokens de CSRF e outros cabeçalhos como uma camada extra de segurança.

Política de referenciador e de referenciador 101

As solicitações HTTP podem incluir um cabeçalho Referer opcional, que indica a origem ou o URL da página da Web a partir do qual a solicitação foi feita. A 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 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 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á-los para determinar que 50% dos visitantes em site-two.example vieram de social-network.example. Mas quando o URL completo, incluindo o caminho e string de consulta for enviada no Referer entre origens, pode colocar o usuário em risco a privacidade e criar riscos de segurança:

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

O URL no 6 é um URL de recurso. Se alguém sem ser o usuário pretendido, um usuário malicioso pode assumir o controle da conta deste usuário.

Para restringir os dados do referenciador 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) pode 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 criadas para se comportar de maneira diferente dependendo do contexto: solicitação de origem cruzada ou da mesma origem, esteja o destino da solicitação como segura como a origem ou ambas. Isso é útil para limitar a quantidade de informações compartilhados entre origens ou com origens menos seguras, mantendo a riqueza de do referenciador no seu site.

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

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

Veja algumas coisas que você precisa considerar ao definir uma política de referenciador:

• Todas as políticas que consideram o esquema (HTTPS ou 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 as solicitações de uma origem HTTPS para outra origem HTTPS, embora o HTTP seja menos seguro. Isso porque para essas o que importa é a ocorrência de um downgrade de segurança. que é, se a solicitação puder expor dados de uma origem criptografada a uma como em solicitações HTTPS → HTTP. Uma solicitação HTTP → HTTP é descriptografados, para que não haja downgrade.
• Se uma solicitação tem a mesma origem, isso significa que o esquema (HTTPS ou HTTP) é são iguais, 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 referenciadores para seu site:

• Como um cabeçalho HTTP
• Em 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 são ambos no nível da página. A ordem de prioridade determinar a política efetiva de um elemento é o 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 as solicitações de sub-recursos desta página seguem a strict-origin-when-cross-origin política.

Como ver a política de referenciador?

securityheaders.com é útil para determinar quais política que um site ou uma página específica usa.

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

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

É altamente recomendável definir explicitamente uma política de melhoria da privacidade, como 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 frequentemente mudar para o padrão do navegador. Mas isso não é o ideal, porque:

• Navegadores diferentes têm políticas padrão diferentes, portanto, se você depende do navegador padrões, seu site não se comportará de maneira 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 corte de referenciadores para solicitações entre origens. Aceitar explicitamente uma política que melhora a privacidade antes da mudança do padrão do navegador, que oferece controle e ajuda a executar testes que você achar adequado.

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

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

• Seguro: se o seu site usa HTTPS (se não, torne-o um prioridade), você não quer que os URLs do seu site vazem solicitações não HTTPS. Como todos na rede podem ver isso, os vazamentos expor seus usuários a ataques do tipo person-in-the-middle. As políticas no-referrer-when-downgrade, strict-origin-when-cross-origin e no-referrer. e strict-origin resolverão esse problema.
• Aprimoramento 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ê 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 sensata.

Exemplo: 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 atender a 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 no seu site e, se necessário, outros política de permissão 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 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?

Sua política depende 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

Aqui estão algumas diretrizes sobre o que fazer caso seu site use o URL referenciador de as solicitações recebidas.

Proteger os usuários dados

O Referer pode conter dados particulares, pessoais ou de identificação. Portanto, verifique se você o trata dessa forma.

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

Alternativas a Referer

Talvez seja necessário considerar alternativas se:

• Um recurso essencial de seu site usa o URL referenciador de entrada solicitações entre origens.
• Seu site não está mais recebendo a parte do URL referenciador necessária em um solicitação de origem cruzada. Isso acontece quando o emissor da solicitação muda política ou quando não há uma política definida e a política do navegador padrão foi 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 que tem acesso de nível superior à página, window.location.origin é uma alternativa.
• Se disponíveis, cabeçalhos como Origin e Sec-Fetch-Site fornecer o Origin ou descrever se a solicitação é de origem cruzada, 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 analisando o referenciador.
• Se você estiver usando o referenciador em um script que tem acesso de nível superior à página, window.location.pathname pode funcionar como alternativa. Extrair apenas o caminho do URL e transmiti-la como argumento, para que quaisquer arquivos potencialmente nos parâmetros de URL não serão transmitidas.

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

• Verificar se é possível mudar os sistemas para esperar o emissor da solicitação (por exemplo, site-one.example) para definir explicitamente as informações de que você precisa. em algum tipo de configuração.
  • Pró: mais explícito e mais privacidade para usuários do site-one.example, mais preparados para o futuro.
  • Desvantagem: você talvez precise fazer mais da sua parte ou para os usuários do 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.
  • Desvantagem: que preserva a privacidade possivelmente menos para site-one.example usuários, é possivelmente incompatí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 no-referrer. Caso contrário, um usuário malicioso poderá falsificar o referenciador.

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

Registrar e depurar

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

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

Pagamentos

Os provedores de pagamento podem usar o cabeçalho Referer das solicitações recebidas de e 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 o transação.
• payment-provider.example verifica o Referer dessa solicitação em uma lista de valores de Referer permitidos configurados pelos comerciantes. Se não houver correspondência entrada na lista, payment-provider.example rejeita a solicitação. Se isso acontecer, for correspondente, 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 em alguns ataques. No entanto, o cabeçalho Referer por si só não é uma base confiável para um cheque. O site solicitante, sendo um comerciante legítimo ou não, pode definir um A política no-referrer que torna as informações de Referer indisponíveis para o provedor de pagamento.

Analisar o Referer pode ajudar os provedores de pagamento a capturar invasores ingênuos que não definiu 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 com os dados mínimos que ela pode incluir, 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 Referer permitidos para online-shop.example devem ser online-shop.example, não online-shop.example/cart/checkout. Ao esperar nenhum Referer ou um valor Referer que é apenas o solicitante origem do site, você evita erros que podem surgir de suposições sobre o Referrer-Policy do comerciante.
• Se o Referer estiver ausente ou presente e sua origem básica de Referer for bem-sucedida, você pode passar para outra verificação mais confiável .

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

O que acontece com Referer quando um site de comerciante HTTP sem referenciador a política 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. Mudança do Chrome para uma nova política padrão não vai mudar esse comportamento.

Conclusão

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

Para saber mais sobre diferentes técnicas para proteger seus usuários, acesse nossas Coleta segura

Recursos

• Noções básicas sobre "mesmo site" e "mesma origem"
• Um novo cabeçalho de segurança: política de referenciadores (2017)
• Política do referenciador ativada MDN
• Cabeçalho do referenciador: questões de privacidade e segurança sobre MDN
• Mudança do Chrome: pisque a intenção para implementar
• Mudança do Chrome: pisque a intenção para envio
• Mudança do Chrome: entrada de status
• Mudança no Chrome: 85 Beta blogpost
• Referenciador cortando conversa do GitHub: quais navegadores diferentes fazer
• Especificação da política de referenciador

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