Qué es open redirect: riesgos y cómo prevenirlo

Open redirect, o redirección abierta, es una vulnerabilidad web en la que una aplicación traslada al navegador del usuario hacia una URL de destino tomada directamente de un parámetro controlable, sin verificar que ese destino pertenece a un conjunto de sitios de confianza. El estándar la cataloga como CWE-601 (URL Redirection to Untrusted Site) y también se conoce como unvalidated redirects and forwards. Por sí sola rara vez compromete datos del servidor, y por eso suele infravalorarse en los informes, pero es una pieza extraordinariamente útil para el atacante: presta la reputación de un dominio legítimo a un enlace que termina en infraestructura hostil, y en flujos de autenticación puede convertirse en el eslabón que filtra tokens de sesión completos.

Lo esencial. open redirect abusa de la confianza que el usuario y los sistemas de filtrado depositan en un dominio conocido. Su riesgo alto aparece cuando se encadena con phishing o con OAuth, donde una redirección no validada permite exfiltrar códigos de autorización y access tokens. La defensa correcta no es una blocklist de dominios malos, sino una allowlist estricta de destinos permitidos, o mejor aún, evitar por completo que el destino viaje como URL en el parámetro.

Qué es open redirect y por qué se subestima

El patrón vulnerable nace de una funcionalidad legítima y muy extendida: tras iniciar sesión, tras confirmar una acción o tras salir de una pasarela, la aplicación quiere devolver al usuario a la página donde estaba. Para recordar ese destino, muchas implementaciones lo guardan en un parámetro de la URL. Nombres habituales son ?next=, ?url=, ?redirect=, ?return=, ?returnUrl=, ?continue=, ?dest=, ?destination=, ?checkout_url= y, en flujos federados, ?redirect_uri= o el RelayState de SAML.

El defecto aparece cuando el servidor toma ese valor y emite la redirección sin comprobar el destino. Una petición tan inocente como https://apptrusted.tld/login?next=/dashboard funciona igual de bien con https://apptrusted.tld/login?next=https://atacante.tld, y el navegador acaba en el sitio del atacante habiendo partido de un dominio de confianza. La razón por la que se subestima es que el escáner marca un severity bajo y el desarrollador no ve robo de datos inmediato. Ese análisis ignora el valor real del bug: no está en lo que hace por sí mismo, sino en lo que habilita cuando se combina con ingeniería social o con protocolos de autorización.

Cómo funciona: tipos de redirección

Conviene distinguir dónde se materializa la redirección, porque cambia tanto la explotación como la defensa.

Redirección del lado servidor (cabecera Location)

Es la variante clásica. El backend responde con un código 3xx y una cabecera Location construida a partir del parámetro:

GET /login?next=https://atacante.tld HTTP/1.1
Host: apptrusted.tld

HTTP/1.1 302 Found
Location: https://atacante.tld

Se detecta con una simple inspección de cabeceras, por ejemplo curl -I "https://apptrusted.tld/login?next=https://atacante.tld" y observando si el Location refleja el dominio externo sin filtrar.

Redirección del lado cliente (DOM-based)

Aquí el destino lo procesa JavaScript en el navegador, típicamente con window.location, location.href, location.assign() o location.replace() alimentados desde location.search o el fragmento #. Esta variante es DOM-based y no siempre deja rastro en el servidor, lo que dificulta su detección con herramientas que solo miran respuestas HTTP. Además abre una puerta adicional: si el código asigna a location un valor con esquema javascript: o data:, la redirección abierta puede escalar a ejecución de script en el dominio, es decir, un XSS basado en DOM. Otras formas menos frecuentes son la etiqueta <meta http-equiv="refresh"> generada dinámicamente y las cabeceras Refresh.

Open redirect como arma de phishing

El uso más común es el phishing. Un correo o un mensaje que contiene https://login.marca-conocida.tld/redir?url=https://marca-conocida.tld.atacante.tld/verificar supera el primer filtro humano: el dominio inicial es real, coincide con la marca y aparece en la barra al pasar el ratón. También supera muchos filtros automáticos, porque los gateways de correo y los proxies suelen mantener listas de reputación por dominio, y el dominio de partida está limpio. La víctima confía en el punto de origen, no advierte el salto y aterriza en una página de credenciales clonada.

Este vector potencia campañas descritas en nuestra guía sobre cómo evitar el phishing, y explica por qué un hallazgo aparentemente menor merece corrección: cada redirector abierto en un dominio corporativo es un amplificador gratuito para quien suplanta a la organización.

Robo de tokens OAuth: el impacto crítico

Donde open redirect deja de ser molesto y pasa a ser grave es en OAuth 2.0 y OpenID Connect. El flujo de authorization code depende de un parámetro redirect_uri que indica a dónde debe devolver el servidor de autorización el código o el token. El estándar exige que ese destino se valide contra los valores registrados por el cliente, precisamente porque es un blanco natural.

El problema surge cuando la validación de redirect_uri es laxa (por ejemplo, comprobando solo que el dominio coincida) y en ese mismo dominio existe un open redirect. El atacante registra o solicita un redirect_uri que apunta al redirector abierto del cliente legítimo; el servidor de autorización lo acepta porque el host está en la allowlist; y tras la autenticación de la víctima, el código de autorización o el access token viajan hacia el redirector, que a su vez los reenvía al servidor del atacante, con frecuencia expuestos en la query string o en el fragmento y visibles en la cabecera Referer. Esta clase de encadenamiento se documentó públicamente como covert redirect en 2014 y sigue vigente. La guía de seguridad vigente para OAuth, RFC 9700 (OAuth 2.0 Security Best Current Practice), junto con las consideraciones de la RFC 6749, recomienda comparación exacta de cadena para redirect_uri, prohibición de comodines y uso de PKCE, medidas que cierran este abuso. Si trabajas con tokens en tus APIs, conviene revisar también nuestro artículo sobre seguridad de JWT, porque el token robado por esta vía suele ser un JWT con toda la sesión dentro.

Técnicas de bypass de validaciones débiles

Muchas aplicaciones intentan defenderse con comprobaciones frágiles que un atacante rompe con variaciones de URL. Estas son las técnicas que un pentester prueba de forma sistemática:

• URL relativa a protocolo: //atacante.tld. El navegador la interpreta como absoluta hacia ese host, pero un filtro ingenuo que solo rechaza cadenas que empiezan por http la deja pasar.
• Abuso del userinfo: https://apptrusted.tld@atacante.tld. Un validador que busca la subcadena apptrusted.tld la encuentra, pero el host real es atacante.tld.
• Confusión con backslash: https:/\atacante.tld, /\/atacante.tld o \/\/atacante.tld. Los navegadores normalizan las barras invertidas a barras normales, mientras que muchos parseadores de servidor no lo hacen, creando una divergencia explotable.
• Prefijos y sufijos engañosos: https://atacante.tld/apptrusted.tld, https://apptrusted.tld.atacante.tld o https://apptrusted.tld.atacante.tld/. El dominio de confianza aparece en la cadena, pero no es el host efectivo.
• Codificación y caracteres de control: %2F%2Fatacante.tld, doble codificación, tabuladores o saltos de línea insertados para romper expresiones regulares.
• Homógrafos IDN y Unicode que imitan visualmente al dominio legítimo.

El denominador común es una diferencia de interpretación (parser differential) entre el componente que valida la URL y el que finalmente la usa. Esta misma clase de discrepancia está detrás de una serie de avisos del Spring Framework de 2024, identificados como CVE-2024-22243 y CVE-2024-22262, donde el parseo de URL en UriComponentsBuilder podía abusarse para open redirect y SSRF. Por eso la validación mediante blocklist o regex casera es una batalla perdida.

Cómo prevenir open redirect

La defensa se ordena de la más robusta a la más frágil:

1. No aceptar URLs como destino. La opción más segura es la indirección: en lugar de recibir una URL, recibir un identificador o token corto (?next=dashboard) que el servidor traduce a una ruta mediante un mapa interno. El atacante no puede introducir un host arbitrario porque el host nunca viaja en el parámetro.
2. Forzar destinos relativos. Si la aplicación solo necesita volver a una página propia, aceptar exclusivamente rutas que empiecen por una única barra y rechazar cualquier valor que contenga //, /\, un esquema o un carácter @. Descartar el host por completo y anteponer siempre el origen propio del servidor.
3. Allowlist estricta de destinos. Cuando el negocio exige redirigir a dominios externos concretos (por ejemplo, pasarelas de pago), parsear la URL con una librería robusta, extraer el host y compararlo por coincidencia exacta contra una lista corta de dominios permitidos. Nunca por contains, startsWith ni endsWith.
4. En OAuth, comparación exacta de redirect_uri, sin comodines ni coincidencias parciales de dominio, más PKCE en todos los clientes públicos.
5. Página intermedia de aviso para salidas externas legítimas, que informe al usuario de que abandona el dominio antes de completar la redirección, tal como hacen los grandes buscadores.

Como capas complementarias, conviene marcar los enlaces salientes con rel="noopener noreferrer" para no filtrar el Referer, y aplicar una Content Security Policy que limite los destinos de navegación cuando sea viable. Estas medidas no sustituyen a la validación del destino, la refuerzan.

Cómo testear open redirect en una auditoría

En una auditoría web, el flujo habitual empieza por descubrir parámetros candidatos. Herramientas como Arjun o ParamSpider ayudan a enumerar nombres de parámetros ocultos, y el interceptor de Burp Suite permite marcar cada punto donde una URL o una ruta viaja hacia el servidor. Después se inyecta un dominio controlado (un canary) en cada parámetro sospechoso y se observa la respuesta: un Location o una redirección de cliente que apunte al canary confirma el hallazgo.

Para automatizar el fuzzing de listas de bypass se usan ffuf y nuclei, que incluye plantillas específicas de open redirect, así como escáneres dedicados como Oralyzer. La confirmación manual sigue siendo imprescindible en la variante DOM-based, donde hay que revisar el JavaScript que asigna a location y comprobar si acepta esquemas peligrosos. Como parte de la revisión OWASP, este control se corresponde con WSTG-CLNT-04 (Testing for Client-side URL Redirect) de la Web Security Testing Guide.

Encaje con OWASP y estándares

Open redirect tuvo entrada propia en el OWASP Top 10 de 2013 como A10 (Unvalidated Redirects and Forwards) y desapareció como categoría independiente en ediciones posteriores por su menor prevalencia relativa, no por dejar de existir. Hoy se evalúa dentro de la disciplina de validación de entradas y del control de flujos de autenticación, y aparece de forma recurrente en programas de bug bounty precisamente por su capacidad de encadenarse. Su identificador canónico sigue siendo CWE-601, y su tratamiento forma parte de cualquier revisión seria junto al resto del catálogo, como recogemos en las vulnerabilidades web más comunes de 2025.

Preguntas frecuentes

¿Open redirect es una vulnerabilidad grave o menor?

Depende del contexto. Aislado y hacia un destino sin credenciales, su severity es baja. Encadenado con phishing sobre un dominio de marca o con un flujo OAuth de validación laxa, se convierte en un riesgo alto porque habilita robo de credenciales y de tokens de sesión. La gravedad la fija el uso, no la mecánica.

¿Basta con bloquear las URLs que empiezan por http?

No. Ese filtro se rompe con //atacante.tld, con https:/\atacante.tld o con el truco del @ en el userinfo. Cualquier defensa basada en rechazar patrones concretos (blocklist) pierde frente a las variaciones de codificación y de sintaxis de URL. La solución correcta es allowlist de destinos o evitar la URL en el parámetro.

¿Qué diferencia hay entre open redirect y SSRF?

En open redirect quien realiza la petición al destino malicioso es el navegador de la víctima, del lado cliente. En SSRF quien la realiza es el propio servidor, del lado backend, alcanzando recursos internos. Comparten la idea de un destino no validado, pero el impacto y la defensa difieren.

¿Cómo afecta open redirect a OAuth exactamente?

Si el servidor de autorización valida el redirect_uri solo por dominio y en ese dominio existe un redirector abierto, el atacante logra que el código de autorización o el token se reenvíen a su servidor a través de la redirección. La mitigación es comparación exacta de redirect_uri, prohibición de comodines y PKCE, tal como recomienda la RFC 9700.

¿Los frameworks modernos protegen por defecto?

Algunos ofrecen ayudas, como funciones de redirección que fuerzan rutas relativas, pero muchos aceptan URLs absolutas sin objeción si el desarrollador las pasa. La protección efectiva depende de usar esas funciones correctamente y de validar el destino, no de asumir que el framework lo hace solo.

Recursos relacionados

• Qué es CSRF: cross-site request forgery
• Qué es XSS: cross-site scripting
• Qué es SSRF: server-side request forgery
• Qué es JWT y consideraciones de seguridad
• Cómo evitar el phishing
• Auditoría de seguridad web y móvil

Auditar open redirect y vulnerabilidades web con Secra

En Secra tratamos open redirect no como un hallazgo de relleno, sino como lo que es: un habilitador de phishing dirigido y de robo de tokens en flujos de autenticación. Nuestras auditorías web, alineadas con OWASP Top 10 y la Web Security Testing Guide, enumeran todos los parámetros de redirección, prueban de forma sistemática las técnicas de bypass, revisan la variante DOM-based en el JavaScript de la aplicación y verifican la validación de redirect_uri en vuestros flujos OAuth y OpenID Connect. Entregamos hallazgos priorizados por impacto real, casos de prueba reproducibles y recomendaciones de corrección concretas para vuestro stack. Si necesitáis confirmar que ningún dominio de vuestra organización presta su reputación a un atacante, escribidnos desde esta página y planificamos una auditoría a medida.