Una redirección abierta es cuando una URL que empieza con tu dominio real envía a los visitantes a un sitio completamente distinto. Aquí tienes cómo funciona y cómo prevenirla de forma fiable (sin pasos de ataque).
Por qué es peligrosa
El daño central es la confianza prestada de tu dominio.
| Cómo se abusa | Qué ocurre |
|---|---|
| Phishing a través de tu dominio | El enlace empieza con el dominio real → los usuarios y los filtros confían → fuera, a un sitio falso |
| Secuestro del flujo de autenticación | Manipular el destino de redirección en flujos tipo OAuth para capturar un token o código |
| Amplificación de otros fallos | Combinada con SSRF o XSS para ampliar el impacto |
Por qué funciona
Aparece en funciones como «devolver al usuario a donde estaba tras iniciar sesión», donde la URL de retorno es de confianza y se reenvía tal cual. El «comienzo» de la URL que ve el usuario es el dominio real, por lo que cuesta dudar hasta el final.
Defensa: no aceptes URLs externas
Permite solo rutas relativas (lo más importante)
Acepta destinos de retorno como /dashboard —solo rutas relativas— y rechaza URLs completas (que empiecen por http:// o //). No dejes margen para que el usuario especifique un dominio de destino.
Compara con una lista de permitidos
Si necesitas destinos dinámicos, permite solo entradas de un conjunto fijo de destinos conocidos (un mapa). Cualquier otra cosa cae en una página predeterminada.
No dependas de comprobaciones de cadenas
//evil, las barras invertidas, @ y la multicodificación eluden los filtros ingenuos. Cambia lo que aceptas (relativas + lista de permitidos) en lugar de parchear filtros.
Si debes salir del sitio, hazlo explícito
Cuando las redirecciones externas sean intencionadas, muestra una página intermedia («Estás saliendo hacia un sitio externo»). No reenvíes en silencio.
La visión de este sitio: calificada como 'baja' por sí sola, pero grave combinada con phishing
Las redirecciones abiertas suelen calificarse como bajas por sí mismas, pero como los atacantes pueden aprovechar la confianza en tu dominio, se vuelven graves combinadas con phishing o secuestro de autenticación. Por eso una corrección a nivel de diseño (rutas relativas + lista de permitidos) elimina la causa de forma eficiente. Refleja el caso de SSRF (hacer que el servidor se conecte a cualquier sitio): ambos comparten el principio de defensa de no dejar nunca que el usuario decida el destino.
Redirección abierta frente a SSRF y phishing
Una redirección abierta es menos un ataque en sí que un fallo que hace más convincentes otros ataques. Ponerla junto a términos relacionados muestra dónde encaja.
| Término | Qué ocurre | Quién lo corrige |
|---|---|---|
| Redirección abierta | Una URL del sitio real reenvía el navegador del usuario a un sitio externo | Los desarrolladores del sitio con la función de redirección |
| SSRF | No es el navegador sino el servidor quien envía una petición al destino indicado | Los desarrolladores del sitio con la función que obtiene URLs |
| Phishing | Un sitio falso consigue que la gente introduzca usuarios, contraseñas o datos de tarjeta | Los usuarios, los receptores de correo y la organización suplantada |
Cuando un enlace de phishing puede usar un dominio real, tanto a los usuarios como a los filtros de correo les cuesta más detectarlo. Eliminar las redirecciones abiertas evita que tu dominio se use en estafas.
Ejemplo: donde más importa, las integraciones de inicio de sesión (OAuth)
Las redirecciones abiertas importan sobre todo en las integraciones de inicio de sesión (OAuth). Tras la autorización, el usuario vuelve a la URI de redirección registrada llevando un código de autorización o un token. Si el sitio al que vuelve tiene una redirección abierta, el código o el token puede acabar enviado a un sitio externo.
Por eso la OAuth 2.0 Security Best Current Practice (RFC 9700, enero de 2025) exige dos cosas.
- El servidor de autorización compara las URI de redirección con las registradas de antemano mediante coincidencia exacta
- Ni los clientes ni los servidores de autorización exponen páginas que reenvíen a una URL arbitraria tomada de un parámetro de consulta
Las redirecciones abiertas se clasifican como CWE-601. Por sí solas rara vez se califican de gravedad alta, pero junto a una integración de inicio de sesión se convierten en un problema serio.
Qué gravedad tiene
Por sí sola, una redirección abierta suele calificarse como media. Una calificación que se ve a menudo es CVSS 3.1 6.1.
- El usuario tiene que abrir el enlace (UI:R)
- El impacto es enviar a los usuarios a otro sitio; no permite a nadie leer directamente los datos del sitio
- Como el impacto va más allá del sitio que redirige, se puntúa como cambio de alcance (S:C)
No lo aplaces por el número. Corrígela primero si está en la ruta de retorno de una integración de inicio de sesión, o si ya se está usando en phishing. Para puntuar tu propio caso, usa la calculadora CVSS.
Funciones seguras que tu framework ya tiene
Las funciones del framework tienen menos probabilidad de dejarse un caso que tus propias comprobaciones de cadenas. Dos ejemplos habituales:
| Framework | Función | Qué hace |
|---|---|---|
| Ruby on Rails | Comportamiento por defecto de redirect_to y url_from | Por defecto bloquea las redirecciones a otros hosts; enviar a los usuarios fuera del sitio requiere un allow_other_host: true explícito. url_from devuelve la URL solo si está en el mismo host; si no, nil |
| ASP.NET Core | LocalRedirect y Url.IsLocalUrl | Redirige solo a URLs del mismo sitio, y lanza una excepción con una URL externa |
La documentación de Rails advierte de que, incluso con allow_other_host: true, pasar directamente un parámetro proporcionado por el usuario no es seguro. Al añadir una función de redirección externa, evita esa combinación.
Cómo revisar tu propio sitio
Localiza los parámetros que reciben un destino
Busca en tu código y en tu lista de URLs parámetros con nombres como next, url, redirect, return_to, continue o callback, y comprueba si se pasan tal cual a una redirección.
Revisa cómo se validan los destinos
Mira si la validación se basa en comparar el prefijo de la cadena o en «¿empieza por http?». En su lugar, separa la URL en esquema, host y puerto con un analizador de URLs y compárala con una lista de permitidos, o usa las funciones seguras del framework (como LocalRedirect en ASP.NET Core).
Revisa los registros de tus integraciones de inicio de sesión
En la configuración de OAuth o SSO, comprueba que las URI de redirección registradas no tienen comodines ni URLs antiguas que ya no necesitas.
Plantéate elegir el destino por ID
Si tienes que redirigir fuera del sitio, acepta un ID corto en lugar de la propia URL y busca el destino en una tabla del lado del servidor. OWASP recomienda este enfoque.
Busca redirecciones externas en tus registros de acceso
Busca en tus registros de acceso peticiones en las que un parámetro de destino contenga un nombre de host distinto del tuyo. Si encuentras alguna, comprueba si esa redirección envía de verdad a la gente fuera del sitio, y tómalo como señal de que alguien puede estar difundiendo esos enlaces.
Fuentes (primarias)
- OWASP, «Unvalidated Redirects and Forwards Cheat Sheet» — cheatsheetseries.owasp.org (en inglés; IDs asignados en el servidor, comprobación de URLs analizadas contra una lista de permitidos, páginas de aviso)
- IETF RFC 9700, «Best Current Practice for OAuth 2.0 Security» (enero de 2025) — datatracker.ietf.org (en inglés; coincidencia exacta de URI de redirección, sin redirectores abiertos)
- Ruby on Rails API, «ActionController::Redirecting» — api.rubyonrails.org (en inglés; protección por defecto contra redirecciones a otros hosts,
allow_other_host,url_from) - Microsoft, «Prevent open redirect attacks in ASP.NET Core» — learn.microsoft.com (en inglés;
LocalRedirect,IsLocalUrl, registro de URLs no locales) - MITRE, «CWE-601: URL Redirection to Untrusted Site ('Open Redirect')» — cwe.mitre.org (en inglés)
Sigue leyendo
- Glosario: Qué es SSRF · Qué es XSS · Qué es el phishing · Qué es CVSS
- Fundamentos: Fundamentos de seguridad