Um open redirect é quando uma URL que começa com o seu domínio real leva os visitantes a um site completamente diferente. Veja como funciona e como evitá-lo de forma confiável (sem passos de ataque).
Por que é perigoso
O dano central é a confiança emprestada do seu domínio.
| Como é abusado | O que acontece |
|---|---|
| Phishing pelo seu domínio | O link começa com o domínio real → usuários e filtros confiam → vão para um site falso |
| Sequestro de fluxo de autenticação | Adulteração do destino de redirecionamento em fluxos do tipo OAuth para capturar um token/código |
| Amplificação de outras falhas | Combinado com SSRF ou XSS para ampliar o impacto |
Por que funciona
Aparece em recursos como "levar o usuário de volta para onde estava após o login", onde a URL de retorno é confiada e encaminhada como está. O "início" da URL que o usuário vê é o domínio real, então é difícil desconfiar dela do começo ao fim.
Defesa: não aceite URLs externas
Permita apenas caminhos relativos (o mais importante)
Aceite destinos de retorno como /dashboard — apenas caminhos relativos — e rejeite URLs completas (que começam com http:// ou //). Não dê espaço para o usuário especificar um domínio de destino.
Compare com uma allowlist
Se você precisar de destinos dinâmicos, permita apenas entradas de um conjunto fixo de destinos conhecidos (um mapa). Qualquer outra coisa recai em uma página padrão.
Não confie em verificações de string
//evil, barras invertidas, @ e codificação múltipla contornam filtros ingênuos. Mude o que você aceita (relativo + allowlist) em vez de remendar filtros.
Se precisar sair do site, deixe explícito
Quando redirecionamentos externos forem intencionais, exiba uma página intermediária ("Você está saindo para um site externo"). Não encaminhe silenciosamente.
A visão deste site: classificado como 'baixo' sozinho, mas grave quando combinado com phishing
Open redirects costumam ser classificados como baixo risco por si só, mas como atacantes podem tomar emprestada a confiança do seu domínio, tornam-se graves combinados com phishing ou sequestro de autenticação. Por isso uma correção em nível de projeto (caminhos relativos + allowlist) remove a causa com eficiência. Espelha o SSRF (fazer o servidor se conectar a qualquer lugar): ambos compartilham o princípio de defesa de nunca deixar o usuário decidir o destino.
Open redirect vs. SSRF vs. phishing
Um open redirect é menos um ataque em si e mais uma falha que torna outros ataques mais convincentes. Colocá-lo ao lado de termos relacionados mostra onde ele se encaixa.
| Termo | O que acontece | Quem corrige |
|---|---|---|
| Open redirect | Uma URL do site verdadeiro encaminha o navegador do usuário para um site externo | Desenvolvedores do site com o recurso de redirecionamento |
| SSRF | Não o navegador, mas o servidor envia uma requisição ao destino que recebeu | Desenvolvedores do site com o recurso de buscar URLs |
| Phishing | Um site falso leva pessoas a digitar IDs, senhas ou dados de cartão | Usuários, quem recebe os e-mails e a organização imitada |
Quando um link de phishing pode usar um domínio verdadeiro, tanto usuários quanto filtros de e-mail têm mais dificuldade de perceber. Remover open redirects impede que o seu domínio seja usado em golpes.
Exemplo: onde mais importa, as integrações de login (OAuth)
Open redirects importam mais em integrações de login (OAuth). Após a autorização, o usuário é enviado de volta à URI de redirecionamento registrada levando um código de autorização ou token. Se o site para onde ele volta tiver um open redirect, o código ou token pode ser repassado a um site externo.
Por isso as boas práticas de segurança do OAuth 2.0 (RFC 9700, janeiro de 2025) exigem duas coisas.
- O servidor de autorização compara as URIs de redirecionamento com as pré-registradas por correspondência exata
- Nem clientes nem servidores de autorização expõem páginas que encaminhem para uma URL arbitrária vinda de um parâmetro da query
Open redirects são classificados como CWE-601. Sozinhos raramente recebem gravidade alta, mas ao lado de uma integração de login tornam-se um problema sério.
Qual a gravidade
Sozinho, um open redirect costuma ser classificado como médio. Uma classificação comum é CVSS 3.1 6.1.
- O usuário precisa abrir o link (UI:R)
- O impacto é mandar usuários para outro site; não permite ler diretamente os dados do site
- Como o impacto vai além do site que redireciona, ele é pontuado como mudança de escopo (S:C)
Não adie por causa do número. Corrija primeiro se ele estiver no caminho de retorno de uma integração de login ou se já estiver sendo usado em phishing. Para pontuar o seu próprio caso, use a calculadora de CVSS.
Helpers seguros que o seu framework já tem
Os recursos do framework deixam passar menos casos do que as suas próprias verificações de string. Dois exemplos comuns:
| Framework | Helper | O que faz |
|---|---|---|
| Ruby on Rails | Comportamento padrão do redirect_to e url_from | Por padrão bloqueia redirecionamentos para outros hosts; mandar usuários para fora do site exige um allow_other_host: true explícito. url_from devolve a URL só se ela estiver no mesmo host; caso contrário, nil |
| ASP.NET Core | LocalRedirect e Url.IsLocalUrl | Redireciona apenas para URLs dentro do mesmo site e lança uma exceção para uma URL externa |
A documentação do Rails alerta que, mesmo com allow_other_host: true, repassar direto um parâmetro fornecido pelo usuário não é seguro. Ao criar um recurso de redirecionamento para fora do site, evite essa combinação.
Como verificar o seu próprio site
Encontre parâmetros que recebem um destino
Procure no seu código e na sua lista de URLs parâmetros com nomes como next, url, redirect, return_to, continue ou callback, e verifique se eles são passados direto para um redirecionamento.
Verifique como os destinos são validados
Veja se a validação depende de comparação de prefixo da string ou de "começa com http". Em vez disso, separe a URL em esquema, host e porta com um parser de URL e compare com uma allowlist, ou use os helpers seguros do framework (como o LocalRedirect do ASP.NET Core).
Revise os registros da sua integração de login
Nas configurações de OAuth ou SSO, confira se as URIs de redirecionamento registradas não têm curingas nem URLs antigas de que você não precisa mais.
Considere escolher destinos por ID
Se precisar redirecionar para fora, aceite um ID curto em vez da própria URL e procure o destino numa tabela no servidor. A OWASP recomenda essa abordagem.
Procure redirecionamentos para fora nos logs de acesso
Pesquise nos logs de acesso requisições em que um parâmetro de destino contém um nome de host diferente do seu. Se encontrar, verifique se esse redirecionamento realmente manda pessoas para fora do site e trate isso como sinal de que alguém pode estar circulando esses links.
Fontes (primárias)
- OWASP, "Unvalidated Redirects and Forwards Cheat Sheet" — cheatsheetseries.owasp.org (em inglês; IDs mapeados no servidor, allowlist sobre URLs já analisadas, páginas de aviso)
- IETF RFC 9700, "Best Current Practice for OAuth 2.0 Security" (janeiro de 2025) — datatracker.ietf.org (em inglês; correspondência exata de URIs de redirecionamento, sem open redirectors)
- Ruby on Rails API, "ActionController::Redirecting" — api.rubyonrails.org (em inglês; proteção padrão contra redirecionamentos para outros hosts,
allow_other_host,url_from) - Microsoft, "Prevent open redirect attacks in ASP.NET Core" — learn.microsoft.com (em inglês;
LocalRedirect,IsLocalUrl, registro de URLs não locais) - MITRE, "CWE-601: URL Redirection to Untrusted Site ('Open Redirect')" — cwe.mitre.org (em inglês)
Leia a seguir
- Glossário: O que é SSRF · O que é XSS · O que é phishing · O que é CVSS
- Fundamentos: Fundamentos de segurança