Pentesting de APIs: seguridad REST, GraphQL y OAuth

Las APIs son el sistema nervioso de tu negocio digital. Conectan servicios, exponen datos y mueven dinero. Auditamos su seguridad siguiendo el OWASP API Security Top 10, con el rigor de un atacante y la precisión de un equipo técnico especializado.

Dimensiona tu proyecto · Auditar mi API

¿Prefieres hablarlo? Llámanos al +34 960 730 013

Las APIs son el nuevo perímetro de ataque

El riesgo número uno del OWASP API Security Top 10 no es la autenticación, sino la autorización a nivel de objeto: "Broken Object Level Authorization" (API1:2023). Un endpoint que devuelve los datos de cualquier usuario si cambias el ID en la URL. Una API interna expuesta sin protección porque "solo es para uso interno". Un token que no caduca nunca. Estos fallos son silenciosos y fáciles de explotar para alguien que sabe buscarlos.

Así se cuela una petición por un fallo de autorización a nivel de objeto

La autenticación funciona, el token es válido y aun así la API entrega los datos de otro cliente. Sigue la misma petición con y sin el control que falta.

Sin control por objeto

  1. Ana, clienta legítima, pide el pedido 48213 con su propio token. El pedido no es suyo: solo ha cambiado el número de la URL.
  2. El gateway valida la firma y la caducidad del token. Ana está autenticada, así que la petición sigue adelante.
  3. El servicio busca el pedido por su identificador y nunca comprueba si pertenece a quien lo pide.
  4. La API responde 200 con el nombre, la dirección y el teléfono de otro cliente. Con un bucle sobre el identificador se descargan los pedidos de toda la plataforma.

Con control por objeto

  1. La misma petición: el token de Ana y el pedido 48213, que pertenece a otro cliente.
  2. La autenticación pasa igual, porque el token es válido. Ese control, por sí solo, no protege el dato.
  3. Antes de devolver nada, el servicio compara el propietario del pedido con el usuario del token. No coinciden.
  4. La API responde 403 y registra el intento. Repetido en bucle, salta una alerta en lugar de producirse una fuga de datos.

Ejemplo ilustrativo. En un pentesting de APIs probamos este cruce en cada endpoint que recibe un identificador, con usuarios de distintos roles y tenants.

Qué auditamos

  • BOLA (Broken Object Level Authorization): acceso a recursos ajenos
  • Broken Authentication: tokens débiles, sin expiración, sin revocación
  • Exposición excesiva de datos: respuestas con más información de la necesaria
  • Rate limiting y protección frente a abuso de la API
  • SSRF, inyecciones y validación de entrada en parámetros de la API
  • Flujos OAuth 2.0 y OpenID Connect: redirect_uri, PKCE, scope escalation
  • GraphQL: introspección, batching attacks, field-level authorization

Cómo auditamos una API

  1. Mapeo de endpoints: Identificamos todos los endpoints, métodos HTTP, parámetros y formatos de autenticación. Revisamos la documentación si existe (Swagger, OpenAPI).
  2. Análisis de autenticación y autorización: Probamos los mecanismos de autenticación y verificamos que la autorización funciona correctamente a nivel de objeto y función.
  3. Fuzzing e inyecciones: Enviamos payloads maliciosos para detectar inyecciones, comportamientos inesperados y exposición de errores del servidor.
  4. Pruebas de lógica de negocio: Evaluamos los flujos transaccionales: ¿puede un usuario estándar ejecutar acciones de administrador? ¿Puede acceder a datos de otros usuarios?
  5. Explotación y documentación: Confirmamos cada hallazgo con una prueba de concepto clara y lo clasificamos por criticidad.

Los diez riesgos contra los que probamos tu API

La lista de referencia del sector para la seguridad de APIs, en su edición vigente de 2023. Toca un riesgo para ver en qué consiste y cómo lo comprobamos; los colores agrupan los que comparten causa.

  1. API1:2023 Broken Object Level Authorization (Autorización): La API devuelve o modifica un objeto con solo conocer su identificador, sin comprobar que pertenece a quien lo pide. Cruzamos identificadores entre usuarios y tenants en cada endpoint que recibe un ID: rutas, parámetros, cuerpo y cabeceras.
  2. API2:2023 Broken Authentication (Autenticación): Fallos en cómo se emiten y validan las credenciales: tokens que no caducan o cuya firma no se verifica, intentos de login ilimitados o una recuperación de cuenta débil. Probamos la emisión, validación y revocación de JWT y sesiones, la fuerza bruta y el flujo de recuperación de cuenta.
  3. API3:2023 Broken Object Property Level Authorization (Autorización): El objeto es tuyo, pero no todas sus propiedades deberían serlo: respuestas que exponen campos internos o peticiones que permiten escribir campos como role o price (mass assignment). Comparamos las propiedades que devuelve y acepta cada endpoint con las que cada rol debería poder ver o modificar.
  4. API4:2023 Unrestricted Resource Consumption (Abuso y consumo): Sin límites de peticiones, tamaño, paginación o coste, un atacante agota recursos o dispara la factura de servicios de terceros como SMS, correo o IA. Medimos límites de frecuencia, tamaño de carga, paginación y operaciones caras, de forma controlada y acordada contigo.
  5. API5:2023 Broken Function Level Authorization (Autorización): Un usuario estándar invoca funciones de administración porque el control depende de que no conozca el endpoint o el método. Repetimos las llamadas de cada rol privilegiado con las credenciales de los demás roles, cambiando también el método HTTP.
  6. API6:2023 Unrestricted Access to Sensitive Business Flows (Abuso y consumo): Flujos legítimos —compras, reservas, altas o comentarios— automatizados a escala para acaparar stock, hacer spam o abusar de promociones. Identificamos los flujos de negocio sensibles y comprobamos si se pueden automatizar sin ningún freno.
  7. API7:2023 Server Side Request Forgery (Servidor y configuración): La API descarga una URL que le pasa el usuario, y se la puede apuntar a servicios internos o a los metadatos de la nube. Probamos cada parámetro que acepta URLs (webhooks, importaciones, previsualizaciones) contra destinos internos y de metadatos.
  8. API8:2023 Security Misconfiguration (Servidor y configuración): Cabeceras y CORS permisivos, errores con trazas, métodos innecesarios, TLS débil o la introspección de GraphQL abierta en producción. Revisamos la configuración del servidor, CORS, cabeceras, mensajes de error y la exposición de esquemas.
  9. API9:2023 Improper Inventory Management (Inventario y terceros): Versiones antiguas, entornos de prueba o endpoints sin documentar que siguen publicados y sin los controles de la versión actual. Descubrimos versiones y hosts que no están en el inventario y comparamos sus controles con los de la versión en producción.
  10. API10:2023 Unsafe Consumption of APIs (Inventario y terceros): La API confía más en los datos que recibe de terceros que en los de sus propios usuarios y los procesa sin validarlos. Revisamos cómo validan las integraciones las respuestas de APIs de terceros, las redirecciones y el transporte.

OWASP API Security Top 10, explicado riesgo a riesgo

Nombres oficiales en inglés, tal como los publica OWASP.

Entregables

  • Informe técnico con cada endpoint en alcance y sus hallazgos
  • PoC reproducible para cada vulnerabilidad (requests, responses, payloads)
  • Mapa de superficie de ataque de tu API
  • Recomendaciones de remediación específicas (no genéricas)
  • Reunión de cierre con el equipo de desarrollo backend

Casos de uso habituales

  • APIs de plataformas SaaS con acceso multiusuario y datos sensibles
  • Microservicios internos con comunicación entre servicios
  • APIs de e-commerce con endpoints de pago y gestión de pedidos
  • Aplicaciones móviles cuya lógica reside en la API backend
  • APIs expuestas a partners o terceros mediante API keys
  • APIs bancarias y fintech sujetas a DORA o PSD2

Preguntas frecuentes

¿Necesitáis acceso a la documentación de la API (Swagger/OpenAPI)?

Es útil pero no imprescindible. Podemos trabajar en modo caja negra interceptando el tráfico de la aplicación que consume la API. La documentación acelera el proceso y mejora la cobertura.

¿Auditáis APIs internas o solo las expuestas a internet?

Las dos. De hecho, las APIs internas son frecuentemente las más vulnerables porque se asume erróneamente que "solo las usan los empleados". El movimiento lateral en un ataque suele aprovechar exactamente este tipo de API.

¿Qué diferencia hay entre auditar una API REST y una GraphQL?

GraphQL tiene vectores de ataque específicos: la introspección puede revelar el esquema completo de datos, el batching permite DoS a nivel de aplicación y la autorización a nivel de campo es más compleja de implementar correctamente. Cubrimos ambos con metodologías adaptadas.

¿Cuánto tarda una auditoría de API?

Entre 3 y 7 días hábiles para la fase técnica, según el número de endpoints y la complejidad de los flujos de autenticación y negocio.

¿Necesitáis la documentación de la API o podéis trabajar sin ella?

Se puede trabajar sin ella, pero el resultado es peor y más caro. Con una especificación OpenAPI o una colección de Postman el alcance queda cubierto desde el primer día; sin ella hay que dedicar tiempo a descubrir endpoints, y los que no se descubren no se prueban. Si la documentación está desactualizada, dínoslo: un endpoint que existe y no está documentado es de por sí un hallazgo relevante.

¿Cubrís GraphQL y no solo REST?

Sí, y el enfoque cambia bastante. En GraphQL importan la introspección expuesta en producción, los ataques de profundidad y complejidad de consulta que agotan el servidor, y la autorización a nivel de campo: es frecuente proteger el tipo pero no cada campo, de forma que una consulta anidada devuelve datos que el usuario no debería ver. En REST el peso recae más en la autorización por objeto y en la enumeración de identificadores.

¿Cómo evitáis agotar los límites de peticiones durante las pruebas?

Se acuerda antes: o se excluye la IP de origen del rate limiting durante la ventana de pruebas, o se ajusta la intensidad para mantenerse por debajo del umbral. Conviene decidirlo conscientemente, porque desactivar el límite permite probar el resto a fondo pero deja sin evaluar el propio control de abuso, que en una API expuesta es un hallazgo por derecho propio. Lo habitual es probar ambos escenarios en momentos distintos.

Recursos relacionados

Fuentes

¿Listo para proteger tu empresa?

Responde la ficha de alcance a tu ritmo y la usaremos para preparar tu propuesta. Si prefieres hablarlo antes, reserva una llamada gratuita de 30 minutos.

Dimensiona tu proyecto · Auditar mi API