Aprende a mitigar vulnerabilidades en APIs

Las vulnerabilidades en APIs se concentran en fallos de autorización, no en errores de código exóticos. La referencia del sector es el OWASP API Security Top 10, cuya edición estable sigue siendo la de 2023, y sus tres primeros puestos son variantes del mismo problema: la API comprueba quién eres, pero no si ese dato concreto te pertenece.

Puntos clave

El riesgo número uno es BOLA (autorización rota a nivel de objeto): cambiar un identificador en la petición y acceder al pedido, la factura o el expediente de otro cliente.
Un WAF no resuelve la seguridad de las APIs. Los fallos de autorización viajan en peticiones perfectamente legítimas desde el punto de vista del protocolo.
No puedes proteger las APIs que no sabes que tienes. El inventario de endpoints, versiones antiguas y entornos de pruebas expuestos es el punto de partida.
Las pruebas automatizadas detectan configuración, no lógica. Los fallos de autorización y de flujo de negocio requieren pruebas manuales.
Puedes practicar sobre una API vulnerable real: InsecureShip-API-Lab, el laboratorio gratuito y de código abierto del equipo de seguridad ofensiva de Cylum.

Por qué una API se rompe de forma distinta a una aplicación web

En una aplicación web tradicional, el navegador solo muestra al usuario lo que la interfaz decide enseñarle. Esa capa visual esconde muchos errores: si el botón no está, el usuario no pulsa.

Una API no tiene interfaz. Expone directamente la lógica de negocio y los datos, y espera peticiones de cualquier cliente capaz de construirlas: una aplicación móvil, un integrador, un script. Quien ataca no necesita saltarse la pantalla, porque no hay pantalla. Solo tiene que enviar una petición distinta a la que envía tu aplicación oficial.

De ahí salen las tres diferencias que importan:

La lógica queda al descubierto. Los nombres de los endpoints, los parámetros y la estructura de los objetos son visibles para cualquiera que observe el tráfico de la aplicación.
El control de acceso se aplica petición a petición. Cada endpoint debe decidir por su cuenta si el usuario autenticado tiene derecho sobre ese recurso concreto. Un olvido en un solo método basta.
La superficie crece sola. Cada microservicio, cada versión y cada integración añade endpoints. Y los antiguos rara vez se apagan.

Qué es el OWASP API Security Top 10 y por qué la edición vigente sigue siendo la de 2023

El OWASP API Security Top 10 es una lista de los diez riesgos de seguridad más críticos en interfaces de programación de aplicaciones, publicada por la OWASP Foundation, una organización sin ánimo de lucro dedicada a la seguridad del software. Funciona como documento de concienciación y como marco de referencia para auditorías: cuando un informe de pentesting dice «API1:2023», ambas partes saben exactamente de qué se habla.

Conviene aclarar una confusión muy extendida. El OWASP API Security Top 10 y el OWASP Top 10 de aplicaciones web son listas distintas, mantenidas por comunidades diferentes y con ciclos de publicación independientes:

El OWASP Top 10 de aplicaciones web se renovó recientemente: la edición 2025 se anunció en noviembre de 2025 y su versión final se publicó en enero de 2026.
El OWASP API Security Top 10 mantiene como edición estable la publicada el 5 de junio de 2023. No existe una edición posterior.

Es decir: si alguien te ofrece una auditoría «según el OWASP API Top 10 2025», pregunta a qué se refiere exactamente.

Las 10 vulnerabilidades más críticas en APIs, explicadas

API1:2023 — Autorización rota a nivel de objeto (BOLA)

Qué es. La API comprueba que el usuario está autenticado, pero no que el objeto solicitado le pertenece.

Cómo se explota. Un cliente legítimo consulta /api/pedidos/1043. El atacante prueba con 1044, 1045, 1046. Si la API responde, acaba de acceder a los pedidos de otros clientes. Automatizarlo lleva minutos.

Qué se juega el negocio. Es la vía más habitual de fuga masiva de datos personales, con las consecuencias asociadas en materia de protección de datos.

Cómo se mitiga. Validar la propiedad del objeto en cada endpoint que reciba un identificador, contra la identidad del token y no contra un parámetro que el cliente pueda manipular. Usar identificadores aleatorios (UUID) dificulta la enumeración, pero no sustituye a la comprobación.

API2:2023 — Autenticación rota

Qué es. Fallos en el mecanismo que verifica la identidad: tokens sin firmar o mal validados, ausencia de caducidad, endpoints de recuperación de contraseña sin límite de intentos, claves de API en el código del cliente.

Cómo se explota. Desde probar contraseñas de forma masiva contra /api/login hasta reutilizar un token que nunca expira, o manipular un JSON Web Token cuya firma no se comprueba en el servidor.

Qué se juega el negocio. Suplantación completa de usuarios, incluidos los administrativos.

Cómo se mitiga. Validar siempre la firma y la caducidad del token en servidor. Limitar intentos en autenticación y recuperación. Exigir doble factor en cuentas privilegiadas. Nunca incrustar credenciales en aplicaciones móviles o en código de cliente: son públicas por definición.

API3:2023 — Autorización rota a nivel de propiedad (BOPLA)

Qué es. El acceso al objeto es correcto, pero la API devuelve o acepta campos que ese usuario no debería ver ni modificar.

Cómo se explota. Dos variantes. La exposición: el endpoint del perfil devuelve el objeto completo del usuario, incluidos el hash de la contraseña o el identificador fiscal, y la aplicación simplemente no los pinta. Y la asignación masiva: el atacante añade «rol»: «admin» al cuerpo de la petición de actualización y el servidor lo acepta sin filtrar.

Qué se juega el negocio. Escalada de privilegios y exposición de datos sensibles que ni siquiera aparecen en pantalla.

Cómo se mitiga. Definir explícitamente qué campos se devuelven y cuáles se aceptan en cada endpoint, con listas permitidas. Nunca serializar el objeto entero de base de datos.

API4:2023 — Consumo de recursos sin restricciones

Qué es. La API no limita el volumen ni el coste de lo que un cliente puede pedir.

Cómo se explota. Peticiones masivas al endpoint de búsqueda, paginación con limite=1000000, o abuso de funciones que cuestan dinero por uso: envío de SMS, correos, validaciones biométricas o llamadas a servicios de terceros.

Qué se juega el negocio. Denegación de servicio y, cada vez más, un impacto económico directo en la factura del proveedor cloud.

Cómo se mitiga. Limitación de peticiones por cliente y por endpoint, topes máximos de paginación, límites al tamaño del cuerpo de la petición, control de profundidad en consultas GraphQL y alertas de gasto en los servicios de pago por uso.

API5:2023 — Autorización rota a nivel de función

Qué es. Un usuario normal puede invocar funciones reservadas a otro rol.

Cómo se explota. El atacante observa que el panel de administración llama a /api/admin/usuarios y prueba esa misma ruta con su token de usuario básico. También funciona cambiando el método: si GET /api/facturas/45 está protegido pero DELETE no se comprueba, el resultado es una eliminación no autorizada.

Qué se juega el negocio. Acceso a funciones administrativas: alta de usuarios, exportaciones completas, cambios de configuración.

Cómo se mitiga. Denegar por defecto y conceder de forma explícita. La comprobación de rol debe estar centralizada en el servidor y cubrir todas las combinaciones de ruta y método, no solo las que la interfaz utiliza.

API6:2023 — Acceso sin restricciones a flujos de negocio sensibles

Qué es. El endpoint funciona exactamente como se diseñó, pero el negocio sufre porque alguien lo automatiza a escala.

Cómo se explota. Bots que compran todo el stock de un lanzamiento para revenderlo, creación masiva de cuentas para acumular promociones de bienvenida, reserva automatizada de todas las citas disponibles.

Qué se juega el negocio. Pérdida económica y de reputación sin que exista un fallo técnico que corregir. Es el riesgo que más despista a los equipos de desarrollo, porque el código es correcto.

Cómo se mitiga. Identificar primero qué flujos son sensibles al abuso automatizado. Después, aplicar controles de detección de tráfico no humano, límites por identidad y por dispositivo, y verificaciones adicionales en los momentos críticos del flujo.

API7:2023 — Falsificación de peticiones del lado del servidor (SSRF)

Qué es. La API acepta una dirección proporcionada por el usuario y la consulta sin validarla.

Cómo se explota. Una función de «importar imagen desde URL» recibe una dirección interna de la propia infraestructura. El servidor la consulta desde dentro de la red, saltándose el cortafuegos, y devuelve la respuesta al atacante. Es el camino habitual hacia los servicios de metadatos de los entornos cloud, donde se guardan credenciales.

Qué se juega el negocio. Acceso a servicios internos y robo de credenciales de infraestructura.

Cómo se mitiga. Validar la dirección contra una lista de destinos permitidos, resolver el nombre de dominio antes de la petición y bloquear los rangos internos, desactivar las redirecciones automáticas y aislar en red los servicios que necesiten salir a internet.

API8:2023 — Configuración de seguridad incorrecta

Qué es. El código está bien, la configuración no.

Cómo se explota. Mensajes de error que revelan la traza completa y la versión del framework, CORS abierto a cualquier origen, endpoints de depuración accesibles en producción, cabeceras de seguridad ausentes, servicios con credenciales por defecto.

Qué se juega el negocio. Cada detalle expuesto acorta el tiempo que el atacante necesita para encontrar la vulnerabilidad siguiente.

Cómo se mitiga. Proceso de despliegue reproducible y endurecido por defecto, sin diferencias artesanales entre entornos. Mensajes de error genéricos de cara al cliente y detalle solo en los registros internos. Revisión periódica de la configuración como parte del ciclo, no como tarea de última hora.

API9:2023 — Gestión inadecuada del inventario

Qué es. Versiones antiguas, entornos de pruebas y endpoints olvidados que siguen respondiendo. Son las llamadas shadow APIs (las que existen sin que seguridad lo sepa) y zombie APIs (las que debieron apagarse y siguen vivas).

Cómo se explota. La versión /api/v1 sigue en pie sin los controles que sí se añadieron en /api/v2. O el entorno de preproducción, con datos reales copiados y sin doble factor, es accesible desde internet.

Qué se juega el negocio. Se invierte en proteger la API actual mientras la puerta abierta está en una versión que nadie recuerda.

Cómo se mitiga. Inventario vivo de APIs, entornos y versiones, con responsable asignado. Documentación generada automáticamente desde el código. Política formal de retirada de versiones con fecha de fin de servicio. Descubrimiento periódico desde fuera, que es exactamente lo que hace un análisis de superficie de exposición.

API10:2023 — Consumo inseguro de APIs de terceros

Qué es. Confiar en los datos que devuelve un proveedor externo más de lo que confiarías en los de un usuario.

Cómo se explota. El atacante no ataca tu API: compromete o suplanta el servicio de terceros que tú consultas, y la respuesta manipulada entra en tu sistema sin validación. También cuenta seguir redirecciones ciegas hacia destinos que el proveedor decide.

Qué se juega el negocio. Es la dimensión de cadena de suministro del problema, y crece con cada integración que añades.

Cómo se mitiga. Validar y normalizar todo lo que llega de terceros con el mismo rigor que la entrada de usuario. Comunicación siempre cifrada. Tiempos de espera y comportamiento definido ante fallo. Y un inventario de qué integraciones tienes y qué permisos les has concedido.

Tabla resumen: riesgo, señal de alerta y control principal

Riesgo OWASP 2023	Señal de alerta en tu API	Control principal
API1 · BOLA	El identificador del recurso viaja en la URL sin comprobación de propiedad	Validar propiedad contra el token en cada endpoint
API2 · Autenticación rota	Tokens sin caducidad, login sin límite de intentos	Validación de firma y caducidad, límite de intentos, MFA
API3 · BOPLA	La respuesta incluye campos que la interfaz no muestra	Listas explícitas de campos de entrada y salida
API4 · Consumo sin restricciones	Paginación sin tope, funciones de coste por uso abiertas	Limitación de peticiones y de tamaño, alertas de gasto
API5 · Función no autorizada	Rutas administrativas que responden a tokens normales	Denegar por defecto, comprobación centralizada por ruta y método
API6 · Flujos de negocio	Picos de actividad automatizada en compras o altas	Identificar flujos sensibles y detectar tráfico no humano
API7 · SSRF	La API acepta URLs que le pasa el cliente	Lista de destinos permitidos y bloqueo de rangos internos
API8 · Configuración	Errores con traza completa, CORS abierto	Despliegue endurecido y reproducible, errores genéricos
API9 · Inventario	Versiones antiguas y entornos de pruebas accesibles	Inventario vivo y política de retirada de versiones
API10 · Terceros	Datos de proveedores usados sin validar	Validar la entrada externa como si fuera de usuario

¿Un WAF protege tus APIs?

Solo en parte, y conviene entender exactamente dónde está el límite.

Un cortafuegos de aplicaciones web (WAF) inspecciona el tráfico buscando patrones maliciosos conocidos: intentos de inyección, cargas sospechosas, firmas de herramientas automatizadas. Contra eso funciona bien, y también aporta limitación de peticiones, que ayuda con API4.

El problema es que los tres riesgos principales del Top 10 no tienen patrón malicioso alguno. Cuando un atacante cambia 1043 por 1044, la petición es sintácticamente perfecta: usuario autenticado, formato correcto, parámetro válido. El WAF no tiene forma de saber que ese pedido no es suyo, porque esa información solo existe en la lógica de tu aplicación.

La conclusión práctica: el WAF es una capa útil, no un sustituto de la autorización correcta ni de las pruebas de seguridad sobre la lógica de negocio. Comprar producto no cierra este riesgo.

Cómo integrar la seguridad de APIs en tu ciclo de desarrollo

1. Inventario. Antes que cualquier herramienta: qué APIs existen, quién las mantiene, qué versiones siguen vivas y cuáles están expuestas a internet.

2. Diseño. Definir el modelo de autorización antes de escribir el primer endpoint, y centralizarlo. Cuando cada desarrollador resuelve los permisos a su manera, el olvido es cuestión de tiempo.

3. Pruebas automatizadas en el pipeline. Análisis estático del código, revisión de dependencias y validación del esquema de la API en cada integración. Detecta configuración, dependencias vulnerables y desviaciones del contrato.

4. Pruebas manuales. Los fallos de autorización y de flujo de negocio no los encuentra un escáner, porque requieren entender qué debería poder hacer cada rol. Aquí es donde entra una prueba de intrusión sobre la API.

5. Monitorización. Registrar los accesos denegados, los picos de peticiones por identidad y los patrones de enumeración. La mayoría de los ataques de tipo BOLA dejan un rastro muy reconocible antes de tener éxito: cientos de peticiones secuenciales fallidas.

Practica sobre una API vulnerable real: InsecureShip-API-Lab

La teoría se asienta cuando explotas el fallo con tus propias manos. Por eso el equipo de seguridad ofensiva de Cylum publicó InsecureShip-API-Lab, un laboratorio gratuito y de código abierto creado por Luis Uribe.

Qué es. Una API REST deliberadamente vulnerable, desarrollada en Node.js con MongoDB y preparada para desplegarse con Docker. Simula una plataforma de gestión de envíos y paquetería, con niveles de acceso diferenciados (cliente, empleado, responsable y administrador), seguimiento de paquetes, gestión de entregas y procesamiento de pagos. Cada función incorpora fallos intencionados que reproducen los riesgos del OWASP API Security Top 10 2023.

Para quién es útil:

Equipos de desarrollo que necesitan ver el fallo antes de aprender a evitarlo.
Formación interna en seguridad de aplicaciones.
Preparación de pruebas de API testing y de competiciones tipo Capture The Flag.
Perfiles que empiezan en seguridad ofensiva y quieren un entorno controlado.

Qué incluye. Una guía paso a paso, una colección de peticiones preconfiguradas para reproducir cada vulnerabilidad y versiones corregidas de cada ruta, claramente identificadas, para comparar la implementación insegura con la segura. Incorpora también un comprobador de patrones inseguros con fines didácticos: sirve para entender cómo se detectan estos fallos, no para sustituir a una herramienta de análisis real.

Advertencia importante. InsecureShip es vulnerable por diseño. No debe desplegarse en producción ni exponerse a internet bajo ninguna circunstancia. Úsalo siempre en un entorno local y aislado.

Repositorio: https://github.com/Cylum-Cybersecurity/insecureShip-API-Lab
Guía de uso paso a paso: disponible en el propio repositorio, en el documento Walkthrough – Writeup.

Cuándo conviene una auditoría de seguridad de APIs

Un laboratorio entrena al equipo. No dice nada sobre el estado real de tus APIs en producción. Estos son los momentos en los que una prueba de intrusión específica sobre APIs deja de ser opcional:

Antes de exponer una API a socios o clientes. El coste de arreglarlo después incluye la conversación con el cliente afectado.
Tras un cambio en el modelo de permisos o la incorporación de un rol nuevo. Es cuando aparecen los fallos de autorización.
Al integrar un proveedor externo con acceso a datos.
De forma recurrente, si tu producto evoluciona con despliegues frecuentes. Una auditoría anual sobre una API que cambia cada semana informa de un sistema que ya no existe.
Cuando no sabes cuántas APIs tienes. Ese es, en sí mismo, el resultado de la auditoría.

Qué exigen NIS2 e ISO 27001 sobre la seguridad de las APIs

Ninguna de las dos normas menciona las APIs de forma literal, y esa es precisamente la confusión habitual. Lo que exigen son controles que, en una empresa con producto digital, se materializan en las APIs:

Directiva NIS2 (Directiva UE 2022/2555). Su artículo 21 obliga a las entidades esenciales e importantes a implantar medidas de gestión de riesgos que incluyen la seguridad en la adquisición, desarrollo y mantenimiento de sistemas, la gestión de vulnerabilidades y la seguridad de la cadena de suministro. Una API de producción sin inventario ni pruebas periódicas es difícil de defender ante ese artículo. En España la transposición se ha producido de forma parcial mediante el Real Decreto-ley 7/2025, mientras la Ley de Coordinación y Gobernanza de la Ciberseguridad continúa su tramitación [VERIFICAR el estado en la fecha de publicación].
ISO/IEC 27001:2022. Los controles del bloque de desarrollo seguro cubren directamente este terreno: principios de ingeniería segura, pruebas de seguridad en desarrollo y aceptación, separación de entornos y gestión de vulnerabilidades técnicas.

La lectura para dirección: la evidencia que pide un auditor no es una herramienta comprada, sino un inventario actualizado, un proceso de pruebas documentado y un registro de hallazgos con su corrección.

Preguntas frecuentes sobre seguridad en APIs

¿Cuál es la vulnerabilidad más común en APIs? La autorización rota a nivel de objeto (BOLA), primer puesto del OWASP API Security Top 10 2023. Consiste en que la API verifica que el usuario está autenticado pero no que el recurso solicitado le pertenece. Se explota cambiando un identificador en la petición y permite acceder a datos de otros clientes.

¿Un WAF es suficiente para proteger una API? No. Un WAF detecta patrones maliciosos conocidos y ayuda a limitar el volumen de peticiones, pero no puede identificar fallos de autorización: esas peticiones son técnicamente correctas y solo la lógica de tu aplicación sabe si el usuario tiene derecho sobre ese recurso concreto.

¿Qué son las shadow APIs y las zombie APIs? Las shadow APIs son interfaces en funcionamiento que el equipo de seguridad desconoce, normalmente creadas por desarrollo o por integraciones puntuales. Las zombie APIs son versiones antiguas que debieron retirarse y siguen respondiendo, a menudo sin los controles añadidos en versiones posteriores. Ambas se corrigen con inventario.

¿Cada cuánto hay que hacer pruebas de seguridad sobre las APIs? Depende del ritmo de cambio. Con despliegues frecuentes, lo razonable es combinar pruebas automatizadas en cada integración con pruebas manuales recurrentes, y añadir una revisión específica ante cada cambio del modelo de permisos o incorporación de un rol nuevo.

¿Existe una edición 2025 del OWASP API Security Top 10? No. La edición estable vigente es la de 2023, publicada el 5 de junio de ese año. La confusión viene del OWASP Top 10 de aplicaciones web, cuya edición 2025 se anunció en noviembre de 2025 y se publicó en enero de 2026. Son dos listas independientes con ciclos distintos.

¿Puedo practicar con una API vulnerable sin riesgo? Sí, siempre en un entorno local y aislado. InsecureShip-API-Lab está diseñado para eso: se despliega con Docker en tu equipo e incluye las versiones corregidas de cada ruta para comparar. Nunca debe exponerse a internet ni desplegarse en producción.

Fuentes

OWASP Foundation, OWASP API Security Top 10 2023, edición estable publicada el 5 de junio de 2023. https://owasp.org/API-Security/editions/2023/en/0x00-header/
OWASP Foundation, OWASP API Security Project (página del proyecto e historial de versiones). https://owasp.org/www-project-api-security/
OWASP Foundation, OWASP Top 10:2025 (lista de aplicaciones web, independiente de la de APIs). https://owasp.org/Top10/2025/
Cylum Cybersecurity, repositorio insecureShip-API-Lab. https://github.com/Cylum-Cybersecurity/insecureShip-API-Lab
Directiva (UE) 2022/2555 (NIS2), artículo 21, y Real Decreto-ley 7/2025 de transposición parcial en España.
ISO/IEC 27001:2022, controles de desarrollo seguro y gestión de vulnerabilidades técnicas.