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.
![Solicitação HTTP que inclui um cabeçalho Referer.](https://web.dev/static/articles/referrer-best-practices/image/http-request-including-r-9ebf692a22831.jpg?authuser=5&hl=pt-br)
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:
![URLs com caminhos, mapeados para diferentes riscos de privacidade e segurança.](https://web.dev/static/articles/referrer-best-practices/image/urls-paths-mapped-diff-5b35e579c46d7.jpg?authuser=5&hl=pt-br)
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
![Dados que podem
estar contidos no cabeçalho Referer e no document.referrer.](https://web.dev/static/articles/referrer-best-practices/image/data-can-contained-the-209ad524f7ae8.jpg?authuser=5&hl=pt-br)
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
estrict-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.
Navegador | Padrão Referrer-Policy / comportamento |
---|---|
Chrome |
O padrão é strict-origin-when-cross-origin .
|
Firefox |
O padrão é strict-origin-when-cross-origin .A partir da versão 93, para usuários da Proteção estrita de rastreamento e da Navegação privada, as políticas de referenciador menos restritivas no-referrer-when-downgrade ,
origin-when-cross-origin e unsafe-url são
ignoradas para solicitações entre sites. Isso significa que o referenciador é sempre cortado
para solicitações entre sites, independentemente da política do site.
|
Borda |
O padrão é strict-origin-when-cross-origin .
|
Safari |
O padrão é semelhante ao strict-origin-when-cross-origin , com algumas diferenças específicas. Consulte
Como impedir o rastreamento do Tracking Prevention para saber mais.
|
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:
- Política no nível do elemento
- Política no nível da página
- 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.
![Captura de tela do painel "Network" do Chrome DevTools, mostrando o Referer e o Referrer-Policy.](https://web.dev/static/articles/referrer-best-practices/image/a-screenshot-the-network-7f0db2eae4fd4.jpg?authuser=5&hl=pt-br)
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
estrict-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
estrict-origin
compartilham apenas a origem, eno-referrer
não compartilha nada. Isso deixa comstrict-origin-when-cross-origin
,strict-origin
eno-referrer
como opções de melhoria de privacidade. - Útil:
no-referrer
estrict-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
(edocument.referrer
) recebido. O emissor de solicitação pode mudar para uma políticano-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 doReferer
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
(edocument.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
eSec-Fetch-Site
fornecem oOrigin
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.
- Pró: mais explícito, mais que preserva a privacidade para os usuários do
- 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.
- Desvantagem: possivelmente menos preservar a privacidade para usuários
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 parapayment-provider.example
para gerenciar a transação.payment-provider.example
verifica oReferer
dessa solicitação em relação a uma lista de valores deReferer
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
paraonline-shop.example
precisam seronline-shop.example
, nãoonline-shop.example/cart/checkout
. Ao esperar nenhum valor deReferer
ou um valor deReferer
que seja apenas a origem do site solicitante, você evita erros que podem resultar de suposições sobreReferrer-Policy
do comerciante.
- Ao definir a lista de valores de
- Se a
Referer
estiver ausente ou se estiver presente e a verificação básica de origem daReferer
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.