Una empresa de logística expone una API para que sus clientes consulten el estado de sus envíos. El endpoint no requiere autenticación porque "solo devuelve información pública". Lo que no consideraron es que también acepta un parámetro de ID de cliente que, iterado secuencialmente, devuelve información de todos los clientes en la plataforma. Ningún firewall lo detectó. Ninguna alerta se disparó. La exfiltración duró semanas.
El problema no fue técnico en el sentido complejo. Fue una API diseñada sin pensar en el adversario.
El inventario que nadie tiene
En organizaciones con cierto nivel de madurez digital, las APIs proliferan de forma orgánica. Cada equipo de desarrollo las crea para sus propias integraciones, cada proveedor SaaS las expone para conectarse con otros sistemas, cada migración a la nube deja APIs viejas activas que nadie recuerda haber creado. Según datos de Salt Security, el 94% de las organizaciones reportó haber tenido problemas de seguridad en sus APIs durante 2023, y el vector más común no fue un ataque sofisticado: fue una API que nadie sabía que estaba expuesta.
Sin un inventario actualizado, no hay posibilidad de auditar. Y sin auditoría, el equipo de seguridad opera sobre la suposición de que todo está bien — hasta que no lo está.
Los riesgos que más se materializan
El primero es la autenticación ausente o débil. APIs que no requieren token, que aceptan credenciales por defecto o que exponen endpoints de administración sin protección adicional. En entornos de desarrollo es común encontrar APIs con autenticación deshabilitada "temporalmente" que nunca se volvió a habilitar antes de salir a producción.
El segundo es la exposición excesiva de datos. Una API bien diseñada devuelve exactamente lo que el cliente necesita. En la práctica, muchas devuelven el objeto completo del backend —con campos internos, identificadores técnicos y datos sensibles— porque es más fácil filtrar en el frontend que limitar en el backend. Cuando esa API queda expuesta, también quedan expuestos todos esos campos.
El tercero es la falta de límites de consumo. Una API sin control de tasa de peticiones es vulnerable a enumeración —como el caso de la empresa de logística—, a scraping masivo de datos y a ataques de fuerza bruta sobre parámetros de búsqueda. El atacante no necesita vulnerar nada: solo necesita hacer muchas peticiones válidas.
El cuarto es el ciclo de vida no gestionado. APIs que se crearon para un proyecto piloto, para una integración temporal o para una versión anterior del producto y que siguen activas meses o años después. Nadie las mantiene, nadie las monitorea y nadie sabe si tienen vulnerabilidades conocidas. Son la deuda técnica más silenciosa del ecosistema cloud.
¿Qué hacer al respecto?
El primer paso es construir el inventario. No como proyecto de tres meses: como ejercicio inmediato de reconocimiento. Revisar el tráfico de red saliente, los registros del gateway de APIs si existe, la documentación de desarrolladores y los contratos con proveedores SaaS da una imagen inicial suficiente para empezar a priorizar.
El segundo paso es incorporar seguridad en el ciclo de diseño de APIs, no solo al final. Una API que se diseña desde el principio con autenticación obligatoria, respuesta mínima y control de tasa es significativamente más difícil de explotar que una a la que se le añaden controles después de que ya está en producción. Eso requiere que el equipo de seguridad esté en conversación con desarrollo antes del lanzamiento, no después del incidente.
El tercer paso es monitorear el comportamiento. Una API puede tener todos los controles correctos y aun así ser abusada de formas que no se anticiparon. El tráfico anómalo —peticiones inusualmente frecuentes, patrones de enumeración, accesos fuera de horario desde ubicaciones atípicas— es detectable si hay logging activo y alguien está mirando.
¿Tienes hoy un inventario confiable de todas las APIs activas en tu organización, incluidas las que crearon equipos que ya no existen?
Acciones inmediatas
- Solicita al área de desarrollo un listado de todas las APIs activas en producción, incluyendo las internas. Compara ese listado con el tráfico real que registra tu infraestructura de red. La diferencia entre ambos es tu inventario de APIs no documentadas, que es también tu mayor punto ciego de seguridad.
- Verifica que ninguna API pública opere sin autenticación, incluso si "solo devuelve datos públicos". La autenticación no es solo para proteger datos sensibles: es para saber quién consume la API, con qué frecuencia y desde dónde. Sin ese registro, no hay visibilidad ante un abuso.
- Revisa si tus APIs tienen controles de tasa de peticiones configurados y activos. Un endpoint sin rate limiting es una invitación abierta a la enumeración y al scraping. Este control es técnicamente simple de implementar y elimina una clase completa de ataques oportunistas.
- Identifica APIs que fueron creadas para proyectos temporales o versiones anteriores y que siguen activas. Pregunta a los equipos de desarrollo si cada API en el inventario tiene un propietario actual. Las que no lo tienen son candidatas inmediatas a revisión o desactivación.
- Revisa qué datos devuelven tus APIs más expuestas en comparación con lo que el consumidor realmente necesita. Si la respuesta incluye campos internos, identificadores técnicos o información de otros registros además del solicitado, existe un riesgo de exposición excesiva que puede corregirse sin cambiar la funcionalidad.
Si tu organización quiere evaluar la postura de seguridad de sus APIs o establecer controles en el ciclo de desarrollo, contáctanos en https://tbsek.mx/contacto/.
