Una función que recupera el contenido de una URL pegada es una comodidad cotidiana, pero en el peor de los casos expone tus credenciales de la nube. Eso es la SSRF. Aquí tienes cómo funciona y cómo defenderse, desde cero.
Qué ocurre realmente
El acceso normal es «usuario → sitio externo». La SSRF hace que el servidor envíe solicitudes a destinos internos en nombre del atacante. Los servidores pueden alcanzar redes internas y endpoints de credenciales de la nube que son invisibles desde fuera, así que un atacante puede leerlos de forma indirecta.
169.254.169.254 (credenciales de la nube)En la nube, ese endpoint interno (el servicio de metadatos) puede entregar credenciales temporales. Si la SSRF lo alcanza, las credenciales se roban y el ataque lleva a la exfiltración masiva del almacenamiento, que es exactamente lo que ocurrió en la brecha de Capital One (2019): SSRF → metadatos → credenciales IAM → S3.
Dónde se esconde
Cualquier función donde «un servidor recupera una URL proporcionada por el usuario» es candidata.
| Función | Implementación típica |
|---|---|
| Vista previa OG / de enlace | el servidor recupera una URL pegada para construir una miniatura |
| Entrega de webhook | el servidor hace POST a un destino especificado por el usuario |
| Importación de imagen / archivo | «recuperar una imagen desde una URL» |
| Diagnósticos del sitio | el servidor accede al sitio introducido para inspeccionarlo |
Huecos de validación que la gente pasa por alto
«Bloquear las IPs internas» no basta. También debes gestionar estas elusiones.
El bloqueo ingenuo no basta
- Seguimiento de redirecciones: un dominio permitido hace un
302a una dirección interna. - Reenlace de DNS (DNS rebinding): IP externa en el momento de la validación, IP interna en el momento de la recuperación.
- Trucos de codificación de IP: formas decimales/octales/cortas disfrazan una dirección interna.
- Esquemas raros:
file://,gopher://y otros esquemas inesperados.
Cómo defenderte si construyes la función
La SSRF se previene en «cómo construyes la función». Estas son las reglas que este sitio se impone en sus propias funciones de diagnóstico.
Usa una lista de permitidos para los destinos
Restringe el esquema (http/https) y el host a un conjunto permitido únicamente. «Permitir solo estos» es más fiable que «bloquear los internos».
Bloquea los objetivos internos
Deniega la accesibilidad a 127.0.0.1 / 10.x / 192.168.x / 169.254.169.254 (metadatos).
Solo dominios que el usuario posea (para diagnósticos)
Restringe a dominios cuya propiedad haya demostrado el usuario. No dejes que se dirijan a sitios de terceros.
Gestiona las elusiones y protege los metadatos
Valida el destino final de la redirección, ten en cuenta el reenlace de DNS y exige metadatos basados en token (por ejemplo, IMDSv2) en la nube.
Este sitio se construye sobre «no guardar secretos», «diagnosticar solo lo que se ha demostrado poseer» y «minimizar el daño que pueda causar cualquier compromiso» (→ Acerca de este sitio).
SSRF, CSRF y redirección abierta: diferencias
Las tres implican un destino elegido desde fuera, pero difieren en qué se mueve y hasta dónde llega.
| Ataque | Quién va adónde | Qué puede alcanzar |
|---|---|---|
| SSRF | Tu servidor envía una petición al destino que se le indicó | Lugares inalcanzables desde fuera, como la red interna y las credenciales de la nube |
| CSRF | El navegador del usuario envía una petición que el usuario no pretendía | Todo lo que el usuario puede hacer en un sitio donde tiene la sesión iniciada |
| Redirección abierta | El navegador del usuario se reenvía al sitio externo que se indicó | Un sitio falso (phishing) |
La SSRF es especialmente peligrosa porque lo que alcanza está «dentro del servidor». Los lugares que tu cortafuegos protege desde fuera siguen siendo alcanzables a través del servidor.
Casos reales: también se esconde en funciones de los frameworks
La SSRF no aparece solo en funciones de «recuperar esta URL» que escribes tú, sino también en funciones de los frameworks. En los CVE recientes de Next.js, por ejemplo, la SSRF (CWE-918) está entre los tipos de debilidad más comunes, en funciones del servidor como la optimización de imágenes que recuperan imágenes externas (→ vulnerabilidades de Next.js y React en datos reales, en inglés). En el «CWE Top 25» de MITRE (las 25 debilidades de software más peligrosas), publicado en diciembre de 2025, la SSRF ocupa el puesto 22.
En la nube, la brecha de Capital One es el ejemplo de referencia. La SSRF alcanzó el servicio de metadatos y se robaron credenciales temporales con permisos excesivos. En noviembre de 2019, AWS publicó IMDSv2 para reducir este tipo de daño.
Cómo comprobar tu propio entorno
Haz una lista de todos los lugares que recuperan una URL indicada
Busca en tu código clientes HTTP (fetch, axios, requests, etc.) cuyo destino pueda incluir entrada del usuario. Las vistas previas de enlaces, los webhooks, la importación de imágenes, la generación de PDF y las funciones de importación son los casos típicos.
Revisa los ajustes de permisos del framework
En los ajustes de optimización de imágenes o de recuperación externa, comprueba que los hosts permitidos no sean demasiado amplios (en Next.js, que images.remotePatterns no contenga una entrada que sea solo un comodín).
Exige IMDSv2 (AWS)
En las opciones de metadatos de cada instancia EC2, comprueba que HttpTokens está en required (solo IMDSv2). En servidores que no ejecutan contenedores, mantén en 1 el límite de saltos de la respuesta del token.
Restringe el tráfico saliente del servidor
Ejecuta el código que recupera URLs en un entorno aparte que no pueda alcanzar la red interna, o limita el tráfico saliente a los destinos que necesita. Si la validación de la aplicación pasa algo por alto, la red sigue deteniéndolo.
Fuentes (primarias)
- OWASP, «Server-Side Request Forgery Prevention Cheat Sheet» (en inglés) — cheatsheetseries.owasp.org (listas de permitidos, bloqueo de direcciones internas, gestión de redirecciones y DNS)
- AWS, «Use the Instance Metadata Service to access instance metadata» (en inglés) — docs.aws.amazon.com (tokens de sesión de IMDSv2, el ajuste required, límite de saltos)
- AWS Security Blog, «Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities with enhancements to the EC2 Instance Metadata Service» (noviembre de 2019, en inglés) — aws.amazon.com
- Microsoft, «Azure Instance Metadata Service» (en inglés) — learn.microsoft.com (Azure también usa 169.254.169.254)
- MITRE, «2025 CWE Top 25 Most Dangerous Software Weaknesses» (diciembre de 2025, en inglés) — cwe.mitre.org (CWE-918 en el puesto 22)
Sigue leyendo
- Glosario: Qué es RCE · Qué es una CVE
- Fundamentos: Fundamentos de seguridad
- Defensa: Falsificación de X-Forwarded-For y proxies de confianza