OWASP API Security Top 10 Explicado en Español (con BOLA, BFLA y Mass Assignment)
La guía definitiva del OWASP API Security Top 10 (2023) en español, riesgo por riesgo, con ejemplos y PoCs. Incluye dónde vive hoy el Mass Assignment (BOPLA), BOLA, BFLA y más.
OWASP API Security Top 10 Explicado en Español (con BOLA, BFLA y Mass Assignment)
Categoría: API Security · Web Security · OWASP · Guía de Referencia Nivel: Fundamentos → Intermedio Tiempo de lectura: 20 min Actualizado: agosto 2026 Fuente oficial: owasp.org/API-Security Laboratorio asociado: CP02 API Security · CP05 Bug Bounty Hunter · TribuCibernetica Cyber Range
Las APIs son hoy la superficie de ataque dominante — y fallan de formas que el OWASP Top 10 web no captura del todo. Por eso existe una lista propia. Aquí está el OWASP API Security Top 10 explicado en español, riesgo por riesgo, con ejemplos reales. Y si llegaste buscando "Mass Assignment", te decimos exactamente dónde vive hoy: dentro de API3:2023 (BOPLA). Todo validado contra la fuente oficial.
Antes de empezar: por qué las APIs tienen su propio Top 10
OWASP publicó por primera vez el API Security Top 10 en 2019, porque el Top 10 general para aplicaciones web no capturaba cómo fallan las APIs. La edición vigente es la de 2023, publicada tras cuatro años de datos nuevos.
La diferencia de fondo: el Top 10 web cubre riesgos como inyección o control de acceso a nivel de aplicación. El de APIs ataca la lógica que las APIs exponen directamente al que las llama — autorización a nivel de objeto, de propiedad y de función — más riesgos propios como el inventario indebido de APIs o el consumo inseguro de APIs de terceros. Algunas categorías aparecen en ambas listas (control de acceso, misconfiguration, SSRF), pero resuelven problemas distintos.
Y un dato que importa en 2026: como los LLMs suelen actuar como una capa de API inteligente que interactúa con bases de datos y servicios, muchos de estos riesgos de API son cada vez más relevantes también para aplicaciones de IA.
Índice
- La lista completa (2023) de un vistazo
- Dónde quedó el "Mass Assignment"
- API1:2023 — Broken Object Level Authorization (BOLA)
- API2:2023 — Broken Authentication
- API3:2023 — Broken Object Property Level Authorization (BOPLA)
- API4:2023 — Unrestricted Resource Consumption
- API5:2023 — Broken Function Level Authorization (BFLA)
- API6:2023 — Unrestricted Access to Sensitive Business Flows
- API7:2023 — Server Side Request Forgery (SSRF)
- API8:2023 — Security Misconfiguration
- API9:2023 — Improper Inventory Management
- API10:2023 — Unsafe Consumption of APIs
- Cómo practicar esto en el Cyber Range
- Glosario y referencias oficiales
1. La Lista Completa (2023) de un Vistazo
| ID | Riesgo | En una línea |
|---|---|---|
| API1 | Broken Object Level Authorization (BOLA) | Accedes al objeto de otro usuario cambiando un ID |
| API2 | Broken Authentication | El sistema reconoce como válido a quien no lo es |
| API3 | Broken Object Property Level Authorization (BOPLA) | Lees o escribes propiedades que no deberías (incluye Mass Assignment) |
| API4 | Unrestricted Resource Consumption | Sin límites de recursos → DoS y costos |
| API5 | Broken Function Level Authorization (BFLA) | Invocas funciones de admin siendo usuario común |
| API6 | Unrestricted Access to Sensitive Business Flows | Abuso automatizado de flujos de negocio |
| API7 | Server Side Request Forgery (SSRF) | Fuerzas al servidor a pedir a destinos que eliges |
| API8 | Security Misconfiguration | Configuración insegura |
| API9 | Improper Inventory Management | APIs "fantasma" y versiones viejas expuestas |
| API10 | Unsafe Consumption of APIs | Confiar ciegamente en APIs de terceros |
Nota de lectura clave: API1, API2, API3 y API5 son todos fallos de autorización/autenticación. Es el área de mayor apalancamiento — más de la mitad de la lista gira en torno a "¿quién puede tocar qué?".
2. Dónde Quedó el "Mass Assignment"
Si buscabas un artículo de "Mass Assignment OWASP", aquí está la verdad que casi nadie aclara: Mass Assignment ya no es una categoría propia.
En la edición 2019 existían por separado "Mass Assignment" y "Excessive Data Exposure". En la edición 2023, OWASP las fusionó en una sola categoría: API3:2023 — Broken Object Property Level Authorization (BOPLA). Mass Assignment es hoy la "mitad de escritura" de BOPLA (asignar propiedades que no deberías), y Excessive Data Exposure es la "mitad de lectura" (que te devuelvan propiedades de más).
Así que el tema es plenamente vigente — solo cambió de nombre y de casa. Lo desarrollamos completo en la sección de API3 (sección 5).
3. API1:2023 — Broken Object Level Authorization (BOLA)
Fuente oficial: API1:2023
Es la vulnerabilidad de API más explotada en el mundo real, y fue #1 tanto en 2019 como en 2023.
El modelo mental. La API expone endpoints que reciben un identificador de objeto (un ID de usuario, de factura, de pedido). BOLA ocurre cuando la API no verifica que el objeto solicitado pertenece a quien lo pide. El usuario A pide el objeto de B cambiando el ID, y la API se lo entrega.
Ejemplo — PoC:
# Petición legítima del usuario A a SU pedido:
GET /api/v1/pedidos/8801 HTTP/1.1
Authorization: Bearer <token_de_A>
# El atacante simplemente itera el ID:
GET /api/v1/pedidos/8802 HTTP/1.1
Authorization: Bearer <token_de_A>
# Si devuelve el pedido 8802 (de otro cliente) → BOLA confirmado.
# Escalable a extraer TODA la base iterando IDs.
Cómo se defiende: autorización a nivel de objeto en el servidor, en cada endpoint que recibe un ID; comprobar que el objeto pertenece al usuario del token; usar IDs aleatorios e impredecibles (UUID) no ayuda por sí solo pero sube el costo; y probar el mecanismo de autorización sistemáticamente.
4. API2:2023 — Broken Authentication
Fuente oficial: API2:2023
El modelo mental. Los mecanismos de autenticación están mal implementados, permitiendo al atacante comprometer tokens o suplantar a otros usuarios. Contraseñas débiles o adivinables, cifrado ausente en tránsito o reposo, tokens mal firmados o sin expiración, endpoints de login sin límite de intentos.
Ejemplo: un endpoint de autenticación sin rate-limiting que permite fuerza bruta ilimitada, o un JWT firmado con un algoritmo débil (o con alg: none aceptado por el servidor).
Cómo se defiende: MFA en flujos sensibles; protocolos de autenticación estándar (no inventes el tuyo); validación estricta de tokens (algoritmo, firma, expiración, claims); límites de intentos; y cifrado en tránsito y reposo.
5. API3:2023 — Broken Object Property Level Authorization (BOPLA)
Fuente oficial: API3:2023
Aquí vive el Mass Assignment. BOPLA es la falta de validación de autorización a nivel de propiedad de un objeto — no ya "¿puedes acceder a este objeto?" (eso es BOLA), sino "¿puedes leer o modificar esta propiedad específica del objeto?".
Las dos mitades de BOPLA:
a) Mass Assignment (la mitad de escritura). La API vincula automáticamente los campos que envía el cliente a las propiedades del objeto, sin filtrar cuáles se permiten. El atacante añade una propiedad que no debería poder tocar.
# La app permite actualizar tu perfil. Envías lo esperado...
PATCH /api/v1/perfil HTTP/1.1
Authorization: Bearer <token_de_usuario>
Content-Type: application/json
{ "nombre": "Marco", "email": "marco@ejemplo.com" }
# ...pero pruebas añadir una propiedad privilegiada:
{ "nombre": "Marco", "email": "marco@ejemplo.com", "isAdmin": true }
# Si la API asigna 'isAdmin' sin validar → escalada de privilegios
# por Mass Assignment. Acabas de volverte administrador.
b) Excessive Data Exposure (la mitad de lectura). La API devuelve el objeto completo y espera que el cliente filtre qué mostrar. El atacante lee la respuesta cruda y obtiene propiedades sensibles (hash de contraseña, flags internos, datos de otros).
Cómo se defiende: define explícitamente qué propiedades puede leer y escribir cada rol (allowlist de campos, nunca blocklist); evita el binding automático de todo el body; valida el esquema de respuesta para no devolver de más; y jamás confíes en que el cliente "filtrará".
Conexión web: en el OWASP Top 10 web 2025, estos patrones de autorización de API (BOLA/BFLA) quedaron absorbidos dentro de A01 Broken Access Control. Dos listas, la misma raíz: autorización rota.
6. API4:2023 — Unrestricted Resource Consumption
Fuente oficial: API4:2023
El modelo mental. La API no limita cuántos recursos puede consumir una petición o un cliente: sin rate-limiting, sin límites de tamaño de payload, sin límites de profundidad de consulta (crítico en GraphQL). Permite ataques de denegación de servicio y dispara costos (cómputo, ancho de banda, llamadas a servicios de pago).
Cómo se defiende: límites de tasa y concurrencia por cliente; límites de tamaño de petición y de profundidad de consulta; timeouts; paginación obligatoria; y alertas de gasto en servicios medidos.
7. API5:2023 — Broken Function Level Authorization (BFLA)
Fuente oficial: API5:2023
El modelo mental. Mientras BOLA es sobre objetos (¿puedes ver el pedido de otro?), BFLA es sobre funciones (¿puedes ejecutar una acción de admin siendo usuario común?). Ocurre cuando un usuario de bajo privilegio llama directamente a un endpoint administrativo que la interfaz le oculta, pero el servidor no le niega.
Ejemplo — PoC:
# La UI solo muestra este endpoint a admins, pero el usuario común
# lo llama directo:
DELETE /api/v1/admin/usuarios/500 HTTP/1.1
Authorization: Bearer <token_de_usuario_comun>
# Si el servidor ejecuta el borrado → BFLA. La autorización estaba
# en la interfaz, no en el servidor.
Cómo se defiende: verificar autorización a nivel de función en el servidor para cada endpoint; denegar por defecto; y no depender de que la interfaz "esconda" las funciones privilegiadas.
8. API6:2023 — Unrestricted Access to Sensitive Business Flows
Fuente oficial: API6:2023
El modelo mental. Categoría nueva en 2023. No es un bug técnico, sino el abuso automatizado de un flujo de negocio legítimo: comprar todas las entradas de un concierto con bots para revenderlas, crear cuentas en masa, agotar inventario. La API funciona "bien" — el problema es que no contempla el abuso a escala.
Cómo se defiende: identificar los flujos sensibles al abuso; mecanismos anti-automatización (device fingerprinting, detección de patrones no humanos, CAPTCHA donde aplique); y límites por flujo de negocio, no solo por endpoint.
9. API7:2023 — Server Side Request Forgery (SSRF)
Fuente oficial: API7:2023
El modelo mental. La API recibe una URL del usuario y hace una petición a ella sin validarla. El atacante la apunta a recursos internos: metadatos de la nube (169.254.169.254), servicios internos, o la red privada.
Ejemplo: una función de "importar imagen desde URL" a la que el atacante le pasa http://169.254.169.254/latest/meta-data/ para robar credenciales de la instancia cloud.
Cómo se defiende: allowlist de dominios/destinos permitidos; validación y normalización estricta de URLs; deshabilitar redirecciones no necesarias; y aislar la red de salida del servicio.
Nota de versión: en el Top 10 web 2025, SSRF dejó de ser categoría propia y se integró en A01. En el API Security Top 10 2023 sigue siendo su propia categoría, API7.
10. API8:2023 — Security Misconfiguration
Fuente oficial: API8:2023
El modelo mental. El mismo concepto que en el mundo web, aplicado a APIs: cabeceras de seguridad ausentes, CORS mal configurado (permitiendo cualquier origen), verbos HTTP innecesarios habilitados, mensajes de error verbosos, TLS mal ajustado.
Cómo se defiende: hardening reproducible; CORS restrictivo; deshabilitar métodos y features innecesarias; errores genéricos; y revisión de configuración en cada despliegue.
11. API9:2023 — Improper Inventory Management
Fuente oficial: API9:2023
El modelo mental. No puedes proteger lo que no sabes que existe. Las APIs "fantasma" (shadow APIs), versiones viejas sin retirar (/api/v1 olvidada mientras usas /api/v3), entornos de staging expuestos y documentación desactualizada son puertas abiertas que nadie vigila.
Ejemplo: una versión /api/v1/ deprecada pero aún activa, sin los parches de seguridad que sí tiene la v3, explotable porque nadie recordó apagarla.
Cómo se defiende: inventario completo y actualizado de todas las APIs, versiones y entornos; retirar versiones deprecadas; documentación viva; y descubrimiento continuo de APIs expuestas.
12. API10:2023 — Unsafe Consumption of APIs
Fuente oficial: API10:2023
El modelo mental. Categoría nueva en 2023 que reemplazó a "Logging & Monitoring insuficiente". Se enfoca en el riesgo de confiar ciegamente en los datos que recibes de APIs de terceros. Sueles proteger bien tu API de entradas de usuario, pero tratas la respuesta de una API externa como confiable — y ahí entra el ataque.
Cómo se defiende: trata los datos de APIs de terceros con la misma desconfianza que la entrada de usuario; valida y sanitiza sus respuestas; usa TLS con validación de certificado; y no sigas redirecciones de terceros a ciegas.
13. Cómo Practicar Esto en el Cyber Range
La ruta CP02 — API Security del Cyber Range de TribuCibernetica es donde estos diez riesgos dejan de ser teoría: explotas BOLA iterando IDs, escalas privilegios con Mass Assignment (BOPLA), abusas BFLA llamando endpoints de admin, y montas las defensas correspondientes — en entornos reales y en español. La ruta CP05 — Bug Bounty Hunter te enseña a convertir estos hallazgos en reportes que pagan (BOLA es de las vulnerabilidades más premiadas del mundo).
Conexión con las otras guías OWASP:
- La contraparte web → OWASP Top 10 2025 explicado (donde BOLA/BFLA viven en A01)
- Injection en APIs → nuestra saga de SQL Injection (el Tomo 4 cubre GraphQL y APIs)
- APIs para LLMs → OWASP LLM Top 10
→ Empieza en CP02 gratis → Únete al Discord
14. Glosario y Referencias Oficiales
| Término | Definición |
|---|---|
| BOLA | Broken Object Level Authorization — acceso no autorizado a objetos de otros usuarios (API1) |
| BOPLA | Broken Object Property Level Authorization — lectura/escritura no autorizada de propiedades (API3); incluye Mass Assignment |
| BFLA | Broken Function Level Authorization — ejecución no autorizada de funciones privilegiadas (API5) |
| Mass Assignment | Asignar propiedades no permitidas al vincular el body a un objeto; hoy dentro de BOPLA |
| Excessive Data Exposure | Devolver más propiedades de las necesarias; hoy dentro de BOPLA |
| Shadow API | API expuesta pero no documentada ni gestionada |
| SSRF | Server-Side Request Forgery — forzar peticiones del servidor a destinos elegidos por el atacante |
Referencias oficiales de OWASP:
- OWASP API Security Project — owasp.org/www-project-api-security
- API Security Top 10 2023 (índice oficial) — owasp.org/API-Security/editions/2023/en/0x11-t10
- Cada categoría API1–API10 enlazada en su sección correspondiente arriba
Guía elaborada por TribuCibernetica con base en la edición oficial OWASP API Security Top 10:2023, validada contra owasp.org en agosto de 2026. El OWASP API Security Top 10 se publica bajo licencia Creative Commons. Contenido educativo independiente, no oficial de OWASP. Practica las técnicas ofensivas exclusivamente en entornos autorizados; en México, el acceso no autorizado a sistemas constituye delito (Art. 211 bis del Código Penal Federal).