Pentest de API: guía por el OWASP API Security Top 10, alcance y qué entregar al equipo
Cómo funciona un pentest de API (REST, GraphQL, gRPC): el OWASP API Security Top 10 como mapa de cobertura, cómo definir el alcance y qué esperar del informe.
Resumen: un pentest de API es la prueba de intrusión centrada en las interfaces que consumen tu frontend, tu app móvil y tus partners: REST, GraphQL, gRPC y webhooks. La referencia de cobertura es el OWASP API Security Top 10 (2023), encabezado por fallos de autorización que los escáneres no detectan. Un buen pentest de API es de caja gris: con especificación OpenAPI, cuentas por rol y al menos dos usuarios por rol.
En los productos modernos la API es el producto. Cualquier control que exista solo en la interfaz se puede saltar llamando directamente a la API; por eso el pentest de API es hoy la prueba con mayor retorno para la mayoría de empresas de software.
El OWASP API Security Top 10 (2023) como mapa de cobertura
| ID | Riesgo | Qué significa para tu negocio |
|---|---|---|
| API1 | Broken Object Level Authorization (BOLA) | un cliente accede a datos de otro cambiando un identificador |
| API2 | Broken Authentication | sesiones, tokens o recuperación de contraseña permiten tomar cuentas |
| API3 | Broken Object Property Level Authorization | campos que el usuario no debería ver ni modificar |
| API4 | Unrestricted Resource Consumption | costes e indisponibilidad por falta de límites |
| API5 | Broken Function Level Authorization | funciones de administración accesibles a usuarios normales |
| API6 | Unrestricted Access to Sensitive Business Flows | automatización abusiva de compras, cupones, registros |
| API7 | Server-Side Request Forgery | el servidor es inducido a acceder a recursos internos |
| API8 | Security Misconfiguration | CORS, cabeceras, mensajes de error, configuraciones por defecto |
| API9 | Improper Inventory Management | versiones antiguas y endpoints olvidados aún activos |
| API10 | Unsafe Consumption of APIs | confianza excesiva en datos de APIs de terceros |
Cuatro de los diez (API1, API3, API5, API6) tratan de autorización y lógica de negocio: la herramienta no sabe qué es "tuyo" y qué es "del otro". El número uno de la lista, en BOLA/IDOR en APIs; los fallos de autenticación más comunes, en errores de JWT y OAuth.
Cómo definir el alcance
El esfuerzo depende menos del número de endpoints y más de cuántas combinaciones objeto × usuario × operación hay que verificar. Reúne:
- Especificación: OpenAPI/Swagger, schema GraphQL, ficheros .proto, colección de Postman.
- Roles y tenants: qué roles existen y si hay multi-tenant.
- Flujos críticos: pagos, transferencias, exportación de datos, invitaciones, cambio de email y contraseña.
- Autenticación: sesión, JWT, OAuth/OIDC, API keys, mTLS.
- Versiones: ¿sigue activa la v1? ¿Hay endpoints internos expuestos por el mismo gateway?
- Entorno: staging con datos realistas o producción con ventana definida.
Una API de hasta ~80 endpoints con 2–4 roles lleva normalmente de 5 a 12 días de prueba; consulta cuánto cuesta un pentest.
Qué entregar al equipo de pentest
- Especificación actualizada, incluidos los endpoints "internos".
- Al menos dos cuentas por rol, en al menos dos tenants si aplica.
- Datos de ejemplo en los flujos críticos.
- IPs del equipo permitidas en el WAF/rate limit de staging.
- Un contacto técnico para dudas rápidas y avisos de hallazgos críticos.
Qué esperar del resultado
- Hallazgos con prueba de concepto reproducible, severidad justificada e impacto en el negocio.
- Cadenas de ataque, no elementos aislados.
- Recomendaciones a nivel de código y arquitectura: autorización centralizada por objeto, filtrado en la consulta a base de datos, listas de campos permitidos en la serialización, límites por usuario y por flujo.
- Retest tras las correcciones.
Cómo prevenir entre pentests
- Tests automáticos de autorización en la CI.
- Inventario vivo de APIs, con fecha de retirada para versiones antiguas.
- Rate limit por usuario y por flujo de negocio, no solo por IP.
- Revisión de seguridad en cada cambio del modelo de datos o de roles.
Preguntas frecuentes
¿Qué diferencia hay entre pentest de API y pentest web?
El pentest web cubre la aplicación vista desde el navegador; el de API se centra en las interfaces llamadas directamente, incluidas las que usan apps y partners. En SPAs modernas se solapan, y el alcance ideal prueba ambas capas.
¿Tengo que entregar la documentación de la API?
No es obligatorio, pero sí muy recomendable: sin documentación, parte del presupuesto se va en descubrimiento; con ella, en ataque.
¿Se puede hacer en producción?
Sí, con ventana, límites de carga y reglas claras sobre operaciones que modifican datos. Siempre que sea posible, preferimos un staging fiel a producción.
¿GraphQL es diferente?
Las clases de riesgo son las mismas, pero la superficie cambia: introspección, consultas anidadas, batching y resolvers con reglas de autorización propias requieren técnica específica.