Herramientas de pruebas de seguridad de API: las cuatro categorías
Escáneres
Sondean en busca de clases de vulnerabilidades conocidas y configuraciones incorrectas.
Amplia cobertura, ningún conocimiento de tus reglas de negocio.
Proxies e interceptores
Permiten que una persona inspeccione y manipule el tráfico.
Potentes y totalmente dependientes de quien los maneja.
Fuzzers
Lanzan entradas malformadas contra los endpoints en busca de caídas.
Encuentran problemas de robustez, generan ruido que hay que clasificar.
La cuarta es la verificación de comportamiento: ¿rechaza la API lo que debería rechazar? Llamadas sin autenticar, accesos entre cuentas, límites de roles, tokens caducados. Ningún escáner puede comprobar esto porque depende de lo que tu producto entienda por permiso.
El hueco que tiene la mayoría de los equipos
Los equipos suelen tener un escáner en el pipeline y una prueba de penetración una vez al año. Ambas cosas sirven. Ninguna comprueba que el endpoint que se publicó el martes pasado aplique autorización a nivel de objeto, y ese es el fallo que más se explota en las API reales.
El motivo por el que nadie lo comprueba es organizativo, no técnico. Parece un asunto de seguridad, así que espera al proceso de seguridad, que se ejecuta cada trimestre. En realidad es una comprobación de comportamiento que corresponde a la suite de pruebas que se ejecuta con cada cambio.
Cómo saber cuál es tu hueco
¿Puedes decir cuándo fue la última vez que alguien verificó que el usuario A no puede leer los datos del usuario B? Si la respuesta es la prueba de penetración anual, eso es una ventana de doce meses sobre tu fallo más probable.
¿Un endpoint nuevo recibe automáticamente una comprobación de permisos? Si depende de que quien lo escribe se acuerde, se va a escapar.
¿Los hallazgos del escáner se clasifican o se acumulan? Un escáner que produce hallazgos que nadie lee es peor que no tener escáner, porque parece cobertura.
Cubrir el hueco de comportamiento
Los planes de API generados incluyen categorías de autorización y de límites, de modo que las comprobaciones de permisos conviven con la cobertura funcional en lugar de ser un ejercicio aparte. Eso las pone en cadencia de cada cambio, que es la única cadencia que sigue el ritmo de los endpoints nuevos.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
La misma configuración está disponible en el panel de TestSprite si prefieres no instalar nada en local. El resto de la superficie del CLI está en el repositorio del CLI.
El funcionamiento se detalla en la documentación de pruebas de API.
La clasificación, o por qué el escáner dejó de importar
Los escáneres fallan de una forma concreta y muy común: siguen funcionando y todo el mundo deja de leerlos. Vale la pena entenderlo porque no es un problema de herramientas.
La primera ejecución produce una lista larga, gran parte de ella no aplicable. Nadie tiene tiempo de revisarla entera, así que se lee por encima. La siguiente ejecución produce la misma lista más dos elementos nuevos, invisibles dentro del ruido ya existente. En un trimestre el informe es un artefacto que se genera y se archiva, y un hallazgo auténtico podría quedarse ahí un año.
La solución no tiene nada de glamurosa: clasifica la primera lista una vez, bien, y silencia lo que no aplica dejando por escrito el motivo. A partir de ahí el informe solo muestra lo que cambió, y eso sí lo lee la gente. Un escáner sin clasificar es peor que ninguno, porque produce la apariencia de cobertura.
Qué ejecutar en cada sitio
Comprobaciones de comportamiento en cada pull request. Escáneres de forma programada. Proxies y fuzzers en manos de alguien que esté haciendo un trabajo dirigido. Una prueba de penetración cuando cambia el modelo de amenazas, no cuando lo dice el calendario.
Si el pipeline es de otro equipo, la GitHub App es el camino de menor resistencia: es un webhook, no cambia nada en tu repositorio y se dispara cuando tu build informa de que la nueva versión está en producción. Si prefieres que la comprobación se vea en el repositorio, un paso de GitHub Actions lo hace.
Qué aporta TestSprite en la cuarta categoría
Verificación de comportamiento: ¿rechaza la API lo que debería rechazar? Los planes generados incluyen categorías de autorización y de límites, de modo que cada endpoint se comprueba frente a accesos sin autenticar, lecturas entre cuentas, límites de roles y credenciales caducadas, con cada cambio.
Funciona contra el servicio en ejecución a través de su interfaz, usando una pasada de descubrimiento más tu especificación para saber qué existe. Auto-Authentication mantiene vivas las sesiones durante toda la ejecución, Dynamic Variables traslada valores entre llamadas, Dependency Chains deriva el orden de ejecución a partir de lo que cada caso necesita y produce, y Auto-Cleanup elimina exactamente lo que la ejecución creó.
La ganancia es que la autorización a nivel de objeto deja de depender de que alguien se acuerde. Tu escáner sigue ocupándose de las clases de dependencias e inyección, tu prueba de penetración sigue ocupándose del abuso creativo, y la categoría que queda entre ambas deja de no ser trabajo de nadie.
¿Es TestSprite una herramienta de pruebas de seguridad de API?
Cubre la categoría de comportamiento: autorización, límites de roles, valores límite e higiene de errores. No es un escáner y no busca clases de vulnerabilidades.
¿Seguimos necesitando un escáner?
Sí. Las vulnerabilidades en dependencias y las clases de inyección son reales, y un escáner es el instrumento adecuado. Las categorías se complementan.
¿Qué es la autorización a nivel de objeto?
Si un usuario puede acceder al registro de otro usuario cambiando un identificador. Es el fallo grave más común en las API y uno de los más fáciles de probar.
¿Cómo frenamos el ruido del escáner?
Clasifica de forma programada y silencia dejando adjunto el motivo. Un backlog sin clasificar es indistinguible de no tener escáner.
¿Se pueden ejecutar las comprobaciones de comportamiento contra producción?
Lo habitual es que la respuesta correcta sea un entorno representativo. Crear y borrar registros en producción para probar permisos tiene su propio riesgo.
La categoría más barata suele ser la que falta.
Las herramientas de pruebas de seguridad de API se dividen en escáneres, proxies, fuzzers y verificación de comportamiento. La mayoría de los equipos tiene la primera y le falta la última, que es donde vive la autorización a nivel de objeto. Ponla en cadencia de cada cambio y deja el escáner en ejecución programada.