Pentesting de APIs (REST y GraphQL): guía técnica para empresas

Un pentesting de APIs es una auditoría ofensiva sobre las interfaces de programación que tu organización expone hacia clientes web, móviles, partners B2B o microservicios internos. Hoy las APIs son el corazón de cualquier producto digital: el frontend, la app móvil y los procesos back-office consumen exactamente los mismos endpoints, y los atacantes lo saben. Por eso un pentesting moderno ya no se acaba en la capa web, llega hasta cada endpoint REST o GraphQL y comprueba autenticación, autorización por objeto, lógica de negocio, manejo de tokens, paginación abusiva y exposición de datos.

Esta guía cubre qué es un pentesting de APIs, en qué se diferencia REST de GraphQL desde la perspectiva ofensiva, los bugs más explotados según el OWASP API Security Top 10 vigente, la metodología que aplicamos y cómo encaja en NIS2, DORA, ISO 27001 y PCI DSS.

Qué es un pentesting de APIs

Un pentesting de APIs es un ejercicio ofensivo autorizado y acotado sobre los endpoints REST, GraphQL, gRPC o SOAP que una organización expone, internos o públicos. El objetivo no es validar que los endpoints "responden 200", sino demostrar qué peticiones legítimas a primera vista permiten a un atacante leer datos que no le tocan, escribir donde no debe, escalar permisos, abusar de la lógica de negocio o reventar la cuota de un servicio aguas abajo.

A diferencia de un escáner automático tipo Nuclei o Postman security checker, un pentesting de APIs profesional:

• Audita autorización por objeto en cada recurso, no sólo el login. La inmensa mayoría de los bugs API críticos son de autorización, no de autenticación.
• Encadena llamadas para reproducir flujos reales. Una secuencia "login → consulta de pedido → cambio de dirección → pago" es donde se esconden los bugs de lógica de negocio.
• Audita la documentación implícita: si tu API expone un Swagger / OpenAPI / GraphQL introspection, el equipo lo descarga y lo cubre completo. Si no, se hace fuzzing y reverse engineering desde el cliente.
• Entrega prueba de concepto reproducible con la petición exacta, el response y el script para reproducir.
• Justifica severidad CVSS según impacto en negocio, no según una tabla genérica.

La duración típica varía mucho: una API REST simple con 30 endpoints se cubre en 5-7 días laborables; una API GraphQL madura con introspection desactivada y federación de servicios puede llegar a 15-20 días.

Por qué hacer pentesting de APIs

Tres datos que cualquier CISO ya conoce y que están convirtiendo el pentesting de APIs en obligatorio:

1. Las APIs son hoy el principal vector de fuga de datos. Los informes anuales de IBM, Verizon DBIR y Akamai sitúan los ataques contra APIs como el segmento que más rápido crece, con incidentes documentados en banca, salud y e-commerce que empiezan en un endpoint mal autorizado y terminan en exfiltración masiva.
2. Las APIs no se ven desde fuera. No tienen UI, así que los WAFs genéricos y las herramientas que dependen del DOM no te protegen. Un atacante con un Postman bien configurado tarda menos en descubrir un IDOR que un usuario normal en encontrar tu botón "perfil".
3. NIS2, DORA, PCI DSS v4.0 e ISO 27001:2022 ya exigen pruebas técnicas específicas sobre APIs. La cláusula PCI DSS 6.4.6 obliga a evaluar APIs como cualquier otra superficie expuesta. NIS2 artículo 21 exige pruebas de eficacia de medidas técnicas, lo que en la práctica incluye pentesting API para servicios críticos.

Bien ejecutado, un pentesting de APIs entrega:

• Inventario real de endpoints (incluido el shadow API que el equipo de desarrollo no recuerda haber dejado expuesto).
• Cadenas de ataque reproducibles con peticiones HTTP exactas y scripts.
• Recomendaciones priorizadas por esfuerzo/beneficio que el equipo de desarrollo puede aplicar.
• Evidencia auditable para los auditores externos de NIS2, DORA, ISO 27001 o PCI DSS.

REST y GraphQL: por qué se auditan distinto

REST y GraphQL son arquitecturas distintas y cada una tiene su catálogo de bugs.

REST

Una API REST expone recursos (/users/123, /orders/45). Cada endpoint hace una operación CRUD sobre un recurso identificado por URL. La superficie de ataque se mide por el número de endpoints y por las relaciones entre recursos.

Los bugs típicos en REST:

• BOLA / IDOR (Broken Object Level Authorization). El endpoint /orders/45 te devuelve la orden 45 aunque no sea tuya. Es la categoría #1 del OWASP API Top 10 desde 2019.
• Mass assignment. Pasas {"role": "admin"} en el body de un POST a /users, y la API lo asigna porque el modelo no filtra qué campos acepta.
• Inyección clásica. SQL, NoSQL, comando, LDAP. Sigue apareciendo en APIs con menos disciplina de validación que la capa web.
• Rate limiting roto. Login sin throttling permite credential stuffing masivo.
• Exposición de datos. El endpoint devuelve más campos de los que la UI usa: tokens internos, IDs de otros usuarios, hashes.

GraphQL

Una API GraphQL expone un único endpoint (/graphql) que acepta queries arbitrarias contra un esquema. Es muchísimo más flexible que REST y, por la misma razón, mucho más peligrosa cuando no se audita.

Los bugs típicos en GraphQL:

• Introspection abierta en producción. El endpoint expone el esquema completo a cualquier atacante con un cliente GraphQL. Es como dejar el Swagger público sin auth.
• Aliases y batched queries. Un atacante combina N llamadas en un único request, saltándose el rate limiting que cuenta requests, no operaciones.
• Query depth abuse. Una query anidada user → posts → comments → author → posts → comments → ... puede hacer que el resolver dispare miles de consultas SQL en cascada y tirar la base de datos.
• Field-level authorization rota. La query es legítima pero un campo concreto (user.email, order.creditCard) no debería verse desde ese contexto. El equipo de desarrollo aplicó autorización a la operación pero no al campo.
• GraphQL subscriptions sin auth. Las subscriptions vía WebSocket suelen heredar problemas de autorización del REST equivalente.

gRPC, SOAP y el resto

Los pentesting de APIs modernos cubren también gRPC (común en microservicios internos) y los SOAP legacy (banca, administraciones públicas, integraciones EDI). Comparten el mismo principio: cualquier interfaz que exponga datos requiere autorización por objeto y por campo, sea cual sea el protocolo.

OWASP API Security Top 10: las 10 categorías que cualquier auditor cubre

El OWASP API Security Top 10 es el estándar de facto. La versión vigente lista:

1. API1: Broken Object Level Authorization (BOLA). La categoría que más impacto causa. Un endpoint procesa un ID y devuelve el recurso sin validar que el usuario autenticado pueda verlo.
2. API2: Broken Authentication. Tokens débiles, JWT con alg: none aceptado, contraseñas en query string, refresh tokens sin caducidad.
3. API3: Broken Object Property Level Authorization. Variante a nivel de campo: el usuario puede leer la orden pero no debería ver order.internal_notes.
4. API4: Unrestricted Resource Consumption. Sin rate limiting, sin tamaño máximo de body, sin protección contra batch queries en GraphQL.
5. API5: Broken Function Level Authorization. Un usuario regular puede invocar /admin/deleteUser porque la lista blanca de roles está mal aplicada.
6. API6: Unrestricted Access to Sensitive Business Flows. La API permite ejecutar el flujo "comprar entrada" sin captcha ni anti-bot, así que los bots automatizados se las quedan todas.
7. API7: Server Side Request Forgery (SSRF). La API acepta una URL como input y la dispara desde el servidor, abriendo el acceso a recursos internos (metadata cloud, base de datos, panel de admin).
8. API8: Security Misconfiguration. CORS mal configurado, headers de seguridad ausentes, errores que filtran stacktraces.
9. API9: Improper Inventory Management. APIs viejas v1 que siguen vivas mientras la v2 es la única documentada. Los atacantes encuentran v1 enseguida.
10. API10: Unsafe Consumption of APIs. Tu API consume otra API de un partner sin validar la respuesta. Una respuesta maliciosa del partner termina ejecutándose en tu lógica.

Una auditoría seria empieza por mapear los 10 contra cada endpoint del scope.

Errores recurrentes que aparecen en el 80% de las APIs auditadas

Cuatro fallos sistémicos que vemos en casi cualquier API empresarial, sea startup o gran corporación:

• Autorización a nivel de operación pero no de objeto. El middleware comprueba "este usuario puede llamar a GET /orders/{id}", pero no comprueba que el ID concreto le pertenece. Es BOLA y, paradójicamente, es el bug más fácil de explotar y más difícil de detectar con escáner.
• Filtros del lado cliente. El backend devuelve 200 órdenes y el frontend filtra para mostrar las del usuario actual. Cualquier atacante con DevTools ve el JSON completo.
• GraphQL introspection viva en producción. Permite a un atacante anónimo descargar el esquema completo, mapear toda la API y diseñar ataques precisos sin enumeración a ciegas.
• Endpoints "internos" sin auth porque "están detrás del firewall". Hasta que un SSRF o un proxy abierto los expone. Defensa en profundidad: cualquier endpoint requiere auth, esté donde esté.

Metodología: cómo se ejecuta un pentesting de APIs serio

El proceso que seguimos en cualquier auditoría de APIs sigue siempre los mismos seis bloques:

1. Alcance y autorizaciones. Lista de endpoints en scope, ventanas horarias, criterios de parada (cualquier afectación a producción dispara pausa). Si hay datos personales o financieros, pacto de NDA y entornos de pruebas.
2. Reconocimiento. Importación del OpenAPI/Swagger si existe; si no, captura desde el cliente legítimo (web, móvil) usando proxy. Para GraphQL, intento de introspection y fallback a búsqueda de queries en el cliente.
3. Mapping de autorización. Cada endpoint se prueba con tres tipos de actor: anónimo, usuario sin permisos, usuario con permisos. Las matrices de respuesta esperada vs respuesta real dan la mayoría de hallazgos críticos.
4. Explotación. Encadenamos los fallos relevantes hasta demostrar el impacto real (acceso a datos, escalada, modificación). Sin destrucción ni interrupción.
5. Reporte. Cadenas de ataque reproducibles con peticiones HTTP exactas, severidad CVSS justificada por impacto en negocio, recomendaciones priorizadas y código de mitigación cuando aplica.
6. Acompañamiento y retest. Sesión con desarrollo para resolver dudas, soporte durante la remediación y verificación de cierre tras los fixes.

Las herramientas habituales: Burp Suite o Caido como proxy principal, Postman o Insomnia para colecciones, InQL y GraphQL Voyager para introspection y mapeo, Nuclei para checks repetibles tras la auditoría manual, ffuf para enumeración de endpoints ocultos.

Pentesting de APIs y compliance: NIS2, DORA, ISO 27001, PCI DSS

El pentesting de APIs es la pieza técnica que evidencia varios controles obligatorios:

• NIS2 (artículo 21). Las medidas de gestión de riesgos exigen pruebas regulares de eficacia. Para servicios cuyo backend principal son APIs, el pentesting API es la prueba pertinente.
• DORA (artículo 25 y 26). El régimen TIBER-EU/TLPT presupone pruebas técnicas sobre cualquier infraestructura crítica para la operación financiera, incluidas APIs públicas y privadas.
• PCI DSS v4.0 (req. 6.4.6 y req. 11.3.1). Exige evaluación específica de APIs y aplicaciones a medida tras cualquier cambio significativo y, como mínimo, anualmente.
• ISO 27001:2022 (control A.8.26 Application security requirements). Exige requisitos de seguridad documentados y verificados sobre APIs durante el ciclo de desarrollo.
• Reglamento eIDAS, RGPD. Cualquier API que procese datos personales o firmas electrónicas hereda los requisitos de seguridad y trazabilidad asociados.

Cómo elegir un proveedor de pentesting de APIs

Cinco criterios que separan un PDF lleno de resultados de Postman security checker de un pentesting útil:

1. Capacidad demostrada en BOLA / IDOR a escala. Es la categoría más explotada y la que más mata informes incompletos. El proveedor debe describir cómo cubre autorización por objeto en cada endpoint, no sólo "revisar autorización".
2. Experiencia con GraphQL real. GraphQL exige conocimientos específicos (aliases, batched queries, subscriptions) que un perfil sólo REST no tiene.
3. Reporte que sirva al equipo de desarrollo. Petición HTTP exacta + script reproducible + sugerencia de fix. Sin esto, el equipo no puede remediar.
4. Disposición al retest tras la remediación. Auditoría sin verificación de cierre tiene la mitad del valor.
5. Confidencialidad operativa. Las APIs auditadas suelen exponer datos personales o financieros. Repositorio interno cifrado, NDAs, borrado contractual al cierre.

Preguntas frecuentes sobre pentesting de APIs

¿En qué se diferencia un pentesting de APIs de un pentesting web?

El pentesting web audita la aplicación completa: frontend (UI, JavaScript), backend (controladores) y APIs que lo sostienen. Un pentesting de APIs se centra exclusivamente en la capa API, lo que permite mayor profundidad por endpoint, cubrir mejor BOLA y autorización por campo, y auditar APIs que no tienen UI (B2B, microservicios internos, integraciones partner). En APIs públicas con cliente web complejo, lo eficaz es combinar ambos.

¿Hace falta documentación OpenAPI o Swagger para auditar?

Ayuda mucho, pero no es imprescindible. Si la documentación existe, el equipo importa el OpenAPI/Swagger y cubre cada endpoint declarado. Si no, se hace ingeniería inversa desde el cliente legítimo: proxy del navegador o de la app móvil, captura de peticiones, mapeo de endpoints. La ausencia de documentación suele ser en sí misma un hallazgo (API9: Improper Inventory Management).

¿Cuánto cuesta un pentesting de APIs?

El precio se calcula por días de trabajo y depende del tamaño de la API y la complejidad. Una API REST con 30-50 endpoints se cubre en 5-7 días; una API GraphQL madura o una superficie B2B con federación de servicios va de 12-20 días. Lo razonable es pedir propuesta concreta tras una sesión de scoping de 30-60 minutos donde se mapea el alcance real.

¿Cubre el pentesting de APIs los problemas de rate limiting?

Sí, está dentro del API4 (Unrestricted Resource Consumption) del OWASP API Top 10. Se prueba con cargas controladas. La auditoría incluye recomendaciones de configuración (cuota por token, throttling adaptativo, captcha en endpoints sensibles) sin generar denegación de servicio en producción.

¿GraphQL es más seguro que REST?

No, sólo distinto. GraphQL tiene menos endpoints (uno solo en el caso típico), lo que reduce la superficie en bruto, pero expone más complejidad por endpoint: introspection, aliases, batched queries, query depth, field-level authorization. Una API GraphQL mal configurada es a menudo más explotable que una REST equivalente porque el atacante con introspection abierta sabe exactamente qué pedir.

¿Cuándo conviene auditar APIs?

Tres ventanas críticas: antes del lanzamiento público, después de cualquier cambio significativo (nueva versión mayor, nueva integración partner) y de forma anual como mínimo cuando el sistema procesa datos sensibles. PCI DSS y NIS2 imponen el ritmo anual; el resto debe acompañar el ritmo de cambio del producto.

Recursos relacionados

• Qué es un pentesting: la guía pillar de la disciplina completa.
• Pentesting web: auditoría de la capa de aplicación que normalmente acompaña al pentesting de APIs.
• Pentesting cloud (AWS, Azure, GCP): auditoría de la infraestructura cloud donde corren las APIs.
• OWASP Top 10 explicado: cómo se relaciona con el OWASP API Security Top 10.
• Servicio de auditoría web y móvil: el servicio donde aplicamos esta metodología.

El pentesting de APIs en Secra

En Secra ejecutamos pentesting de APIs REST, GraphQL y gRPC dentro del servicio de auditoría web y móvil, bajo OWASP API Security Top 10 y con foco real en autorización por objeto y por campo. Cada hallazgo va con petición HTTP reproducible, severidad justificada por impacto en negocio y plan de remediación priorizado. Si quieres una propuesta concreta para tu API, escríbenos a través de contacto.