SSRF: el ataque que convierte su app en puerta a la nube interna
Un campo "importar desde URL" mal validado puede leer metadata de AWS o escanear su red. Cómo bloquearlo sin matar features legítimas.
Server-Side Request Forgery aparece en OWASP Top 10 y en writeups de Google Security Blog porque es devastadoramente simple: su servidor hace fetch a una URL que el atacante controla — o peor, a 169.254.169.254 para robar credenciales IAM en EC2. Apps de PYMES con "preview de link" o integraciones de scraping son blanco clásico.
Defensas en capas contra SSRF
Defiensa en capas: validar esquema (solo https), bloquear IPs privadas y metadata endpoints, resolver DNS y rechazar rangos internos, usar allowlist de dominios cuando el caso de uso lo permite. Nunca pase URL cruda del usuario a librerías HTTP sin sandbox.
En AWS, IMDSv2 obligatorio y roles con permisos mínimos limitan blast radius si ocurre SSRF. En Vercel/Netlify, entienda qué puede alcanzar su serverless desde la red del proveedor — no asuma aislamiento total.
Pruebas de SSRF en CI
Para equipos pequeños en Puerto Rico: añada test de seguridad en CI que intente fetch a http://127.0.0.1 y metadata IP — debe fallar. Code review checklist de una línea en PRs que toquen HTTP client outbound.
SSRF no es teórico; es cómo pentesters abren camino a data stores internos en horas. Feature útil mal implementada cuesta más que retrasar release una semana por validación correcta.
Escribe sobre ciberseguridad práctica para pymes en Puerto Rico y el Caribe — sin relleno, con lo que realmente hay que hacer.
