Los 10 riesgos OWASP de seguridad de APIs vs IBM API Connect

/en
API Security · OWASP · IBM API Connect

Los 10 riesgos OWASP de seguridad de APIs vs IBM API Connect.

Los 10 riesgos críticos de seguridad de APIs según OWASP, uno a uno, mapeados a las capacidades reales de IBM API Connect y DataPower. Dónde el gateway resuelve, dónde ayuda y dónde el trabajo sigue siendo del backend.

10 min lectura●Análisis técnico●

Las APIs son el principal vector de ataque contra aplicaciones empresariales y, con la adopción creciente de agentes de IA y protocolos como MCP, el inventario de consumidores autónomos sigue creciendo. Los riesgos del OWASP API Security Top 10 (edición 2023, vigente) no cambian — solo se vuelven más críticos.

Esta entrada va al grano: mapeo riesgo por riesgo de qué cubre IBM API Connect + DataPower y qué no. De los 10, el gateway tiene cobertura nativa en 4, ayuda parcial en otros 4, impacto indirecto en 1 y deja 1 al backend. Saber cuál es cuál es lo que diferencia a un equipo formado de uno que descubre las cosas en producción.

10
Riesgos críticos
en la lista OWASP
2023
Última edición
vigente OWASP
4 / 10
Cobertura nativa
del gateway IBM
3
Categorías nuevas
frente a 2019
01 · Contexto

¿OWASP qué y por qué importa más en 2026?

La OWASP API Security Top 10 es la lista de referencia del sector con los 10 riesgos más críticos de seguridad en APIs. La última edición es de 2023 — y en 2026 sigue siendo el estándar, sin reedición pendiente. Lo que ha cambiado no es la lista, es el contexto en el que aplica:

  • Las APIs siguen siendo uno de los principales vectores de ataque contra aplicaciones empresariales.
  • La adopción creciente de agentes de IA y protocolos como MCP añade consumidores autónomos al mapa — distintos de las apps y los partners de toda la vida.
  • El API sprawl — APIs no documentadas ni gobernadas — sigue siendo un reto recurrente en organizaciones con muchos años de integraciones acumuladas.

En este escenario el gateway deja de ser solo un proxy y se convierte en la pieza donde se aplican (o se dejan de aplicar) los controles del OWASP API Top 10.

Cómo leer este post

Cada riesgo lleva un badge de cobertura con cuatro niveles: Total (lo cubre el gateway por sí solo), Parcial (ayuda pero requiere diseño correcto), Indirecto (aporta poco) o No directo (el problema está en el backend). El objetivo no es vender — es que sepas dónde poner el esfuerzo.

02 · Los 10 riesgos

OWASP API Top 10 (2023) · mapeo a IBM API Connect + DataPower

API1:2023 Broken Object Level Authorization (BOLA) Cobertura parcial

El cliente cambia un ID en la URL (/orders/42 → /orders/43) y accede a un objeto que no es suyo. Sigue siendo el riesgo nº1 — porque la lógica de propiedad vive en el backend.

Lo que SÍ hace el gateway Valida JWT, extrae claims de usuario y los pasa al backend en headers firmados. Puede aplicar políticas por scope OAuth.
Lo que tiene que hacer tu backend Comprobar que el user_id del token coincide con el dueño del objeto solicitado en cada endpoint. El gateway no conoce el modelo de datos.
API2:2023 Broken Authentication Cobertura nativa

Tokens mal validados, mecanismos de autenticación inseguros, JWT firmados con none, credenciales por defecto. La autenticación es el plano donde el gateway aporta más, sin discusión.

Lo que SÍ hace el gateway OAuth 2.0 completo (authorization server, scopes, refresh), JWT validation (firma, exp, aud, iss), OIDC, mTLS, API keys con rotación, integración con LDAP/AD/IAM externo. Es WD509G y WE752G en estado puro.
Lo que tiene que hacer tu backend Confiar en el resultado de validación del gateway. Si validas otra vez en el backend, asegúrate de no introducir inconsistencias.
API3:2023 Broken Object Property Level Authorization Cobertura parcial

El backend devuelve más campos de los que el usuario debería ver (excessive data exposure) o acepta más campos en escritura (mass assignment). Combina los antiguos API3:2019 y API6:2019.

Lo que SÍ hace el gateway Transformaciones de respuesta (mascarado de campos sensibles, filtrado por scope). DataPower puede aplicar XSLT o políticas GatewayScript para sanear payloads.
Lo que tiene que hacer tu backend No devolver campos que el rol no debería ver. No aceptar campos no esperados en escritura. El gateway puede ayudar a posteriori, pero la responsabilidad sigue siendo del diseño del API.
API4:2023 Unrestricted Resource Consumption Cobertura nativa

Falta de rate limiting, ausencia de quotas, payloads sin tamaño máximo. Antes se llamaba "Lack of Resources & Rate Limiting". Donde el gateway brilla.

Lo que SÍ hace el gateway Rate limit por consumidor, por plan, por endpoint. Quotas diarias/mensuales. Throttling configurable. Límite de tamaño de payload. Burst control. Todo configurable en el manager y aplicado en DataPower o Nano Gateway.
Lo que tiene que hacer tu backend Definir los SLAs de cada plan/consumidor. El gateway aplica lo que tú decidas — no decide por ti qué es razonable.
API5:2023 Broken Function Level Authorization Cobertura parcial

Un usuario normal accede a endpoints de admin porque la API no comprueba el rol más allá de la autenticación.

Lo que SÍ hace el gateway Aplicar políticas distintas por endpoint en función de scopes OAuth. Bloquear acceso a rutas admin desde tokens sin el scope correspondiente. Routing condicional.
Lo que tiene que hacer tu backend Diseñar bien los scopes OAuth desde el principio. Un scope admin es inútil si lo conceden todos los flujos. El gateway aplica reglas — no las inventa.
API6:2023 Unrestricted Access to Sensitive Business Flows Cobertura parcial

Una API expone un flujo de negocio sensible (compras, transferencias, votación) y un atacante automatiza miles de llamadas legales pero abusivas. El daño no viene de un exploit técnico — viene del volumen.

Lo que SÍ hace el gateway Throttling por consumidor, detección de patrones, geo-blocking, CAPTCHA gateway integration, integración con WAF (DataPower) para reglas avanzadas.
Lo que tiene que hacer tu backend Identificar cuáles son tus flujos sensibles (no todos lo son) y diseñar contadores de negocio que el gateway pueda consumir vía analytics.
API7:2023 Server Side Request Forgery (SSRF) No directo

Una API acepta una URL del usuario y la usa para hacer peticiones internas — el atacante la usa para atacar tu red interna. Vector subiendo en cloud por el uso de servicios de metadata (AWS IMDS, Azure IMDS).

Lo que SÍ hace el gateway Poco directamente. Si el backend reenvía vía el gateway hacia outbound, se puede restringir destinos. Pero no es el patrón habitual.
Lo que tiene que hacer tu backend Validar URLs entrantes contra lista blanca. Bloquear rangos internos (RFC 1918, link-local). No usar inputs de usuario directamente en peticiones HTTP server-side. Esto es 95% backend.
API8:2023 Security Misconfiguration Cobertura nativa

Defaults inseguros, TLS mal configurado, CORS demasiado abierto, headers de seguridad ausentes, errores stack-trace expuestos. El clásico que sigue causando incidentes.

Lo que SÍ hace el gateway DataPower viene con defaults seguros y permite políticas centralizadas de TLS, CORS, headers de seguridad (HSTS, CSP, X-Frame-Options), supresión de stack traces. Auditoría unificada de configuración desde API Connect V12.
Lo que tiene que hacer tu backend No anular en el backend lo que el gateway ya hace correctamente (errores de doble configuración). Mantener defaults seguros también dentro de la red interna.
API9:2023 Improper Inventory Management Cobertura nativa

APIs zombi en producción, versiones antiguas sin retirar, entornos de staging accesibles desde internet, documentación inexistente. La base del API sprawl.

Lo que SÍ hace el gateway El núcleo de API Connect es exactamente esto: catálogo de APIs, versionado, ciclo de vida (creación, publicación, deprecación, retirada), gobierno federado en V12 (gateways heterogéneos visibles desde un solo plano), Developer Portal con documentación auto-generada.
Lo que tiene que hacer tu backend Cumplir el proceso de gobierno: cada API publicada pasa por el manager. Las APIs que no están en el catálogo son shadow — y son las que generan brechas.
API10:2023 Unsafe Consumption of APIs Cobertura indirecta

Tu app consume APIs de terceros sin validar lo que devuelven — y un proveedor comprometido te lleva por delante. Nuevo en 2023, especialmente relevante en arquitecturas con muchas integraciones SaaS.

Lo que SÍ hace el gateway Si el consumo de APIs externas pasa por el gateway hacia outbound, se pueden aplicar políticas de schema validation, sanitización de respuestas y rate limit al proveedor. No siempre es el patrón.
Lo que tiene que hacer tu backend Validar contratos de API consumidos. No confiar en payloads recibidos. Aislar dependencias. Esto es disciplina de desarrollo, más que configuración de plataforma.
03 · Resumen visual

Los 10 riesgos, de un vistazo

Tabla de cobertura del gateway IBM (API Connect + DataPower) por riesgo OWASP:

Riesgo Nombre corto Cobertura gateway Capacidad clave
API1
BOLA
Parcial
JWT claims propagados
API2
Broken Authentication
Nativa
OAuth, JWT, OIDC, mTLS
API3
Object Property Level Authz
Parcial
Mascarado de campos
API4
Unrestricted Resource Consumption
Nativa
Rate limit, quotas, throttling
API5
Function Level Authorization
Parcial
Scopes OAuth + políticas
API6
Sensitive Business Flows
Parcial
Detección patrones, WAF
API7
SSRF
No directo
Backend principalmente
API8
Security Misconfiguration
Nativa
TLS, CORS, headers, auditoría
API9
Improper Inventory Management
Nativa
Catálogo, versionado, V12
API10
Unsafe Consumption of APIs
Indirecta
Validación de contratos

Balance: 4 cobertura nativa (API2, API4, API8, API9) · 4 cobertura parcial (API1, API3, API5, API6) · 1 indirecta (API10) · 1 no directa (API7).

04 · El factor humano

El gateway aplica reglas — alguien tiene que diseñarlas

La conclusión honesta tras leer el mapeo es la que rara vez sale en el material comercial: el gateway es una herramienta potente, pero sin criterio propio. Aplica al pie de la letra lo que tu equipo configure. Si los scopes OAuth están mal pensados, el gateway no los arregla por ti. Si pones un rate limit de 10.000 req/s en un endpoint de transferencias, el gateway te ayuda a fallar más rápido.

Las capacidades de API Connect y DataPower son las que has visto arriba. La diferencia entre "tenemos API Connect" y "tenemos API Connect mitigando 8 de los 10 riesgos OWASP correctamente" la marca el equipo que lo opera.

Los 5 cursos oficiales que cubren todo esto WD509G y WD514G para el núcleo de API Connect; WE761G, WE752G y WE754G para DataPower. En español, in-company desde 2 personas.
Catálogo de cursos
Qué hay en los cursos

No es solo "qué hace cada nodo de DataPower". Es cuándo aplicar qué política, cómo diseñar scopes OAuth que escalen, cuándo el rate limit por consumer se queda corto y conviene pasar a business flow throttling — el tipo de decisión operativa que se ve en proyecto, no en el manual.

Resumen

Lo esencial en 5 puntos

Para llevarse de este post

→ OWASP API Top 10 2023 sigue siendo el estándar vigente en 2026 — sin reedición pendiente, pero más relevante por la era agéntica.

→ El gateway IBM (API Connect + DataPower) tiene cobertura nativa de 4 riesgos — autenticación, rate limiting, configuración segura e inventario de APIs.

→ Ayuda parcialmente en otros 4 (BOLA, property authz, function authz, business flows) — pero la lógica de negocio sigue siendo del backend.

→ SSRF y unsafe consumption son territorio principalmente de los developers — no esperes que el gateway los resuelva por ti.

→ La diferencia entre tener la herramienta y mitigar los riesgos es la formación del equipo que la configura.

FAQ

Preguntas frecuentes

¿La versión 2023 de OWASP API Top 10 sigue vigente en 2026?

Sí. La OWASP Foundation publicó la última actualización del API Security Top 10 en 2023 y no hay versión nueva publicada en 2026. La lista sigue siendo el estándar de referencia del sector — más relevante todavía con la adopción de agentes de IA que consumen APIs masivamente.

¿API Connect / DataPower cubre los 10 riesgos OWASP?

No, y eso no es un defecto del gateway. De los 10 riesgos, el gateway cubre completamente 4 (API2, API4, API8, API9), ayuda parcialmente en 4 (API1, API3, API5, API6), tiene impacto indirecto en 1 (API10) y deja 1 a backend (API7 SSRF). El resto requiere diseño correcto del backend y validación humana.

¿Qué riesgo es el más fácil de mitigar con el gateway?

API4 (Unrestricted Resource Consumption) y API9 (Improper Inventory Management). Rate limiting, quota plans y throttling son territorio nativo de API Connect. El catálogo, versionado y gobierno federado de V12 cubren directamente la gestión de inventario.

¿Dónde aprendo a configurar todo esto en API Connect?

Los cursos oficiales WD509G (admins) y WD514G (devs), más los de DataPower (WE761G, WE752G, WE754G). En SIXE los impartimos in-company desde 2 personas con ingenieros que despliegan estos productos en cliente. El catálogo está en el hub de formación API Connect.

Fuentes

Referencias

OWASP Foundation. OWASP API Security Project. owasp.org/www-project-api-security

OWASP Foundation. API Security Top 10 (2023 edition). owasp.org/API-Security · edición 2023

IBM. IBM API Connect — Cloud Pak for Integration. ibm.com/products/api-connect

IBM. IBM DataPower Gateway. ibm.com/products/datapower-gateway

SIXE. Hub formación oficial IBM API Connect. sixe.es/formacion/ibm-api-connect

Última actualización: .

Formación API Connect & DataPower

¿Hablamos de formación para tu equipo?

Cuéntanos qué riesgos OWASP os preocupan más, cuántos sois y dónde estáis. Te respondemos en menos de 24 horas con itinerario, modalidad y presupuesto cerrado. Sin formularios kilométricos.

Ver el hub completo Contacto
Informix 15, watsonx y fin de soporte de 12.10 en 2026
SIXE