Pentesting APIs: OWASP API Top 10 guía

Respuesta directa: El pentesting de APIs evalúa los riesgos documentados en el OWASP API Security Top 10 2023 —desde autorización rota a nivel de objeto (BOLA) hasta consumo irrestricto de recursos— utilizando herramientas como Burp Suite Pro, Postman y OWASP ZAP. La diferencia crítica respecto al pentesting web tradicional es que las APIs exponen la lógica de negocio directamente, sin una capa de presentación que filtre o valide las solicitudes del usuario.

Por qué las APIs son el vector más subestimado

Gartner proyectó en 2022 que para 2025 las APIs serían el vector de ataque más frecuente en aplicaciones empresariales. En 2026, esa proyección se ha cumplido con creces. Las razones son estructurales:

Las aplicaciones modernas —SaaS, mobile, microservicios— no son monolitos: son colecciones de APIs que se comunican entre sí. Una aplicación React típica hace docenas de llamadas a endpoints REST o GraphQL en cada sesión de usuario. Cada uno de esos endpoints es una superficie de ataque independiente que complementa las pruebas cubiertas en un pentesting de aplicaciones web con metodología OWASP.

El problema de fondo es que las APIs suelen diseñarse priorizando la funcionalidad sobre la seguridad. Los controles de autenticación y autorización se implementan de forma inconsistente entre endpoints. La documentación (Swagger/OpenAPI) que se comparte con clientes también es accesible para atacantes. Y los equipos de desarrollo frecuentemente no someten sus APIs al mismo rigor de revisión de seguridad que aplican a la interfaz de usuario.

Breaches reales atribuibles a APIs inseguras: Optus (Australia, 2022), 9.8 millones de registros expuestos por una API sin autenticación. Twitter/X (2022), 5.4 millones de cuentas mediante un endpoint de verificación de email sin rate limiting. Peloton (2021), datos de salud de millones de usuarios accesibles sin autenticación a través de la API móvil.

OWASP API Security Top 10 2023: los riesgos que debes conocer

La edición 2023 del OWASP API Security Top 10 fue una revisión sustancial de la lista 2019, con categorías redefinidas para reflejar los patrones de ataque observados en los últimos años:

API1:2023 – Broken Object Level Authorization (BOLA)

El riesgo más crítico, y el más frecuente. BOLA (equivalente al IDOR en aplicaciones web) ocurre cuando un endpoint acepta un ID de objeto y no verifica que el usuario autenticado tiene permiso para acceder a ese objeto específico.

GET /api/v1/orders/78234
Authorization: Bearer <token_usuario_A>

Si este request devuelve los datos del pedido 78234 que pertenece al usuario B, la API tiene BOLA. La solución no es ofuscar los IDs: es implementar autorización a nivel de objeto en cada endpoint.

API2:2023 – Broken Authentication (Autenticación Rota)

Mecanismos de autenticación débiles o mal implementados: tokens JWT con algoritmo none aceptados, secrets de firma triviales, refresh tokens con vida útil excesiva, ausencia de rate limiting en endpoints de login, y credenciales de API hardcodeadas en código fuente o repositorios públicos.

Un hallazgo clásico: un JWT firmado con el secret secret123 descubierto en un repositorio público de GitHub que el equipo olvidó rotar.

API3:2023 – Broken Object Property Level Authorization (BOPLA)

Categoría nueva en 2023. Cubre dos patrones: Mass Assignment (el cliente envía propiedades adicionales que el servidor acepta sin validación, como {"role": "admin"} en un request de actualización de perfil) y Excessive Data Exposure (el servidor devuelve más propiedades de las necesarias, incluyendo campos sensibles).

API4:2023 – Unrestricted Resource Consumption

Ausencia de rate limiting en endpoints costosos: generación de reportes, envío de emails, búsquedas complejas, operaciones de criptografía. Sin límites, un atacante puede ejecutar un DoS económico (aumentando costos de infraestructura cloud) o de disponibilidad.

API5:2023 – Broken Function Level Authorization (BFLA)

Diferencia de API1: mientras BOLA es sobre acceso a objetos individuales, BFLA es sobre acceso a funciones o roles. Un usuario normal que puede acceder a /api/admin/users sin tener rol administrador tiene BFLA.

API6:2023 – Unrestricted Access to Sensitive Business Flows

Flujos de negocio que pueden abusarse a escala mediante automatización: scraping masivo de precios, registro automatizado de cuentas para spam, compra automatizada de inventario limitado (scalping). No es un bug de programación sino una ausencia de controles anti-automatización.

API7:2023 – Server-Side Request Forgery (SSRF)

Cuando la API acepta URLs como parámetros y las consume sin validación, un atacante puede redirigir las solicitudes hacia recursos internos: el servicio de metadatos de AWS (http://169.254.169.254/latest/meta-data/), servicios internos sin autenticación, o incluso el sistema de archivos local.

API8:2023 – Security Misconfiguration

Headers de seguridad ausentes, CORS mal configurado (wildcards en Access-Control-Allow-Origin), versiones antiguas de TLS aceptadas, verbos HTTP no necesarios habilitados (PUT, DELETE sin restricción), y documentación Swagger expuesta en producción.

API9:2023 – Improper Inventory Management

APIs de versiones anteriores (v1, beta) que siguen activas y accesibles aunque la versión actual sea v3. Estas versiones legacy frecuentemente no tienen los mismos controles de seguridad que la versión más reciente y son ignoradas en los procesos de revisión de seguridad.

API10:2023 – Unsafe Consumption of APIs

El vector inverso: la propia aplicación consume APIs de terceros sin validar adecuadamente las respuestas. Si una API de tercero es comprometida o devuelve datos maliciosos, la aplicación que los consume sin sanitización se convierte en el vector de ataque.

Diferencias metodológicas: REST, GraphQL y SOAP

El tipo de arquitectura de API determina los vectores de ataque prioritarios y las herramientas que se utilizan:

REST APIs

El caso más común. Los vectores principales son BOLA/IDOR en parámetros de ruta y query string, manipulación de tokens JWT (cambio de algoritmo, secret débil, claims modificados), CORS misconfiguration, y exposición de datos en respuestas verbosas.

Herramientas: Burp Suite Pro (Repeater, Intruder, Scanner), OWASP ZAP con HUD, Postman para construcción de colecciones de prueba.

Técnica clave: Enumerar todos los endpoints disponibles mediante fuzzing de directorios con wordlists específicas para APIs (SecLists /Discovery/Web-Content/api/) y análisis de la documentación OpenAPI/Swagger si está disponible.

GraphQL APIs

GraphQL introduce vectores específicos: introspección (permite a un atacante descubrir todo el esquema de la API, incluyendo queries, mutations y tipos), query batching para amplificar solicitudes, query depth nesting para ejecutar DoS mediante queries recursivos, y field duplication para evadir rate limiting.

# Query de introspección que revela todo el esquema
{ __schema { types { name fields { name } } } }

La mayoría de las APIs GraphQL en producción deberían deshabilitar la introspección. Una cantidad alarmante no lo hace.

Herramientas: InQL (extensión de Burp Suite para GraphQL), GraphQL Voyager para visualizar el esquema, Altair para construcción de queries de prueba.

SOAP / XML APIs

Menos común en desarrollos nuevos pero frecuente en sectores regulados (banca, gobierno, salud). Los vectores específicos incluyen XML injection, XXE (XML External Entity) para lectura de archivos locales o SSRF, WSDL harvesting para descubrir operaciones disponibles, y WS-Security misconfiguration.

Pruebas de autenticación en APIs: JWT, OAuth 2.0 y API Keys

La autenticación es el área de mayor criticidad en APIs. Los patrones de fallo más frecuentes:

JWT (JSON Web Tokens):

Algoritmo none: el token se acepta sin firma ({"alg":"none"})
Cambio de RS256 a HS256 con la clave pública como secret
Claims sin validación (exp, iss, aud ignorados)
Tokens con vida útil excesiva (semanas o meses)
JWK Set URL no validada (permite al atacante servir su propia clave)

OAuth 2.0:

state parameter no validado (CSRF en flujo de autorización)
redirect_uri con wildcard o validación insuficiente
Tokens de acceso con scopes excesivos
Ausencia de PKCE en flows mobile/SPA
Implicit flow habilitado (deprecado en OAuth 2.1 por razones de seguridad)

API Keys:

Claves sin expiración ni rotación
Transmisión en query string en lugar de header (queda en logs de servidor)
Claves hardcodeadas en código fuente (detectable con herramientas como TruffleHog o GitLeaks)
Sin restricción por IP o dominio de origen

DAST automatizado vs pentest manual de APIs: por qué la automatización no es suficiente

Una confusión frecuente en los equipos de seguridad es asumir que un escáner DAST (Dynamic Application Security Testing) integrado en el pipeline de CI/CD cubre las mismas vulnerabilidades que un pentest manual de APIs. La diferencia es fundamental y tiene implicaciones directas sobre el nivel de riesgo residual.

Qué cubre el DAST automatizado: Los escáneres DAST son eficaces para detectar vulnerabilidades técnicas conocidas y reproducibles de forma sistemática: inyección SQL, XSS reflejado, configuraciones incorrectas de cabeceras HTTP, versiones desactualizadas de TLS y CORS con wildcard. Su ventaja es la escala — pueden ejecutarse en cientos de endpoints simultáneamente, en cada build, sin intervención humana.

Qué no cubre el DAST automatizado: Las categorías más críticas del OWASP API Security Top 10 2023 son específicamente difíciles o imposibles de detectar con herramientas automatizadas. BOLA (API1) requiere que el pentester entienda el modelo de negocio para reconocer qué objeto pertenece a qué usuario y si el acceso es ilegítimo — un escáner no puede saber eso. BFLA (API5) exige intentar ejecutar funciones administrativas con credenciales de usuario regular, lo que demanda comprensión de la lógica de roles. Unrestricted Access to Sensitive Business Flows (API6) — scalping, registro masivo, abuso de flujos de compra — es invisble para herramientas que evalúan requests aislados sin modelar el comportamiento de un atacante con objetivos comerciales.

La complementariedad correcta: El estándar en equipos maduros es usar ambas herramientas con objetivos diferenciados. DAST en CI/CD detecta regresiones técnicas de forma continua y a bajo costo. El pentest manual de APIs — ejecutado por un profesional con metodología OWASP API Security Top 10 — cubre los vectores de lógica de negocio, encadenamiento de vulnerabilidades y escalada de privilegios que la automatización sistemáticamente pasa por alto. Usar solo DAST y llamarlo "pentest de APIs" es el equivalente de instalar un detector de humo en una fábrica de explosivos y considerarlo suficiente.

Preguntas frecuentes

¿Cuáles son los principales riesgos de seguridad en APIs?

Los riesgos más críticos en APIs están documentados en el OWASP API Security Top 10 2023. El más frecuente es BOLA (Broken Object Level Authorization): un usuario accede a objetos de otros usuarios porque la API no verifica permisos a nivel de objeto. Le siguen autenticación rota, exposición excesiva de datos, ausencia de rate limiting y SSRF. Las APIs son el vector más subestimado porque exponen la lógica de negocio directamente, sin capa de presentación que filtre las solicitudes.

¿Cómo se realiza un pentest de APIs REST?

Un pentest de APIs REST comienza con el descubrimiento completo del inventario de endpoints — incluyendo los no documentados — mediante fuzzing con wordlists específicas y análisis del OpenAPI/Swagger disponible. Luego se ejecutan pruebas sistemáticas por cada categoría del OWASP API Security Top 10 2023: BOLA con distintos usuarios, manipulación de tokens JWT, testing de rate limiting, CORS misconfiguration y SSRF. Cada hallazgo se valida manualmente con evidencia de request/response antes de incluirse en el reporte.

¿Qué diferencia hay entre pentesting de APIs y pentesting de aplicaciones web?

El pentesting de APIs se enfoca en la lógica expuesta directamente por los endpoints sin capa de presentación: autorización a nivel de objeto (BOLA/IDOR), mass assignment, consumo irrestricto de recursos y gestión de versiones legacy. El pentesting web incluye también vectores del lado del cliente como XSS, CSRF y manipulación del DOM. Las aplicaciones modernas requieren ambas evaluaciones: una SPA React con backend REST tiene superficie de ataque en los dos niveles.

Las APIs no son una extensión del backend: son la superficie de ataque principal de cualquier aplicación moderna. Evaluarlas con la misma rigurosidad que se aplica a aplicaciones web tradicionales no es opcional — es el estándar mínimo en 2026. Cuando los hallazgos de una API involucran vectores de ataque avanzados como cadenas de escalada de privilegios o movimiento lateral, podría ser el momento de considerar si un ejercicio de Red Team aporta valor adicional para medir la capacidad de detección y respuesta.

Un equipo de pentesting profesional ejecuta evaluaciones de APIs en tres capas: descubrimiento completo del inventario de endpoints (incluyendo los que el cliente no documentó), pruebas sistemáticas por cada categoría del OWASP API Security Top 10, y análisis de explotación encadenada donde hallazgos individuales de severidad media se combinan para alcanzar impacto crítico. WhiteJaguars aplica este enfoque con clasificación CVSS v3.1, evidencia de solicitud/respuesta y retests incluidos.

Pentesting de APIs: riesgos clave y estrategias de análisis