24. Pentesting de APIs REST, GraphQL y servicios expuestos
Las APIs concentran lógica de negocio, datos sensibles e integraciones críticas. En este tema aprenderás a evaluarlas dentro de un alcance autorizado, identificando fallas de autenticación, autorización, exposición de información, abuso de automatización y configuraciones débiles sin salir del marco ético del pentest.
Objetivo
Comprender cómo revisar APIs REST, GraphQL y servicios expuestos con metodología, evidencia controlada y foco en impacto real.
Enfoque
Analizar inventario, documentación, autenticación, autorización, validación, límites, errores, datos y dependencias.
Resultado
Traducir hallazgos técnicos en riesgos claros y recomendaciones aplicables para equipos de desarrollo y seguridad.
24.1 Introducción
Una API permite que aplicaciones, servicios, dispositivos, integraciones y usuarios automaticen operaciones sin depender necesariamente de una interfaz gráfica. Por eso, durante un pentest moderno, no alcanza con revisar formularios web visibles: muchas acciones sensibles se ejecutan a través de endpoints, tokens, parámetros, objetos JSON, consultas GraphQL, colas, webhooks o servicios internos expuestos por error.
El pentesting de APIs busca responder preguntas concretas: quién puede llamar a cada endpoint, qué datos recibe, qué datos devuelve, qué acciones permite, qué límites aplica, cómo maneja errores y qué ocurre cuando se manipulan identificadores, roles, estados o flujos de negocio. La prueba debe realizarse siempre con autorización explícita, cuentas de laboratorio y datos controlados.
24.2 Qué diferencia a una API de una aplicación web tradicional
En una aplicación web tradicional, parte de la lógica está condicionada por vistas, botones y navegación. En una API, el cliente suele construir las solicitudes directamente y el servidor debe validar todo sin confiar en que la interfaz limite el comportamiento. Si el backend permite una operación, un atacante no necesita que exista un botón visible para ejecutarla.
Esto convierte a las APIs en superficies muy sensibles para fallas de autorización, exposición excesiva de datos, parámetros manipulables, ausencia de límites, endpoints antiguos y diferencias entre lo que el equipo cree que está publicado y lo que realmente responde en producción.
24.3 Alcance e inventario de APIs
El primer paso es construir un inventario. Deben identificarse dominios, subdominios, rutas base, versiones, entornos, servicios internos accesibles, documentación pública, colecciones de prueba, aplicaciones móviles, integraciones de terceros y endpoints utilizados por el frontend.
Un inventario incompleto produce pruebas incompletas. Una API antigua, un servicio de administración, una versión beta o un endpoint usado solo por una app móvil pueden contener controles más débiles que la interfaz principal.
| Elemento | Qué revisar | Riesgo típico |
|---|---|---|
| Rutas base | /api, versiones, módulos y prefijos |
Endpoints no documentados o heredados |
| Entornos | Producción, pruebas, staging y desarrollo | Datos reales en ambientes menos protegidos |
| Clientes | Web, móvil, integraciones y servicios internos | Diferencias de controles entre canales |
| Documentación | OpenAPI, Swagger, Postman, README y portales | Operaciones sensibles expuestas por diseño |
24.4 Documentación OpenAPI, Swagger y colecciones
La documentación de una API es una fuente de contexto valiosa. Un archivo OpenAPI o una colección Postman permite entender modelos, parámetros, códigos de respuesta, esquemas, flujos de autenticación y operaciones esperadas. También puede revelar endpoints administrativos, rutas antiguas o campos sensibles que no aparecen en la interfaz pública.
Durante una auditoría se debe comparar la documentación contra el comportamiento real. Un endpoint documentado pero retirado, una operación activa pero ausente de la documentación o un parámetro opcional que cambia la autorización pueden ser señales de deuda técnica y riesgo.
24.5 REST: recursos, métodos y códigos de respuesta
En APIs REST, los recursos suelen representarse mediante rutas y los métodos HTTP indican la operación esperada. La revisión debe comprobar que cada método tenga controles adecuados, que los códigos de respuesta no filtren información innecesaria y que las operaciones destructivas o sensibles exijan privilegios correctos.
| Método | Uso habitual | Control esperado |
|---|---|---|
| GET | Consultar recursos | Autorización por objeto y mínima exposición de datos |
| POST | Crear recursos o ejecutar acciones | Validación de entrada, permisos y protección contra abuso |
| PUT/PATCH | Actualizar recursos | Control de campos modificables y reglas de negocio |
| DELETE | Eliminar recursos | Permisos fuertes, confirmación lógica y registro de auditoría |
24.6 Autenticación en APIs
La autenticación determina quién realiza la solicitud. En APIs modernas puede involucrar sesiones, claves de API, OAuth 2.0, OpenID Connect, tokens JWT, certificados de cliente o integraciones entre servicios. La prueba debe validar que el mecanismo sea consistente, que los tokens expiren, que la revocación funcione y que no existan rutas sensibles accesibles sin credenciales.
También es importante revisar dónde se almacenan los secretos, cómo se rotan, si aparecen en repositorios, registros, URLs, documentación, respuestas o errores. Una clave válida con permisos excesivos puede tener más impacto que una vulnerabilidad técnica compleja.
24.7 Autorización por objeto: BOLA e IDOR
Una de las fallas más comunes en APIs es permitir que un usuario autenticado acceda a objetos que no le pertenecen. Este patrón se conoce como BOLA, por sus siglas en inglés, y se relaciona con los IDOR estudiados en temas anteriores. Suele aparecer cuando el backend valida que el usuario tenga sesión, pero no verifica si realmente puede operar sobre el recurso solicitado.
La validación ética consiste en usar cuentas de laboratorio con roles y pertenencias distintas, comparar el comportamiento esperado y documentar si una cuenta puede consultar, modificar o borrar recursos de otra. La evidencia debe ser mínima y no debe implicar extracción masiva de datos.
24.8 Autorización por función: BFLA
BFLA ocurre cuando un usuario puede ejecutar una función para la que no tiene permiso, aunque el objeto no sea necesariamente de otro usuario. Por ejemplo, una cuenta estándar que puede invocar acciones administrativas, aprobar operaciones, cambiar estados, exportar información o modificar configuraciones globales.
La revisión debe cubrir rutas visibles y no visibles en la interfaz. El hecho de que una opción no aparezca en el menú no significa que el endpoint esté protegido. La autorización debe aplicarse del lado del servidor en cada operación sensible.
24.9 Tokens, scopes y claims
Los tokens pueden contener identificadores, scopes, roles, fechas de expiración, audiencia, emisor y otros claims. Durante el pentest se debe revisar si esos datos son coherentes con el control de acceso real. Un token no debe aceptarse fuera de su audiencia, después de su expiración ni para acciones no cubiertas por sus permisos.
En JWT, además, importa la validación criptográfica, el algoritmo permitido, la clave usada para verificar, el manejo de rotación y el tratamiento de tokens revocados. La recomendación no es confiar en el contenido del token por comodidad, sino validar las reglas críticas contra una fuente de autoridad confiable cuando el riesgo lo exige.
24.10 Rate limiting y abuso de automatización
Las APIs están diseñadas para ser consumidas por software, por lo que el abuso automatizado debe contemplarse desde el diseño. La ausencia de límites puede facilitar enumeración de recursos, fuerza bruta contra códigos, scraping, creación masiva de cuentas, consumo excesivo de recursos o ejecución repetida de acciones costosas.
Un pentest debe comprobar si existen límites por usuario, token, IP, cliente, operación y recurso. También debe evaluar si la respuesta ante exceso de uso es clara, consistente y registrada. El objetivo no es degradar el servicio, sino demostrar de forma controlada si los límites existen y si son suficientes para el riesgo del negocio.
24.11 Validación de entrada y tipos de datos
Las APIs procesan datos estructurados, pero eso no garantiza seguridad. Cada campo debe validarse por tipo, formato, longitud, rango, obligatoriedad, relación con otros campos y regla de negocio. No alcanza con que el frontend o el cliente oficial envíen datos correctos.
La revisión debe incluir campos numéricos, booleanos, listas, objetos anidados, fechas, identificadores, filtros, ordenamientos, paginación y cargas de archivos si existen. Los errores deben rechazarse de forma controlada, sin revelar trazas internas ni detalles innecesarios de infraestructura.
24.12 Exposición excesiva de datos
Una API puede devolver más información de la que la interfaz muestra. Esto ocurre cuando el backend responde con objetos completos y el cliente decide qué campos renderizar. El problema es que cualquier consumidor puede leer la respuesta completa, incluyendo datos internos, estados, roles, correos, identificadores, flags, referencias a terceros o metadatos sensibles.
La remediación consiste en diseñar respuestas por caso de uso, aplicar mínimos privilegios también a nivel de campo, evitar incluir secretos o datos internos y revisar serializadores para que no expongan propiedades no previstas.
24.13 Errores, mensajes y verbos HTTP
Los mensajes de error ayudan al desarrollo y a la operación, pero pueden revelar nombres de tablas, clases, rutas internas, versiones, dependencias, políticas de autorización o diferencias útiles para enumeración. Una API bien diseñada distingue entre errores para el usuario, errores para observabilidad interna y eventos de seguridad.
También se debe revisar la respuesta ante métodos no permitidos, cabeceras inesperadas, contenido con tipo incorrecto, parámetros duplicados y rutas inexistentes. La consistencia reduce filtraciones y dificulta inferir estados internos.
24.14 Versionado y endpoints antiguos
El versionado permite evolucionar una API sin romper clientes, pero también puede dejar código antiguo activo. Las versiones anteriores suelen tener controles menos maduros, dependencias sin soporte o reglas de negocio que ya no reflejan el modelo actual.
En el pentest conviene comparar versiones, revisar si los endpoints retirados siguen respondiendo, validar que las rutas deprecadas mantengan autorización equivalente y confirmar que no existan accesos directos a funciones que el producto ya no muestra.
24.15 GraphQL: características y superficie de ataque
GraphQL centraliza muchas operaciones en uno o pocos endpoints y permite que el cliente solicite estructuras de datos específicas. Esto mejora flexibilidad, pero cambia la forma de auditar: no basta con listar rutas, hay que comprender esquemas, tipos, queries, mutations, resolvers y relaciones entre objetos.
Las fallas frecuentes incluyen autorización incompleta en resolvers, exposición de campos sensibles, consultas demasiado profundas, ausencia de límites de complejidad, introspección expuesta sin necesidad y diferencias entre lo permitido por el esquema y lo validado por la lógica de negocio.
24.16 Introspection, profundidad y complejidad en GraphQL
La introspección permite descubrir el esquema GraphQL. En entornos de desarrollo puede ser útil, pero en producción debe evaluarse según el riesgo y la necesidad real. Aunque se desactive, la seguridad no debe depender solo de ocultar el esquema: cada resolver debe validar autenticación, autorización y reglas de negocio.
| Aspecto | Riesgo | Control recomendado |
|---|---|---|
| Introspection | Descubrimiento amplio del esquema | Restringir o justificar su exposición en producción |
| Profundidad | Consultas recursivas o demasiado anidadas | Límites de profundidad y complejidad |
| Resolvers | Autorización desigual por campo u objeto | Controles centralizados y pruebas por rol |
| Mutations | Cambios de estado no autorizados | Validación de permisos y auditoría de acciones |
24.17 APIs internas y servicios expuestos
Muchas organizaciones publican servicios pensando que solo serán usados por sistemas internos. Sin embargo, una mala segmentación, un proxy mal configurado, una regla de firewall amplia o un subdominio olvidado pueden exponer interfaces administrativas, paneles de monitoreo, documentación, colas, consolas o endpoints de salud con más información de la necesaria.
En la evaluación se debe respetar estrictamente el alcance. Si se identifica un servicio potencialmente sensible fuera del alcance definido, se documenta y se solicita autorización antes de profundizar. La prioridad es reducir riesgo sin generar impacto operativo.
24.18 Webhooks e integraciones
Los webhooks permiten que un sistema notifique eventos a otro. Su seguridad depende de validar origen, autenticidad, integridad, repetición, caducidad y manejo de errores. Una integración débil puede permitir falsificar eventos, repetir operaciones, filtrar información o provocar acciones de negocio no deseadas.
Las buenas prácticas incluyen firmas verificables, secretos rotables, marcas de tiempo, identificadores únicos de evento, registro de auditoría, reintentos controlados y validación estricta de los datos recibidos.
24.19 Evidencia en pruebas de APIs
La evidencia debe demostrar el riesgo sin ampliar innecesariamente el daño. En APIs, esto implica capturar la solicitud, respuesta, usuario utilizado, rol, endpoint, identificador de laboratorio, hora, resultado esperado, resultado observado e impacto. Cuando haya datos sensibles, se deben anonimizar o recortar.
Una buena evidencia no es una colección enorme de respuestas, sino una demostración clara y reproducible para el equipo responsable. Debe permitir corregir el problema, volver a probarlo y entender su prioridad.
24.20 Remediación de fallas en APIs
La remediación debe atacar la causa, no solo el endpoint observado. Si una API presenta BOLA, la solución no debería ser bloquear un único identificador, sino aplicar autorización por objeto en la capa adecuada. Si hay exposición excesiva de datos, conviene revisar modelos de respuesta y serialización en todo el módulo.
- Definir autenticación y autorización obligatorias por operación sensible.
- Aplicar autorización por objeto, función, tenant, rol y estado del recurso.
- Reducir respuestas a los campos necesarios para cada caso de uso.
- Implementar límites de tasa, tamaño, paginación, profundidad y complejidad.
- Centralizar validación de entrada y manejo de errores.
- Registrar eventos relevantes sin exponer secretos ni datos personales innecesarios.
- Retirar versiones antiguas o mantenerlas con controles equivalentes.
24.21 Errores frecuentes durante el pentesting de APIs
Un error común es limitarse a probar endpoints visibles en la interfaz web. Otro es concentrarse solo en inyección y olvidar reglas de negocio, permisos, límites y datos. También es riesgoso probar con cuentas reales de usuarios productivos cuando no fue autorizado explícitamente.
El trabajo profesional requiere cuentas controladas, coordinación con responsables técnicos, límites claros, ventanas acordadas cuando hay riesgo operativo y comunicación temprana si se detecta exposición de datos o posibilidad de acciones irreversibles.
24.22 Flujo práctico de revisión
Un flujo razonable comienza con el inventario, continúa con documentación y autenticación, luego revisa autorización por objeto y función, analiza entradas y respuestas, valida límites, revisa errores, compara versiones, evalúa GraphQL o webhooks si existen y finalmente organiza hallazgos por impacto.
- Confirmar alcance, cuentas de prueba y datos permitidos.
- Construir el inventario de endpoints, métodos, versiones y clientes.
- Revisar documentación y contrastarla con el tráfico real.
- Validar autenticación, expiración, revocación y manejo de secretos.
- Probar autorización por objeto, función, tenant y estado.
- Evaluar validación de entrada, exposición de datos y mensajes de error.
- Comprobar límites de automatización, tamaño, paginación y complejidad.
- Documentar evidencia mínima, impacto, causa probable y remediación.
24.23 Qué debes recordar
Las APIs no son solo una forma alternativa de acceder a una aplicación: muchas veces son el producto principal. Por eso, la seguridad debe vivir en el backend, en cada endpoint, resolver, integración y operación crítica.
Los hallazgos más valiosos suelen aparecer cuando se combinan roles, objetos, estados y flujos de negocio. La pregunta central no es solo si una solicitud funciona, sino si debería funcionar para ese usuario, sobre ese recurso, en ese momento y con esos datos.
24.24 Conclusión
El pentesting de APIs exige método, precisión y criterio. REST, GraphQL, webhooks y servicios expuestos deben revisarse con foco en autorización, datos, límites, errores, versiones y dependencias. La meta no es acumular solicitudes, sino demostrar riesgos reales de forma controlada y entregar recomendaciones que el equipo pueda aplicar.
En el próximo tema avanzaremos hacia el pentesting cloud, donde estos mismos principios se combinan con IAM, almacenamiento, redes, secretos y configuraciones de plataformas en la nube.