1.- API, un perímetro olvidado

La mayoria del tráfico actual esta asociado a API, todo mundo desarrollando aplicaciones moviles o webapps que consuman API/Endpoint desarrolladas en diferentes tecnologias. En terminos generales el gran olvidado es el inventario y ni hablar de la visibilidad. Shadow APIs, endpoints zombies, versiones desactualizadas que siguen funcionando por alguna app legacy.

2.- Los 6 Riesgos de API según NIST SP 800-228

NIST publicó una referencia de seguridad para APIS "Guidelines for API Protection for Cloud-Native Systems" actualizado a marzo de 2026. Con un enfoque interesante desde el ciclo de desarrollo de vida (pre-runtime y runtime) todo esto en Zerto Trust, olvidate de "son apis internas". A continuación te describo los riesgos :

  1. Falta de visibilidad en el inventario de APIs : no podes proteger lo que no sabés que tenes. NIST hace enfasis de manera especifica en los Shadow/Rogue APIs (Sin documentar, sin revisión de seguridad) y los Zombies/Deprecated APIs (Los clasicos reemplazados, pero nunca apagados, por alguna app legacy que todavia los consume, todo un clasico)
  2. Autorización faltante, debil o insuficiente : Se lleva los laureles, NIST los clasifica en 3 , faltante (no hay control a nivel de objeto), incorrecta( valida el usuario/permisos/recurso equivocado) e insuficiente (autoriza el recurso pero filtra campos privilegiados dentro) . Es la zona del BOLA / BFLA / BOPLA.
  3. Autenticación: Credential Stuffing, fuerza bruta, sin rate limit, tokens débiles o mal validados , cuentas y passwords por defecto.
  4. Consumo no restringido de recursos: Denegación de servicios, degradación , a nivel fisicos abuso de consumo de SMS, cargos, sobreuso de APIs de terceros/IA que se traduce en mas gasto.
  5. Fuga de información sensible a llamantes no autorizados : la respuesta del server y los codigos de estados son utilizados para enumerar recursos.
  6. Verificación insuficiente de los datos de entrada: validar que lo que ingresa el usuario sea lo que la aplicacion espera y que ademas no contenga caracteres considerados "maliciosos".

3.- No podes proteger lo que no conoces.

El inventario no deberia ser un excel, es un descubrimiento continuo, es la respuesta y control de seguridad directo al primer Riesgo de NIST. Identificar todo lo que se tiene funcionando, versiones, metodos permitidos, respuestas , parametros. En ese sentido lo primero que se debe de hacer es generar un inventario de tus APIS/Endpoints en el descubrimiento se puede obtener la respuesta del servidor como se observar en la siguiente imagen image Si es necesario al autenticación, es algo que se tendria que tomar en cuenta para hacer el descubrimiento, si ya tenes un swagger /openapi ya podrias iniciar el inventario. image Puedes agregar un jwt valido o inicar sesion con credenciales de cuentas especificos para el escaneo o pruebas, algo a tomar en cuenta es que la aplicación puede detectar datos PII ( informacion considerada privada / confidencial) en algunos paises por aspectos legales.

4.- Identifica lo crítico para el negocio

Perfecto ahora que se obtuvo el inventario y la visibilidad sobre tus APIs/endpoints, la siguiente pregunta es ¿Cual de los endpoints son criticos para el negocio?, existiran endpoints especificos que posiblemente sean mas críticos que otros, como Application Security / Ciberseguridad deberiamos estar alineados al negocio, o al menos la postura de sguridad deberia apopyar o soportar al negocio, la gestión de riesgo se debe tomar en cuenta el impacto y la probabilidad, adicionalmente la clasificacion de los datos.

image Los Endpoints son cargados desde el inventario, esta tarea no es solo del Analista de Seguridad, tampoco del Desarrollador, aqui debe participar el dueño de la App que deberia conocer los riesgos y por lo menos el nivel de criticidad de su aplicacion en relacion al negocio, es necesario tomar en cuenta si son datos privados, confidenciales, publicos o internos, en este calculo se obtiene un nivel de riesgo. ¿Cual es el objetivo de esto? , segui leyendo, la respuesta esta en el siguiente punto.

5.- Mapea las amenazas : Threat Modeling

Como analista de seguridad en aplicaciones o AppSec, tenemos que ser estrategicos, ya se identificaron los endpoint críticos, ahora mi foco de seguridad debe ser sobre ellos, en otras palabras a que amenazas estan expuestos estos endpoints criticos, y adicional "que controles tengo implementados actualmente sobre estos endpoints", existen problemas a nivel de autenticacion, Rate limit , Acceso no autorizado a datos, etc.

image Podemos seleccionar el endpoint y agregar amenazas manuales con base en el modelado de amenazas de STRIDE, este articulo , te explico sobre la metodologia. Por la amenaza identificada, se puede agregar el control implementado o detectar que es necesario implementar controles, esta visión la genera el modelado de amenazas. image

6.-Validando los controles

Identificado las endpoints criticos, detectadas las amenazas, mapeado los controles ahora es el momento de validar si los controles realmente funcionan (are there control in place ?). Es necesario tomar en cuenta que la verificación de los controles se tiene que hacer sin autenticación y con autenticación, incluso para detectar BOLA (Broken Object Level authorization) es necesario 2 cuentas para hacer las pruebas, en otras palabras al finalizar el modelado de amenazas es hora de ejecutar un escaneo de seguridad sobre los endpoints y analizar el resultado.

API Scan

7.- Leyendo los hallazgos

Es importante tomar como partida una metodologia de evaluación para mapear las vulnerabilidades por ejemplo OWASP TOP TEN API 2023

image Es necesario tomar en cuenta el enfoque, el escenario, no es lo mismo implementar seguridad cuando ya se sufrio un incidente o implementar seguridad desde la concepción del proyecto de implementación de una API, en este articulo puedes encontrar más información.