En organizaciones con varios squads y autonomía de despliegue, es sorprendentemente fácil que aparezcan Shadow APIs: endpoints reales en cloud que procesan datos y autentican usuarios, pero que no están en el inventario de seguridad, no pasan por el WAF “corporativo” y muchas veces ni siquiera por el proceso de revisión. No hablamos de “servicios olvidados” en abstracto; hablamos de rutas HTTP vivas que alguien puso en producción para “salir del paso” y que se quedaron.
La combinación más común que veo en empresas: desarrolladores publican directamente en API Gateway (o exponen un App Engine) porque es rápido, y el equipo de seguridad asume que “todo lo externo” entra por el balanceador/WAF central. Ese supuesto rompe en cuanto existe un endpoint alternativo con DNS propio, un stage de testing accesible o un default hostname del proveedor cloud.
Qué salió mal: el día que el WAF “no vio nada”
El patrón suele repetirse. Seguridad recibe alertas por exfiltración de datos o por un token usado desde geografías anómalas, revisa logs del WAF central y “no hay nada”. Mientras el SOC persigue fantasmas, el atacante está golpeando un endpoint que no está detrás de ese WAF: un api-gw creado por un equipo de producto, o una app en App Engine con reglas por defecto.
En una empresa, esto se traduce en horas (o días) de investigación mal enfocada. Los incident responders miran donde tienen telemetría: CDN/WAF, reverse proxy corporativo, SIEM con fuentes “estándar”. El problema es que la Shadow API está generando tráfico en otra capa, con otros logs y otros owners. El resultado práctico: contención tardía y decisiones basadas en datos incompletos.
Además, estas APIs suelen nacer con decisiones de “modo entrega”: autenticación parcial, scopes demasiado amplios o validaciones de entrada mínimas. Si el endpoint quedó fuera del control central, también quedó fuera de las políticas que sí se aplican al front door: rate limiting, detección de bots, reglas anti-inyección y trazabilidad uniforme.
Señales tempranas: pistas técnicas que suelen aparecer antes del incidente
Antes de que explote un incidente, casi siempre hay señales. La dificultad está en que no aparecen en un solo panel; aparecen como pequeñas inconsistencias entre inventarios, DNS, y telemetría de red. Cuando las conectas, ves el “contorno” de una Shadow API.
Estas son pistas que en entornos corporativos suelen repetirse (y conviene tratarlas como trabajo de higiene, no como “cacería puntual”):
- Dominios y subdominios que resuelven a endpoints del proveedor cloud (hostnames por defecto o CNAME hacia API Gateways/servicios gestionados).
- Proyectos/cuentas con servicios HTTP habilitados sin owner claro o con tags incompletos (cost center, entorno, datos).
- Tráfico egress hacia “servicios propios” que no están en el catálogo, detectado por proxy corporativo, VPC Flow Logs o equivalent.
Si encuentras dominios que apuntan a un API Gateway “paralelo”, la consecuencia real es que cualquier control del WAF central es irrelevante para ese tráfico. En auditorías internas, esto suele terminar como hallazgo por “falta de control compensatorio” y, peor, como brecha de monitorización: no es que el WAF falle, es que nunca estuvo en el camino.
Si el problema es de ownership y tags, el riesgo se vuelve operativo: nadie rota secretos, nadie revisa permisos IAM, y nadie sabe qué datos pasan por ahí. En incidentes, esa falta de ownership se traduce en parálisis: se tarda demasiado en decidir si apagar el endpoint rompe algo crítico o si está “muerto”.
API pública vs API interna expuesta por SSRF: el matiz que cambia la prioridad
No todas las Shadow APIs son “públicas” en el sentido clásico. Un caso especialmente peligroso es la API interna (pensada para consumo desde la red privada o desde workloads internos) que termina siendo alcanzable indirectamente por un vector como SSRF (Server-Side Request Forgery) desde una aplicación expuesta a Internet.
En empresa, esto pasa cuando un servicio frontend (público) tiene alguna funcionalidad que hace fetch de URLs (webhooks, importadores, previsualizaciones, callbacks) y no valida destinos. El atacante no necesita que la API interna sea pública; le basta con que el frontend pueda llamar a esa API desde su posición de red. En entornos cloud modernos, ese “puente” es frecuente porque los permisos de red internos son más permisivos que los externos.
Consecuencia práctica: tu priorización cambia. Una Shadow API “solo interna” puede parecer baja prioridad si miras únicamente exposición directa. Pero si existe un flujo SSRF plausible, pasa a ser una ruta de escalada: acceso a endpoints admin, metadata, servicios de configuración o APIs de datos sin los controles que el tráfico externo sí tendría.
En el triage real, conviene separar dos preguntas: (1) ¿es accesible desde Internet? (2) si no lo es, ¿qué componentes expuestos podrían pivotar hacia ella? Esa segunda pregunta es donde muchas organizaciones fallan, porque su inventario de APIs internas es difuso y su modelado de amenazas se queda en el perímetro.
Cómo hacerlo en la práctica: descubrir Shadow APIs con Cloud Asset Inventory + enumeración
La forma más consistente de descubrir Shadow APIs no es “escanear Internet” a ciegas, sino cruzar inventario cloud con superficie HTTP observable. En Google Cloud, Cloud Asset Inventory te permite listar recursos y sus metadatos a nivel de organización/proyecto. En AWS/Azure hay equivalentes, pero aquí el enfoque operativo es el mismo: inventariar recursos que pueden exponer HTTP y luego validar accesibilidad y rutas.
Un flujo práctico que funciona bien en corporativo:
- Inventariar recursos candidatos: API Gateways, App Engine services, Cloud Run services, load balancers, ingress de Kubernetes, endpoints gestionados. El objetivo no es perfecto; es tener un “universo” inicial.
- Normalizar ownership y exposición: para cada recurso, capturar proyecto/cuenta, etiquetas, entorno, DNS asociado, y si está (o no) detrás del WAF/proxy corporativo. Aquí suele aparecer el primer 80% de Shadow APIs: “existen pero nadie las registró”.
- Enumerar endpoints reales: usar herramientas de descubrimiento (por ejemplo, soluciones tipo Gorky/APISec u otras de inventario/descubrimiento de APIs) para detectar rutas, métodos y versiones, y compararlas con lo que el equipo cree que existe (OpenAPI/Swagger en repos, catálogos internos, etc.).
Inventariar no es suficiente si no pasas a verificación. En la práctica, verificación significa: resolver DNS, revisar certificados/TLS, identificar hostnames por defecto del proveedor y confirmar qué responde. Es habitual encontrar stages “dev” o “test” sin auth robusta o con API keys embebidas en clientes internos.
Donde Cloud Asset Inventory aporta más valor es en la cobertura: aunque el endpoint no tenga DNS público “bonito”, el recurso existe y deja huella. La enumeración (con herramientas especializadas) aporta la otra mitad: qué rutas existen y qué comportamiento exponen. Esa combinación es la que convierte “tenemos recursos” en “tenemos endpoints”, que es lo que seguridad necesita para modelar riesgo y poner controles.
Si necesitas un control técnico verificable (y auditable) en Google Cloud para reducir el shadowing por bypass del front door, una medida concreta es impedir, por política de organización, que se creen servicios con exposición pública fuera de los patrones aprobados. Un ejemplo de política de Organization Policy para evitar IPs públicas en instancias de Compute Engine (no resuelve todo, pero reduce la superficie paralela) sería:
- Restringir IPs públicas en VM: usar la constraint
compute.vmExternalIpAccesspara denegar IP externa salvo excepciones justificadas.
La validación aquí no es “confiar” en que la política existe: es verificarla en el árbol de organización (org/folder/project), comprobar excepciones y revisar si hay recursos legacy con IP externa por herencia o por permisos previos. En paralelo, debes cubrir servicios gestionados (API Gateway/App Engine/Cloud Run) con políticas y guardrails equivalentes, porque la exposición pública no siempre pasa por una IP de VM.
Recomendaciones para entornos corporativos
Shadow APIs en cloud suelen nacer por velocidad de entrega y por caminos de despliegue alternativos al WAF central (API Gateway/App Engine/servicios gestionados). El impacto real no es solo “más superficie”: es pérdida de visibilidad, respuesta a incidentes más lenta y controles inconsistentes entre equipos.
Para descubrir endpoints que ni seguridad sabe que existen, funciona mejor un enfoque combinado: inventario con Cloud Asset Inventory para encontrar recursos capaces de exponer HTTP, y enumeración/control de rutas con herramientas de descubrimiento de APIs (por ejemplo, Gorky/APISec u otras equivalentes en tu stack). El objetivo es cerrar la brecha entre “recursos desplegados” y “endpoints accesibles”, incluyendo el matiz crítico de APIs internas que pueden volverse alcanzables vía SSRF.
Operativamente, lo que más reduce reincidencia es tratarlo como un problema de plataforma: ownership/tags obligatorios, rutas de despliegue aprobadas, y políticas verificables que eviten exposiciones públicas fuera del patrón corporativo. Si no puedes medir y listar tus endpoints reales, no puedes defenderlos de forma consistente.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.
Francisco Sepúlveda
Instructor de Cloud Computing y Ciberseguridad, Diseñador de Experiencias Formativas
Instructor y consultor en Cloud Computing, Ciberseguridad e IA, con más de 25 años de experiencia en entornos empresariales reales. Diseño e imparto programas de formación técnica combinando experiencia profunda en la materia con diseño de experiencias formativas, para que los conceptos complejos de seguridad realmente se queden. Comparto análisis técnico aplicado en Cloud Security in Practice.
Conoce más →