Las dos familias de herramientas de seguridad de API
| Protección, en tiempo de ejecución | Gateways, firewalls de aplicaciones web, limitación de tasa, mitigación de bots, gestión de secretos. Reducen lo que llega a tu servicio. Las compran los equipos de plataforma o de seguridad. |
| Verificación, antes de lanzar | Escáneres, fuzzers y comprobaciones de comportamiento sobre autorización y límites. Te dicen qué haría tu servicio. Las compra, o no las compra, el equipo de ingeniería. |
Dónde falla confiar solo en la protección
Un gateway no puede saber que el usuario A no debería poder leer el pedido del usuario B. Eso es una regla de negocio, vive en tu código, y cada petición que la pone a prueba parece completamente legítima en el tráfico. Método correcto, token válido, ruta bien formada.
La autorización a nivel de objeto es el fallo que más se explota en las APIs reales y es justo la clase de fallo que ninguna capa de protección puede ver. Hay que verificarla dentro del servicio, antes de lanzar.
Qué cubre realmente cada familia
Gateways y firewalls: patrones de ataque conocidos, peticiones malformadas, volumen. Valor real, y ciegos ante la lógica.
Limitación de tasa: abuso por volumen. No hace nada contra una única petición maliciosa bien formada.
Gestión de secretos: fugas de credenciales. Ortogonal a todo lo demás que hay aquí y conviene tenerla.
Escáneres: vulnerabilidades en dependencias, clases de inyección, configuración de TLS.
Verificación de comportamiento: si la API rechaza lo que debería rechazar. La más barata y la que más se suele omitir.
Por qué persiste este hueco
Comprobar el comportamiento de la autorización es barato, muy rentable y falta casi siempre, una combinación extraña que merece una explicación.
Cae entre dos responsables. Parece trabajo de seguridad, así que ingeniería da por hecho que el proceso de seguridad lo cubre. Ese proceso consiste en escáneres y una evaluación anual, y ninguno de los dos conoce tus reglas de negocio, así que da por hecho que lo cubren las pruebas. Ambas suposiciones son razonables por separado y el hueco sobrevive durante años.
Designar al responsable resuelve buena parte del problema. Quien escribe el endpoint escribe la comprobación de autorización, en el mismo pull request, como parte normal del trabajo. Así queda en manos de la única persona que sabe quién debería poder ver ese dato, y escala con el número de endpoints en lugar de con el equipo de seguridad.
La comprobación que vale la pena hacer esta semana
Crea dos cuentas. Haz que una cree un registro. Intenta leerlo con el token de la otra. Si te devuelve datos, tienes el fallo grave más común de las APIs, y ningún gateway delante de tu servicio lo habría detenido.
Después automatízala, porque esa comprobación hay que repetirla en cada endpoint nuevo y nadie se va a acordar.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Si prefieres no instalar nada, el panel hace lo mismo. Todo lo demás que puede hacer la línea de comandos está en el repositorio del CLI.
Los planes de API generados incluyen categorías de autorización y de límites, así que estas comprobaciones conviven con la cobertura funcional en lugar de esperar a un ejercicio trimestral. El funcionamiento está en la documentación de pruebas de API.
Conecta el repositorio desde el panel y las ejecuciones parten del despliegue que ya generas, o, en su lugar, añade un paso a tu propio flujo de trabajo.
Qué cubre TestSprite dentro de la familia de verificación
Las comprobaciones de comportamiento que ninguna capa de protección puede hacer: acceso sin autenticar, autorización a nivel de objeto, límites entre roles, credenciales caducadas y entradas fuera de rango. Los planes generados incluyen categorías de autorización y de límites, así que las recibe cada endpoint, incluido el que añadiste la semana pasada.
Funciona contra el servicio en ejecución a través de su interfaz, usando el descubrimiento y tu especificación. Auto-Authentication mantiene vivas las sesiones durante toda la ejecución, Dynamic Variables traslada valores entre llamadas, Dependency Chains deduce el orden de ejecución y Auto-Cleanup elimina exactamente lo que creó la ejecución.
La ganancia está en la cadencia. Estas comprobaciones no son difíciles, pero es fácil olvidarlas en el endpoint número cuarenta, y ejecutarlas en cada cambio es lo que cierra el hueco más explotado de las APIs reales. Tu gateway y tu escáner siguen haciendo aquello en lo que son buenos.
¿Es TestSprite una herramienta de seguridad de API?
Está en la familia de verificación: cubre autorización, límites entre roles y valores límite. No es un gateway ni un escáner de vulnerabilidades.
¿Hacen falta las dos familias?
Sí. La protección reduce lo que te llega; la verificación te dice qué harías con lo que consigue pasar. Ninguna sustituye a la otra.
¿Puede un WAF detectar una autorización rota?
No. La petición es legítima en todos los aspectos que un WAF puede inspeccionar. Solo el servicio sabe quién debería ver ese registro.
¿Por dónde empezar con un equipo pequeño?
Comprobaciones de comportamiento de la autorización en cada endpoint que recibe un identificador. La mayor tasa de acierto, el menor coste, y se ejecuta en tu pipeline actual.
¿Con qué frecuencia debe ejecutarse cada una?
La protección está siempre activa. La verificación corresponde a cada cambio, porque aparecen endpoints nuevos constantemente y cada uno necesita la misma comprobación.
Un gateway no puede conocer tus reglas de negocio.
Las herramientas de seguridad de API o bien protegen una API en ejecución o bien verifican qué haría. La protección es ciega a la lógica de autorización, que es donde vive el fallo que más se explota. Haz la comprobación con dos cuentas y después automatízala.