OWASP API Security Top 10 (2023): los diez riesgos de las APIs explicados y cómo probarlos

Por Kike Gandia · Co-Fundador y CEO, OSCP

El OWASP API Security Top 10 es la lista de referencia de los riesgos de seguridad más críticos en APIs, publicada por la fundación OWASP. Su edición vigente es la de 2023, y la usan equipos de desarrollo, auditores y clientes como vocabulario común para hablar de seguridad de APIs. En esta guía tienes los diez riesgos explicados en español con ejemplos de peticiones reales, qué cambió respecto a la edición de 2019, cuáles detecta un escáner y cuáles solo una prueba manual, y cómo usar la lista en el día a día del desarrollo sin confundirla con un estándar de certificación.

Qué es el OWASP API Security Top 10 y por qué existe aparte del Top 10 web

OWASP (Open Worldwide Application Security Project) es una fundación sin ánimo de lucro conocida sobre todo por el OWASP Top 10 de aplicaciones web. En 2019 su proyecto de seguridad de APIs publicó una lista específica, porque las APIs fallan de forma distinta a una web tradicional:

Exponen objetos y funciones directamente. Una web renderiza en el servidor lo que el usuario puede ver; una API devuelve datos y deja que el cliente —una SPA, una app móvil, otro servicio— decida qué mostrar. Si la API devuelve de más o no comprueba de quién es cada objeto, no hay interfaz que lo tape.
La autorización se dispersa. Cada endpoint, cada método y a veces cada campo necesitan su propia comprobación. Basta con olvidar una.
Hay más superficie y menos visibilidad. Versiones antiguas que siguen activas, endpoints internos publicados, APIs de partners y microservicios que se llaman entre sí.
Las herramientas clásicas ven poco. Un escáner web encuentra inyecciones y cabeceras ausentes, pero no sabe que la factura 1043 pertenece a otro cliente.

La edición vigente es la de 2023, publicada en versión estable en junio de ese año. Es un documento de concienciación: ordena los riesgos más frecuentes y graves, explica cómo se explotan y cómo prevenirlos. No es un estándar con requisitos verificables; para eso OWASP mantiene el ASVS (Application Security Verification Standard), cuya versión 5.0 se publicó en 2025.

Los diez riesgos de un vistazo

Código	Riesgo	Qué es en una frase	Ejemplo
API1:2023	Broken Object Level Authorization (BOLA)	La API no comprueba que el objeto pedido pertenece a quien lo pide	Cambiar el identificador de una factura en la URL devuelve la de otro cliente
API2:2023	Broken Authentication	Los mecanismos de autenticación se pueden saltar o abusar	Login sin límite de intentos, tokens que no se validan o no caducan
API3:2023	Broken Object Property Level Authorization	La API expone o deja modificar propiedades que el usuario no debería	Enviar "role": "admin" en el cuerpo de una actualización de perfil y que se guarde
API4:2023	Unrestricted Resource Consumption	Sin límites de peticiones, tamaño o coste	Un endpoint que envía SMS sin límite dispara la factura del proveedor
API5:2023	Broken Function Level Authorization (BFLA)	Un usuario normal puede llamar a funciones de administración	DELETE /api/users/77 funciona con un token de usuario estándar
API6:2023	Unrestricted Access to Sensitive Business Flows	Un flujo de negocio legítimo se puede automatizar de forma abusiva	Bots que compran todo el stock de un lanzamiento o crean miles de cuentas para cobrar bonos
API7:2023	Server Side Request Forgery (SSRF)	La API descarga una URL que controla el atacante	Un campo «importar desde URL» que acaba leyendo el servicio de metadatos del cloud
API8:2023	Security Misconfiguration	Configuración insegura en cualquier capa	CORS que acepta cualquier origen con credenciales, errores con trazas internas
API9:2023	Improper Inventory Management	No saber qué APIs, versiones y entornos hay expuestos	La /v1 sin los controles de la /v2 sigue activa en producción
API10:2023	Unsafe Consumption of APIs	Confiar ciegamente en los datos de APIs de terceros	Guardar sin validar lo que devuelve un proveedor y ejecutar una inyección almacenada

Tres de los diez (API1, API3 y API5) son fallos de autorización, cada uno a un nivel distinto: el objeto, la propiedad y la función. No es casualidad: es lo que más se rompe en una API y lo que menos ven las herramientas automáticas.

Qué cambió respecto a la edición de 2019

Las notas de la edición de 2023 destacan cuatro cambios: la fusión de la exposición excesiva de datos y la asignación masiva en una sola categoría, más peso del consumo de recursos y dos categorías nuevas, la de flujos de negocio sensibles y la de consumo inseguro de APIs. Comparando las dos listas completas se ven el resto de movimientos:

Edición 2019	Edición 2023	Qué pasó
API1 Broken Object Level Authorization	API1 Broken Object Level Authorization	Se mantiene en el primer puesto
API2 Broken User Authentication	API2 Broken Authentication	Se amplía a la autenticación de cualquier cliente, no solo usuarios
API3 Excessive Data Exposure y API6 Mass Assignment	API3 Broken Object Property Level Authorization	Se fusionan: las dos son autorización a nivel de propiedad, una al leer y otra al escribir
API4 Lack of Resources and Rate Limiting	API4 Unrestricted Resource Consumption	Se amplía al coste: memoria, almacenamiento y facturas de servicios de terceros
API5 Broken Function Level Authorization	API5 Broken Function Level Authorization	Se mantiene
—	API6 Unrestricted Access to Sensitive Business Flows	Nuevo: abuso automatizado de flujos de negocio legítimos
—	API7 Server Side Request Forgery	Nuevo como categoría propia
API7 Security Misconfiguration	API8 Security Misconfiguration	Se mantiene
API9 Improper Assets Management	API9 Improper Inventory Management	Cambia de nombre y añade los flujos de datos hacia terceros
—	API10 Unsafe Consumption of APIs	Nuevo: el riesgo de confiar en APIs ajenas
API8 Injection	—	Sale de la lista como categoría propia; el riesgo sigue existiendo
API10 Insufficient Logging and Monitoring	—	Sale de la lista

Que la inyección ya no tenga categoría propia no significa que haya dejado de importar: sigue siendo un fallo grave, cubierto en el OWASP Top 10 de aplicaciones web y en el ASVS, y cualquier pentest de APIs la prueba.

Autorización: BOLA, propiedades y funciones (API1, API3 y API5)

Los tres riesgos de autorización responden a la misma pregunta —«¿puede este usuario hacer esto?»— a tres niveles distintos:

API1, el objeto. GET /api/v1/facturas/1043 devuelve la factura aunque pertenezca a otro cliente, porque la API comprueba que el token es válido pero no que la factura es suya. Es el fallo más frecuente y el más dañino en APIs, y no se arregla con identificadores aleatorios: un UUID solo dificulta adivinar, no autoriza. Lo tratamos en profundidad en la guía sobre BOLA e IDOR.
API3, la propiedad. Tiene dos caras. Al leer, la API devuelve el objeto completo —con el hash de la contraseña, el coste interno o el correo de otros usuarios— y confía en que el cliente solo muestre lo necesario. Al escribir, acepta cualquier campo que llegue en el cuerpo: si el endpoint de actualizar perfil enlaza el JSON directamente con el modelo, un usuario puede enviar "isAdmin": true o "plan": "enterprise" y que se guarde. Es el antiguo mass assignment.
API5, la función. Un usuario estándar llama a un endpoint de administración —/api/admin/users, un método DELETE, una exportación masiva— y funciona, porque la ruta solo estaba «escondida» en la interfaz. Las APIs con roles complejos, varios tipos de usuario o endpoints de partners son las más propensas.

La prevención es común a los tres: una capa de autorización centralizada que se aplique en cada petición, sobre el objeto, el campo y la acción; listas explícitas de campos que se devuelven y que se aceptan, en lugar de serializar el modelo completo; y denegar por defecto. Y la detección también: hace falta probar con al menos dos usuarios de cada rol y comparar lo que cada uno consigue.

Autenticación: API2 y el abuso de tokens

API2 agrupa todo lo que permite a un atacante hacerse pasar por otro usuario o por otro sistema. En APIs aparece sobre todo así:

Endpoints sensibles sin protección contra fuerza bruta: login, verificación de códigos de un solo uso, recuperación de contraseña. Un código de seis dígitos sin límite de intentos se prueba entero.
Tokens mal validados: JWT que se aceptan sin comprobar la firma, con el algoritmo «none», con una clave débil o sin verificar la caducidad, el emisor o la audiencia.
Credenciales en el sitio equivocado: claves de API dentro de una app móvil o de un bundle de JavaScript, tokens en la URL que acaban en logs y cabeceras Referer.
Flujos de cambio de credenciales sin reautenticación: cambiar el correo o la contraseña sin pedir la actual permite a quien roba una sesión quedarse con la cuenta.
Autenticación entre servicios débil: microservicios que confían en cualquier petición que venga de la red interna.

Los detalles de JWT y de OAuth 2.0 —qué validar en cada token y qué errores de los flujos de autorización se explotan— están en la guía de seguridad de JWT y OAuth en APIs.

Consumo y abuso de negocio: API4 y API6

Estos dos riesgos no requieren ningún fallo de código en sentido clásico: la API hace lo que debe, pero sin límites.

API4, consumo sin restricciones. Cada petición consume algo: CPU, memoria, ancho de banda, almacenamiento o dinero cuando la API llama a un servicio de pago por uso. Los escenarios típicos:

Paginación sin máximo: ?limit=1000000 devuelve la base de datos entera en una respuesta.
Subidas sin tamaño máximo o procesamiento de imágenes sin límite de dimensiones.
Endpoints que envían SMS, correos o llamadas a una API de IA de pago sin cuota por usuario: el ataque no tumba el servicio, te llega en la factura.
Consultas GraphQL anidadas o por lotes que multiplican el trabajo del servidor en una sola petición.

API6, acceso sin restricciones a flujos de negocio sensibles. El flujo es legítimo, pero automatizado a escala hace daño: comprar todo el stock de un producto limitado para revenderlo, reservar y no pagar para bloquear la disponibilidad, crear miles de cuentas para cobrar el bono de bienvenida o publicar spam con cuentas recién creadas. La defensa no es un rate limit genérico, sino entender qué flujos son sensibles para el negocio y protegerlos con controles específicos: detección de automatización, límites por cuenta y dispositivo, verificación adicional en los pasos críticos.

SSRF y APIs de terceros: API7 y API10

API7, Server Side Request Forgery. Cualquier funcionalidad en la que la API descarga algo a partir de una URL que proporciona el usuario es candidata: importar un fichero desde una URL, previsualizar enlaces, registrar un webhook, generar un PDF a partir de HTML, obtener el avatar de una URL. Si el servidor no restringe a dónde puede conectarse, el atacante le pide recursos internos que desde fuera no alcanzaría: paneles de administración, bases de datos sin autenticación en la red interna o el servicio de metadatos del proveedor cloud, que en algunas configuraciones entrega credenciales temporales del rol de la máquina. Por eso un SSRF en una API desplegada en cloud es a menudo el primer eslabón de una cadena que termina en los datos. Defensa: listas de destinos permitidos, bloquear rangos internos y de metadatos tras resolver el DNS, no seguir redirecciones a ciegas y usar la versión del servicio de metadatos que exige sesión.

API10, consumo inseguro de APIs. Los equipos suelen validar con cuidado lo que llega de los usuarios y confiar sin más en lo que devuelve un proveedor: una API de pagos, de geolocalización, de enriquecimiento de datos. Si ese proveedor está comprometido o devuelve algo inesperado, los datos entran sin validar en tu sistema. Ejemplos: seguir redirecciones de la API externa sin comprobar el destino, guardar en la base de datos texto que luego se interpreta como HTML o SQL, o no tener límites de tiempo ni de tamaño en la respuesta. Defensa: tratar las respuestas de terceros como entrada no confiable, validar contra un esquema, usar TLS y fijar qué destinos se aceptan.

Configuración e inventario: API8 y API9

API8, configuración insegura. Es la categoría más amplia, porque cubre toda la pila: el servidor, el framework, el API gateway, el balanceador y el proveedor cloud. Los hallazgos más repetidos:

CORS que refleja cualquier origen y permite credenciales, lo que deja a cualquier web leer las respuestas autenticadas del usuario.
Mensajes de error con trazas, versiones o consultas SQL.
Métodos HTTP que no deberían estar habilitados, o rutas de depuración y documentación interactiva expuestas en producción.
TLS ausente o mal configurado en algún tramo, por ejemplo entre el gateway y el backend.
Cabeceras de caché que permiten guardar respuestas con datos personales en un proxy intermedio.

API9, gestión inadecuada del inventario. No se puede proteger lo que no se sabe que existe. Los casos típicos son la versión antigua de la API que se mantuvo «unas semanas» para clientes que no han migrado y sigue viva sin los controles nuevos, el entorno de staging accesible desde internet con datos reales, endpoints sin documentar que solo usa la app móvil o flujos de datos hacia terceros que nadie ha registrado. Defensa: una especificación OpenAPI que sea la fuente de verdad, generada o validada en el pipeline; un inventario de versiones con fecha de retirada; y descubrimiento periódico de lo que realmente está expuesto, comparándolo con lo documentado. En un pentest, un endpoint vivo que no aparece en la documentación ya es un hallazgo.

Cómo probar cada riesgo: escáner frente a prueba manual

Los escáneres de APIs aportan valor, sobre todo en configuración e inyecciones, pero la mitad de la lista depende de entender quién es cada usuario y qué debería poder hacer. Así se reparte en la práctica:

Riesgo	Lo detecta bien un escáner	Requiere prueba manual
API1 BOLA	Muy poco: no sabe a quién pertenece cada objeto	Sí: dos o más cuentas cruzando identificadores en cada endpoint
API2 Autenticación	En parte: ausencia de límites, tokens sin firma	Sí: flujos de recuperación, MFA, validación de tokens y sesiones
API3 Propiedades	En parte: campos sensibles evidentes en respuestas	Sí: qué campos acepta cada endpoint al escribir y según qué rol
API4 Consumo	En parte: ausencia de rate limiting	Sí: límites de negocio, paginación, coste por petición
API5 Funciones	Poco	Sí: matriz de roles contra endpoints y métodos
API6 Flujos de negocio	No	Sí: requiere entender el negocio
API7 SSRF	En parte, con payloads de colaboración externa	Sí: confirmar qué alcanza desde dentro
API8 Configuración	Bien: CORS, cabeceras, TLS, errores	Para confirmar el impacto real
API9 Inventario	En parte: descubrimiento de rutas y versiones	Sí: comparar lo expuesto con lo documentado
API10 Terceros	No	Sí: revisión de integraciones y, mejor aún, del código

La conclusión práctica: un escaneo automático en el pipeline es útil y barato para API8 y parte de API2, API4 y API9; los fallos de autorización y de lógica, que son los que más datos filtran, necesitan una prueba manual con varios usuarios y roles, idealmente con la especificación OpenAPI o una colección de Postman como punto de partida.

Cómo usar el Top 10 en el ciclo de desarrollo

Usado bien, el Top 10 es una lista de comprobación para cada fase, no solo un informe que se revisa una vez al año:

Diseño: en cada endpoint nuevo, tres preguntas antes de escribir código: de quién es el objeto, qué campos puede leer y escribir cada rol y qué límite de uso tiene.
Desarrollo: autorización centralizada en lugar de comprobaciones repartidas por los controladores; DTO o esquemas explícitos de entrada y salida; límites de paginación y tamaño por defecto.
Pruebas automáticas: tests de autorización con dos usuarios —«el usuario A no puede leer el objeto de B»— en el pipeline de integración continua. Es la forma más barata de evitar que un BOLA corregido vuelva en el siguiente sprint.
Inventario: la especificación OpenAPI como fuente de verdad, con alertas cuando aparece en producción un endpoint que no está en ella.
Verificación independiente: un pentest de la API antes de lanzamientos importantes y tras cambios en autenticación, roles o integraciones.

Y dos límites que conviene tener claros. El Top 10 no es exhaustivo: deja fuera riesgos que en tu API pueden ser críticos, y no sustituye a un modelado de amenazas propio. Tampoco es un estándar de cumplimiento: si un cliente o un auditor pide requisitos verificables, el documento de referencia es el ASVS de OWASP.

FAQ

¿En qué se diferencia del OWASP Top 10 de aplicaciones web?

El Top 10 web cubre los riesgos de las aplicaciones web en general, como las inyecciones o los fallos criptográficos. El de APIs se centra en lo que falla cuando la aplicación expone datos y funciones a través de una interfaz programática: sobre todo autorización a nivel de objeto, propiedad y función, consumo de recursos, inventario y confianza en APIs de terceros. Para una aplicación con API conviene usar los dos.

¿Cuál es la versión vigente del OWASP API Security Top 10?

La edición de 2023, que sustituyó a la primera de 2019. Antes de usar la lista como referencia en un contrato o un informe, comprueba en la web del proyecto de OWASP si se ha publicado una edición posterior.

¿Un escáner automático de APIs cubre el OWASP API Top 10?

Solo en parte. Detecta bien configuraciones inseguras, ausencia de límites y algunos problemas de autenticación, pero apenas ve los fallos de autorización (BOLA, propiedades y funciones) ni el abuso de flujos de negocio, porque no sabe a quién pertenece cada objeto ni qué debería poder hacer cada rol. Esos requieren una prueba manual con varios usuarios.

¿Cumplir el OWASP API Top 10 es un requisito legal o de certificación?

No. Es un documento de concienciación, no una norma ni un estándar certificable. Aun así, clientes, auditores y cuestionarios de seguridad lo usan a menudo como referencia de lo que debe cubrir un pentest de APIs. Si necesitas requisitos verificables, el estándar de OWASP es el ASVS.

¿Se aplica también a GraphQL, gRPC o WebSockets?

Sí: los riesgos son independientes del protocolo. Cambia cómo se manifiestan. En GraphQL, por ejemplo, la autorización a nivel de campo y las consultas anidadas que agotan el servidor son especialmente relevantes; lo explicamos en la guía de GraphQL pentesting.

Nunca hemos auditado nuestra API: ¿por dónde empezamos?

Por el inventario y la autorización. Primero, saber qué endpoints y versiones están realmente expuestos y compararlo con la documentación. Después, probar con dos usuarios de cada rol si uno puede leer, modificar o borrar lo del otro. Esas dos comprobaciones cubren los riesgos que más datos filtran en la práctica.