Saltar al contenido
>_ITDITDPlataforma de seguridad web

Glosario

Qué es la redirección abierta (open redirect): tu URL de confianza usada como trampolín hacia otro sitio

Una redirección abierta (open redirect) permite que una URL de tu sitio reenvíe a los visitantes a cualquier sitio externo, volviendo tu dominio de confianza un trampolín para el phishing. Cómo funciona y la defensa real: nunca aceptar URLs externas.

Publicado 2026-06-10 Actualizado 2026-06-10 3 min de lectura

«El comienzo de la URL era mi dominio real, pero al hacer clic me llevó a un sitio completamente distinto»: eso es una redirección abierta. 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 abusaQué ocurre
Trampolín de phishingEl enlace empieza con el dominio real → los usuarios y los filtros confían → fuera, a un sitio falso
Secuestro del flujo de autenticaciónManipular el destino de redirección en flujos tipo OAuth para capturar un token o código
Amplificación de otros fallosCombinada 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.

dominioreal/login?next= (el comienzo es de confianza)
se planta una URL externa en next=
↓ el sitio reenvía sin validar el destino
el usuario aterriza en un sitio falso creyendo que hizo clic en el real = phishing
El comienzo es el dominio real, por eso se confía. Reenvía una URL externa sin comprobar desde el parámetro y se convierte en un trampolín.

Defensa: no aceptes URLs externas

1

Permite solo rutas relativas (lo más importante)

Acepta destinos de retorno como /dashboardsolo rutas relativas— y rechaza URLs completas (que empiecen por http:// o //). No dejes margen para que el usuario especifique un dominio de destino.

2

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.

3

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.

4

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: 'baja' por sí sola, pero potente junto al phishing

Las redirecciones abiertas suelen calificarse como bajas por sí mismas, pero como prestan la confianza de tu dominio, se vuelven potentes combinadas con phishing o secuestro de autenticación. Por eso un movimiento a nivel de diseño —rutas relativas + lista de permitidos— elimina la raíz 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.

Sigue leyendo

FAQ

Q¿Por qué es un problema una redirección abierta?
A

El primer dominio de la URL es el tuyo, el real y de confianza (por ejemplo, una página de inicio de sesión), por lo que los usuarios y los filtros de correo hacen clic con confianza. Pero el sitio los reenvía a cualquier sitio externo, así que tu dominio real se convierte en un trampolín para el phishing y en un punto de apoyo para robar tokens en los flujos de autenticación.

Q¿Cuál es la mejor defensa?
A

No aceptes URLs externas como destino de redirección. Para las rutas de retorno tras el inicio de sesión, permite solo rutas relativas (/dashboard) y compáralas con una lista de permitidos (un conjunto fijo de destinos conocidos). Si realmente debes enviar a los usuarios fuera del sitio, muestra una página intermedia que les avise de que están saliendo.

Q¿Basta con comprobar si hay http://?
A

No. Las formas sin esquema (//evil.example), las barras invertidas, la codificación y las URLs confusas basadas en @ eluden todas las comprobaciones ingenuas. En lugar de juzgar la cadena, diseña el sistema para no aceptar nunca una URL externa (rutas relativas + lista de permitidos).