Tus APIs mueven tus datos. Demostramos quién llega a ellos de verdad.

BOLA (Broken Object Level Authorization, también llamado IDOR) es el fallo grave más habitual en una API: el servidor devuelve un registro sin comprobar que pertenece a quien lo pide. En la práctica significa cambiar un identificador en una petición, por ejemplo del número de tu cuenta al siguiente, y recibir los datos de otra persona. Como los identificadores suelen ser secuenciales, un solo endpoint mal hecho puede exponer a toda tu base de clientes, y por eso ocupa el número uno del OWASP API Security Top 10 y por eso lo probamos de forma exhaustiva.

Un escáner no puede juzgar si una petición debería estar permitida, porque la petición en sí es válida. Cuando un usuario normal lee un registro de administración, la API devuelve un 200 OK normal; a una herramienta nada le parece roto. Decidir que esa respuesta nunca debió llegar a ese usuario exige entender tus roles y tu negocio, y eso es trabajo de una persona. Los escáneres ayudan a cubrir terreno y con los problemas conocidos; no encuentran los fallos de autorización que causan las mayores brechas de API.

No, aunque se solapan. Un pentesting web mira la aplicación que el usuario ve en el navegador; un pentesting de APIs mira la interfaz máquina a máquina que hay detrás, la misma que llaman directamente tu app móvil, tus partners y tus microservicios. Las APIs concentran el riesgo de autorización y de lógica de negocio, y a menudo exponen funciones que el front web no muestra nunca. Si tu producto es API-first o tiene app móvil, la API suele ser el objetivo más importante. Muchos proyectos cubren las dos cosas; en la primera reunión te decimos qué necesita tu caso. Mira también nuestro servicio de pentesting de aplicaciones web.

Probamos los cuatro. REST es el más común, pero GraphQL, gRPC y SOAP tienen cada uno sus propios riesgos: la introspección del esquema y el abuso de consultas en GraphQL, el manejo de mensajes en gRPC y SOAP. Los probamos en sus propios términos, en vez de forzar una lista de REST sobre ellos. Cuéntanos qué tienes en marcha y acotamos en consecuencia.

Una API enfocada con un modelo de roles claro suele llevar de una a dos semanas de pruebas activas; una superficie grande con muchos roles, varios estilos de API o flujos de negocio complejos se va a dos o tres semanas. Una buena documentación y unas cuentas de prueba lo acortan. El calendario lo confirmamos en la propuesta, que entregamos en las 48 horas siguientes a la primera llamada.

El precio sale del alcance: el número de endpoints, el número de roles, los estilos de API implicados y la complejidad de tu lógica de negocio. Damos un precio cerrado, sin costes ocultos y sin obligación de renovar. Una auditoría enfocada a una sola API está en la parte baja del rango; las superficies grandes con muchos roles y varios estilos escalan desde ahí. El retest que confirma tus correcciones va siempre incluido.

Lo ideal es documentación de la API (OpenAPI/Swagger, un esquema de GraphQL o una colección de Postman), dos cuentas de prueba por rol para poder probar la autorización cruzando fronteras, y un entorno de staging o una URL de producción dentro del alcance. Si la documentación está incompleta, seguimos adelante igual: descubrir los endpoints no documentados es parte del valor. Un contacto técnico para las dudas mantiene el proyecto en marcha.

El hacker ético senior al que conoces en la primera llamada lo ejecuta de principio a fin. Nuestros pentesters tienen credenciales OSCP, OSWE y OSEP, trabajan a mano contra el OWASP API Security Top 10, y somos contribuidores verificados del Bug Bounty de la NASA con hallazgos de API publicados. La misma persona acota, ejecuta y re-verifica. Es tu interlocutor durante todo el proyecto.