Hay una frase que aparece en casi todas las reuniones técnicas donde se discute la seguridad de una integración: «esa API es interna, no está expuesta». En los últimos años hemos auditado bastantes sistemas donde esa frase era cierta el día que se escribió y había dejado de serlo mucho antes de que alguien se diera cuenta. Un balanceador reconfigurado, un contenedor con los puertos mapeados a la interfaz equivocada, una regla de firewall abierta para depurar un viernes por la tarde, un entorno de preproducción con DNS público que nadie recuerda haber creado.
Las APIs se han convertido en el sistema circulatorio de cualquier empresa con algo de tecnología. Conectan el ecommerce con el ERP, el CRM con la herramienta de facturación, la app móvil con el backend, el portal del cliente con el almacén. Y a diferencia de una web, no tienen interfaz visible: cuando algo va mal, no hay una página rota que avise. Un endpoint mal protegido puede estar entregando datos durante meses sin que nadie note nada raro en el panel de analítica.
Este artículo trata la seguridad de las APIs empresariales desde el ángulo que más nos piden en auditoría de seguridad de las APIs: cómo se acaban exponiendo sistemas que se creían privados, qué tipos de ataque toleran peor, por qué la denegación de servicio contra una API se parece poco al DDoS clásico, y cómo una revisión periódica reduce la probabilidad de que un martes cualquiera se convierta en una crisis. Si buscas los fundamentos de autenticación y limitación de peticiones, los cubrimos en la guía de seguridad en APIs REST: autenticación, rate limiting y buenas prácticas; aquí vamos al plano de la exposición y la resiliencia.
1. El inventario: el punto ciego de la seguridad de APIs empresariales
La primera pregunta de cualquier revisión de seguridad de APIs empresariales es también la más incómoda: ¿cuántas APIs tenéis? La respuesta honesta suele ser un número aproximado. Y esa aproximación es el problema, porque no se puede proteger lo que no se sabe que existe.
En la práctica aparecen tres categorías que conviene nombrar bien:
- APIs conocidas y gobernadas. Están documentadas, pasan por el gateway, tienen dueño y versión. Son las que todo el mundo tiene en la cabeza cuando dice «nuestra API».
- Shadow APIs. Endpoints que alguien creó para una integración concreta, un piloto o una migración, y que nunca entraron en el inventario. Funcionan, reciben tráfico y no los vigila nadie.
- Zombie APIs. Versiones antiguas que se suponían retiradas pero siguen respondiendo. Son especialmente peligrosas porque suelen tener la lógica de autorización de hace tres años y no reciben parches.
El ejercicio de inventario es tedioso y siempre da sorpresas. Se hace cruzando cuatro fuentes: la configuración del balanceador y del gateway, los registros de acceso reales de los últimos meses, los repositorios de código y el DNS de la organización. Cuando esas cuatro listas no coinciden —y nunca coinciden— la diferencia es exactamente tu superficie de ataque desconocida.
2. Cómo se expone una API que «no estaba expuesta»
2.1 La regla temporal que se vuelve permanente
Un desarrollador necesita probar contra el entorno real, se abre un puerto desde su IP, la incidencia se resuelve y la regla se queda. Meses después esa IP pertenece a otra persona o la regla se copió a otro grupo de seguridad al clonar la infraestructura. La forma de detectarlo no es preguntar, es revisar: una auditoría periódica de reglas de firewall y grupos de seguridad, comparando lo que hay con lo que debería haber.
2.2 Contenedores con puertos mal mapeados
Este es probablemente el más frecuente en infraestructuras modernas. Un contenedor lanzado con el puerto publicado en todas las interfaces en lugar de en localhost, sobre un host con IP pública:
# Expone el servicio a internet si el host tiene IP pública
docker run -p 8080:8080 mi-api
# Solo accesible desde el propio host
docker run -p 127.0.0.1:8080:8080 mi-apiLo agrava que muchas configuraciones de firewall a nivel de sistema quedan puenteadas por las reglas que el motor de contenedores inserta automáticamente, así que el administrador ve el puerto cerrado en su configuración y abierto desde fuera.
2.3 Documentación que hace de mapa
Un esquema OpenAPI o un panel de exploración publicado en producción no es una vulnerabilidad por sí mismo, pero convierte el reconocimiento del atacante en un paseo: le entrega la lista completa de endpoints, parámetros y estructuras de datos. Si además incluye endpoints administrativos que sí responden, el problema deja de ser informativo.
2.4 Entornos de prueba con vida propia
Staging suele tener menos controles, menos parches y, con demasiada frecuencia, una copia de los datos reales. Cuando además comparte red o credenciales con producción, se convierte en la puerta lateral preferida. Es exactamente el escenario que los controles técnicos de ISO 27001 intentan evitar exigiendo separación de entornos, como explicamos en el artículo sobre desarrollo seguro según ISO 27001 y el ENS.
3. Los ataques que peor tolera la seguridad de APIs empresariales
3.1 Autorización rota a nivel de objeto
Sigue siendo el fallo número uno en APIs, y por un margen amplio. El endpoint verifica que hay un token válido, pero no que ese token tenga derecho sobre el recurso pedido. Cambiando un identificador en la URL se accede a datos ajenos. No lo detecta ningún escáner automático porque, desde fuera, una respuesta correcta con datos de otro cliente es indistinguible de una respuesta correcta.
3.2 Exposición excesiva de datos
La API devuelve el objeto completo de base de datos y confía en que el cliente muestre solo lo que corresponde. El frontend pinta el nombre y el email; la respuesta JSON incluye además el DNI, el histórico de pedidos y un identificador interno útil para el siguiente ataque. La corrección es sencilla de enunciar y laboriosa de aplicar: serializar explícitamente los campos que salen, nunca el modelo entero.
3.3 Abuso de lógica de negocio
No hay ninguna vulnerabilidad técnica: el atacante usa la API exactamente como está diseñada, pero a una escala o en un orden que nadie previó. Consultar el endpoint de disponibilidad de stock cien mil veces para reconstruir el inventario completo de la competencia. Repetir la validación de cupones hasta encontrar uno válido. Iniciar mil procesos de devolución simultáneos para provocar una inconsistencia contable. Estos casos solo se descubren pensando como el negocio, no como el firewall.
3.4 Denegación de servicio a nivel de aplicación
Aquí está la diferencia más importante respecto al DDoS clásico. Un ataque volumétrico busca saturar el ancho de banda con terabits por segundo y lo absorbe una red de mitigación en el borde. Un ataque de agotamiento de recursos contra una API hace lo contrario: pocas peticiones, perfectamente legítimas, deliberadamente caras.
Ejemplos habituales: una consulta con paginación abierta que pide cien mil registros de golpe; un endpoint de búsqueda con comodines que fuerza un escaneo completo de tabla; una consulta GraphQL profundamente anidada que multiplica las resoluciones; la subida de un archivo comprimido que se expande en memoria; o simplemente el endpoint de exportación a PDF invocado en paralelo cincuenta veces.
Ninguna de esas peticiones dispara una alarma volumétrica. El tráfico total puede ser de unos pocos megabits. Pero la base de datos se queda sin conexiones, el pool de trabajadores se agota y la tienda deja de responder. Las defensas son distintas: límites máximos de paginación, tiempo de espera y coste máximo por consulta, cuotas por token además de por IP, colas para lo que sea pesado y aislamiento de los endpoints caros para que no compartan pool con los críticos.
4. Por qué la auditoría técnica baja el riesgo de crisis
Una crisis relacionada con la seguridad de APIs empresariales rara vez viene de un fallo espectacular. Viene de la suma de tres o cuatro decisiones razonables tomadas en momentos distintos por personas distintas, ninguna de las cuales tenía la foto completa. La auditoría técnica sirve precisamente para reconstruir esa foto completa cada cierto tiempo.
4.1 Qué mira una auditoría de APIs
Una revisión seria de la seguridad de APIs empresariales cubre seis bloques. El inventario y la exposición: qué hay publicado de verdad, comparado con lo que se cree tener. La autenticación y la autorización: cómo se emiten y validan los tokens, cuánto viven, si hay comprobación de propiedad recurso a recurso. Los límites y cuotas: si existen, si son por token o solo por IP, y qué pasa cuando se superan. La gestión de datos: qué campos salen realmente en cada respuesta y qué se registra en los logs (más de una vez encontramos tokens completos escritos en texto plano en los registros). La resiliencia: comportamiento bajo carga, tiempos de espera, reintentos y degradación. Y la observabilidad: si existen trazas suficientes para detectar un abuso en curso y reconstruir después qué ocurrió.
4.2 El valor está en el orden, no en la lista
Un informe que entrega ochenta hallazgos sin priorizar es casi tan inútil como no tener informe. Lo que cambia la conversación con dirección es poder decir: de estos ochenta, cuatro permiten acceder a datos de clientes hoy mismo, doce dejan caer el servicio con un script de veinte líneas, y el resto son mejoras de fondo que caben en el trabajo de los próximos dos trimestres. Esa priorización por riesgo real y por esfuerzo de corrección es lo que convierte una auditoría en un plan.
4.3 Lo que cuesta no hacerlo
Merece la pena poner los costes uno al lado del otro. Una auditoría técnica de un conjunto de APIs de tamaño medio es un proyecto acotado de unas semanas. Un incidente con exposición de datos personales implica investigación forense, notificación a la autoridad de control en 72 horas, comunicación a los afectados si el riesgo es alto, posible expediente sancionador, parón del equipo durante semanas y un impacto reputacional que no aparece en ninguna factura pero se nota en el pipeline comercial durante meses. La proporción entre ambos números no admite mucho debate.
¿Sabes cuántas APIs tienes realmente publicadas?
En Keliam levantamos el inventario real de tus APIs, comprobamos qué está expuesto de verdad y probamos cómo se comporta bajo abuso y bajo carga. Te entregamos los hallazgos ordenados por riesgo y un plan de corrección ejecutable por tu equipo.
5. Controles que marcan la diferencia en la seguridad de APIs empresariales
Del conjunto de recomendaciones posibles para la seguridad de APIs empresariales, estas siete son las que más impacto tienen por unidad de esfuerzo en una empresa que parte de una situación normal.
5.1 Todo el tráfico pasa por el gateway
Sin excepciones «temporales». Un gateway que ve el 70% del tráfico da una falsa sensación de control, porque los problemas viven precisamente en el 30% restante. El gateway aporta además el inventario vivo: lo que no está registrado, no responde.
5.2 Autorización comprobada en el servidor, recurso a recurso
Nunca confiar en un identificador que llega del cliente sin verificar la propiedad. Es el control que más incidentes graves previene y el que peor cubren las herramientas automáticas, así que necesita revisión humana y pruebas específicas con dos cuentas distintas.
5.3 Límites por identidad, no solo por IP
El límite por IP se esquiva con un proxy rotatorio y castiga injustamente a clientes que salen por NAT corporativo. Limitar por token o por cliente identificado es mucho más preciso, y permite además detectar comportamiento anómalo de una cuenta concreta.
5.4 Presupuesto de coste por petición
Paginación con tope duro, profundidad máxima de consulta, tiempo de espera por operación y rechazo explícito de peticiones que superen ese presupuesto. Es la defensa concreta contra el agotamiento de recursos descrito antes.
5.5 Respuestas con esquema explícito
Definir qué campos salen en cada respuesta en lugar de serializar el modelo completo. Evita la exposición excesiva de datos y, de paso, hace que los cambios en el modelo no rompan a los clientes.
5.6 Registros útiles y sin secretos
Registrar identidad, endpoint, código de respuesta y latencia por petición, con retención suficiente para investigar. Y filtrar tokens, contraseñas y datos personales antes de escribir. Sin logs no hay detección temprana ni reconstrucción posterior, como explicamos al hablar de por dónde empezar en ciberseguridad empresarial.
5.7 Retirada ordenada de versiones
Anunciar la fecha, medir quién sigue llamando a la versión antigua, avisar a esos clientes y apagar de verdad. Una API zombie es deuda de seguridad acumulándose en silencio.
6. Encaje con ISO 27001, ENS y NIS2
Si tu organización está en un proceso de certificación o trabaja con el sector público, casi todo lo relativo a la seguridad de APIs empresariales ya está exigido en algún control. Los controles técnicos de ISO 27001 cubren control de acceso, criptografía, seguridad en redes y desarrollo seguro, que es donde caen los puntos 5.1 a 5.5. El Esquema Nacional de Seguridad añade la protección de las comunicaciones y de los servicios, junto con la monitorización, que es el punto 5.6. Y para las entidades dentro del ámbito de NIS2 se suma la obligación de notificar incidentes en plazos cortos, lo que en la práctica solo es viable si la observabilidad estaba resuelta antes.
La lectura útil de esto es que no estás haciendo dos trabajos. Montar bien la seguridad de las APIs genera, casi como efecto colateral, la mayor parte de la evidencia que pedirá el auditor.
7. Conclusión
La seguridad de APIs empresariales importa porque las APIs concentran hoy el mayor volumen de datos sensibles en movimiento de la mayoría de empresas, y son el componente que peor se documenta y peor se inventaría. La combinación es mala: mucha superficie, poca visibilidad. La respuesta no es una herramienta, es una rutina: saber qué tienes publicado, verificar la autorización recurso a recurso, poner presupuesto de coste a cada petición, registrar lo suficiente para enterarte y revisarlo todo con periodicidad.
Los incidentes que se convierten en crisis casi nunca eran imprevisibles. Eran invisibles, que es distinto. Una auditoría técnica periódica es, sobre todo, un ejercicio de recuperar visibilidad antes de que la recupere otro por ti.
8. Preguntas frecuentes
¿Basta un WAF para la seguridad de APIs empresariales?
No. Un WAF detecta patrones de ataque conocidos y ayuda mucho contra lo genérico, pero no sabe qué usuario debería ver qué recurso ni distingue un uso legítimo de un abuso de lógica de negocio. Es una capa necesaria, no un sustituto de la autorización en la aplicación.
¿Cómo detecto si tengo shadow APIs?
Cruzando los registros reales de tráfico del balanceador con el inventario declarado y con el DNS de la organización. Todo lo que reciba peticiones y no esté en el inventario es candidato. Es uno de los primeros ejercicios de cualquier auditoría técnica.
¿Puede una API caerse sin un ataque volumétrico?
Con facilidad. Unas pocas peticiones muy caras —consultas sin límite de paginación, búsquedas con comodines, exportaciones masivas— agotan conexiones de base de datos o memoria con un consumo de ancho de banda mínimo. Por eso los límites deben medir coste, no solo número de peticiones.
¿Con qué frecuencia conviene revisar la seguridad de APIs empresariales?
Una revisión técnica completa al año, y una verificación del inventario y de la exposición cada trimestre, que es mucho más ligera. Además, cualquier cambio de arquitectura, nueva integración con un tercero o migración de infraestructura justifica una revisión puntual.
