Checklist de pruebas de seguridad de API, con quién verifica qué

El checklist de pruebas de seguridad de API, agrupado por quién lo verifica

Cubierto por la verificación funcional automatizada

Son verificaciones de comportamiento: ¿responde la API correctamente a una solicitud que debería rechazar? Pertenecen a tu suite habitual y deberían ejecutarse en cada cambio.

• El acceso sin autenticación se rechaza. Cada endpoint protegido, invocado sin credenciales, devuelve el rechazo que corresponde en lugar de datos.

• La autorización se aplica a nivel de objeto. El usuario A no puede leer ni modificar los registros del usuario B cambiando un identificador en la ruta. Es la vulnerabilidad más explotada en las API reales y es una simple verificación de comportamiento.

• Los límites de los roles se respetan. Un rol de solo lectura no puede escribir. Un token expirado o revocado se rechaza.

• La validación de entrada rechaza valores fuera de rango. Casos límite en cada parámetro, incluidos los que nadie documenta.

• Los errores no filtran detalles internos. Los stack traces, los fragmentos de consultas y los nombres de host internos no aparecen en las respuestas.

Requiere un escáner o una herramienta especializada

• Vulnerabilidades en dependencias y librerías.

• Tipos de inyección: SQL, de comandos, de plantillas, de deserialización.

• Configuración de TLS y manejo de certificados.

• Sondeo de CVE conocidos contra tu stack.

Requiere una persona

• Abuso de la lógica de negocio. Pedir una cantidad negativa, repetir un descuento, saltarse un paso en un flujo que daba por sentado el orden.

• El modelado de amenazas, y decidir cuáles son en realidad los datos sensibles.

• Cualquier cosa que exija creatividad sobre cómo alguien usaría mal tu producto.

El punto que todos se saltan

La autorización a nivel de objeto es el punto que más veces falta y el más fácil de comprobar. Crea dos cuentas, haz que una cree un registro e intenta leerlo con el token de la otra. Si eso devuelve datos, tienes la vulnerabilidad grave más común de la industria en las API, y basta una prueba para encontrarla.

Automatizar esto justifica todo el esfuerzo, porque la verificación hay que repetirla en cada endpoint nuevo y ninguna persona se va a acordar de hacerlo.

Cómo lograr que la mitad automatizable se ejecute de verdad

Los planes de API generados incluyen categorías de autorización y de casos límite, así que estas verificaciones conviven con tu cobertura funcional en lugar de ser un ejercicio de seguridad aparte que nadie agenda.

El dashboard cubre lo mismo para quien no quiera una instalación local, y el conjunto completo de comandos está en el repositorio del CLI.

Los detalles de funcionamiento están en la documentación de pruebas de API.

Las dos cuentas que deberías mantener de forma permanente

Casi todos los puntos de comportamiento de esta lista necesitan dos usuarios, y lo más barato que puedes hacer es mantener un par de cuentas de prueba en cada entorno en lugar de crearlas en cada prueba.

Haz que se diferencien en lo que a tu producto le importa: distintos propietarios, distintos roles si los tienes, e idealmente distintas organizaciones. Así cada verificación de autorización se convierte en una prueba de dos líneas en vez de un ejercicio de preparación, y la gente sí las escribe.

La versión que no funciona es crear las cuentas dentro de cada prueba. Es más lenta, deja datos atrás y hace que la verificación dependa de que tu flujo de registro funcione, de modo que un registro roto pone en rojo todas las pruebas de permisos por el motivo equivocado. Cuentas permanentes, creadas una sola vez, eliminan todo eso.

Frecuencia por grupo

Las verificaciones de comportamiento, en cada cambio. Los escáneres, de forma programada y en cada lanzamiento. La revisión humana, cuando cambia el modelo de amenazas, es decir, cuando agregas un nuevo tipo de dato o un nuevo tipo de usuario.

Conecta el repositorio desde el dashboard y las ejecuciones parten del despliegue que ya generas, o bien agrega un paso a tu propio flujo de trabajo.

Cómo cubre TestSprite el tercio automatizable

Los planes de API generados incluyen categorías de autorización y de casos límite, así que los puntos de comportamiento de esta lista conviven con tu cobertura funcional en lugar de ser un ejercicio aparte que alguien tiene que agendar.

Eso significa que el acceso sin autenticación, la autorización a nivel de objeto, los límites de los roles, los tokens expirados y las entradas fuera de rango se verifican en cada cambio, contra el servicio en ejecución y en cada endpoint, incluidos los que se agregaron la semana pasada. 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 creó la ejecución.

El valor está en la frecuencia, no en la sofisticación. Estas verificaciones no son difíciles de escribir; son difíciles de recordar cuando vas por el endpoint número cuarenta. Que se generen y se ejecuten de forma continua es lo que cierra la brecha más explotada en las API reales sin sumar un proceso que alguien tenga que seguir.