Qué es BOLA: la vulnerabilidad #1 en APIs (OWASP API1, 2026)

Imagínate que eres un comercial de una empresa B2B SaaS y tu plataforma muestra las facturas de tu cuenta en GET /api/companies/42/invoices. Por curiosidad, cambias el 42 por 43. La API responde con un 200 OK y te devuelve las facturas de otro cliente — uno que paga el doble que tú y que casualmente es tu competencia.

No has hecho fuerza bruta. No has roto autenticación. Tu token sigue siendo el mismo, válido, emitido para tu cuenta. El backend te ha dado los datos porque, cuando le pediste el recurso /companies/43, comprobó que estabas autenticado pero no comprobó si esa empresa era la tuya. Eso es BOLA. Y según el OWASP API Security Top 10, sigue siendo la vulnerabilidad número uno en APIs en 2026.

Lo grave de BOLA no es la sofisticación del ataque — no la hay. Lo grave es lo trivial que es de explotar y lo difícil que es de detectar a escala. En esta guía vamos a cubrir qué es exactamente BOLA, por qué aparece en tantas APIs auditadas, cómo se diferencia de IDOR y BFLA, cómo detectarlo de forma manual y automatizada, y qué patrones de código lo previenen sin frenar el desarrollo.

Por qué BOLA es la #1 del OWASP API Top 10

OWASP no eligió BOLA como número uno por casualidad. Lo que mide el Top 10 es la combinación de prevalencia, facilidad de explotación e impacto, y BOLA gana en las tres dimensiones.

Prevalencia. En auditorías de APIs reales, BOLA aparece en una mayoría aplastante de los proyectos analizados. El patrón es siempre el mismo: el equipo construye una API REST con cientos de endpoints siguiendo convenciones razonables (/users/{id}, /orders/{id}, /companies/{id}/invoices), aplica un middleware de autenticación que valida el token JWT, y asume que con eso queda cubierta la seguridad. La autorización a nivel de objeto se delega al desarrollador de cada endpoint, que tiene que acordarse de comprobarla manualmente. En una API mediana con 50–200 endpoints, basta con que falle uno.

Facilidad de explotación. No requiere herramientas especializadas. Basta con autenticar como un usuario legítimo, capturar una petición con DevTools o un proxy como Burp Suite, y modificar el ID en la URL o el body. Si la API responde con datos en lugar de un 403, hay BOLA. Un atacante con conocimientos básicos de HTTP puede encontrarlo en minutos.

Impacto. En APIs multi-tenant (SaaS B2B, plataformas con cuentas de cliente), BOLA significa exposición de datos entre clientes — el escenario que más rápido destruye la confianza en un producto. En APIs B2C, significa exposición de datos personales con implicaciones GDPR directas: el artículo 32 exige medidas técnicas para garantizar la confidencialidad, y un BOLA es exactamente lo contrario. En sectores regulados (fintech, healthtech), BOLA puede activar obligaciones de notificación a la AEPD y a los clientes afectados.

Combina las tres dimensiones y entiendes por qué el OWASP API Security Top 10 lo ha mantenido en primera posición durante dos revisiones consecutivas.

Cómo funciona un ataque BOLA: ejemplos reales

Vamos a ver tres patrones distintos de BOLA, porque la categoría es más amplia de lo que parece. No siempre es "cambiar un número en la URL".

Patrón 1: ID secuencial en la ruta

El caso de libro de texto. La API expone recursos a través de IDs numéricos predecibles.

1# Petición legítima: empresa 42 consulta sus facturas
2GET /api/companies/42/invoices HTTP/1.1
3Host: api.tuapp.com
4Authorization: Bearer <token_user_de_empresa_42>
5
6# Respuesta esperada: 200 OK con las facturas de la empresa 42
7# Respuesta vulnerable: 200 OK también para /companies/43 con el mismo token
8
9GET /api/companies/43/invoices HTTP/1.1
10Host: api.tuapp.com
11Authorization: Bearer <token_user_de_empresa_42>
12# → 200 OK — facturas de un cliente distinto

El servidor extrae el ID de la URL, hace SELECT * FROM invoices WHERE company_id = 43 y devuelve el resultado. Nunca compara 43 con el company_id que está dentro del JWT del usuario. La autenticación pasó. La autorización no existió.

Patrón 2: UUIDs "imposibles de adivinar" que se filtran

Es el error más común en equipos que ya han oído hablar de BOLA y han intentado mitigarlo cambiando IDs numéricos por UUIDs. La idea es que un UUID v4 tiene 122 bits de entropía y nadie lo va a adivinar. Es cierto. Pero los UUIDs se filtran constantemente:

• En URLs compartidas en Slack, en correos, en tickets de soporte.
• En logs de acceso accesibles para más personas de las debidas.
• En respuestas de otros endpoints (un endpoint público que devuelve listados con UUIDs incluidos).
• En el frontend, donde cualquier usuario puede ver los UUIDs de otros recursos en la consola del navegador o en el HTML.

Un UUID que se filtra y no tiene comprobación de autorización detrás es exactamente igual de vulnerable que un ID secuencial. La diferencia es que es más difícil enumerar masivamente, pero la explotación dirigida es idéntica.

Patrón 3: ID en el body de un POST/PUT

El más fácil de pasar por alto en revisiones de código, porque la URL no contiene nada sospechoso.

1// PUT /api/invoices/update
2// Cabecera: Authorization: Bearer <token_user_de_empresa_42>
3
4// Petición legítima
5{
6"invoice_id": "inv_42_a1b2c3",
7"status": "paid"
8}
9
10// Ataque: invoice_id de otra empresa
11{
12"invoice_id": "inv_43_x9y8z7",
13"status": "cancelled"
14}
15// → 200 OK — factura ajena marcada como cancelada

El endpoint tiene un nombre genérico (/invoices/update) que no revela el recurso afectado. El ID viaja en el body. El middleware de autenticación valida el token. La lógica del endpoint usa invoice_id directamente para hacer el UPDATE sin verificar a quién pertenece esa factura. BOLA, con efecto destructivo: no solo lectura, también modificación.

BOLA vs IDOR vs BFLA: diferencias claras

Estos tres términos se mezclan constantemente. Esta tabla resume cuándo usar cada uno.

La regla mnemotécnica: BOLA es horizontal (entre usuarios del mismo nivel), BFLA es vertical (escalada de privilegios), BOPLA es lateral (campos del mismo objeto que no deberías tocar). IDOR es el paraguas histórico que cubre los tres en contextos no-API.

Cómo detectar BOLA en tus APIs

La detección de BOLA tiene dos modalidades — manual y automatizada — y cada una cubre lo que la otra no puede.

Detección manual

Es lo que hace cualquier pentester en un primer pase, y deberías hacerlo tú mismo en cada feature nueva que toque recursos por ID. El procedimiento:

1. Crea dos cuentas con el menor nivel de privilegios posible (no uses cuentas admin para esto — los admins suelen tener acceso legítimo a todo y enmascaran el bug).
2. Captura una petición autenticada de la cuenta A que devuelva un recurso identificado por ID. Burp Suite, Postman o las DevTools del navegador sirven.
3. Consulta el ID equivalente de la cuenta B desde la propia interfaz (creando un recurso, mirando la URL del frontend, leyéndolo de un endpoint público).
4. Reenvía la petición de A reemplazando el ID por el de B. Si responde con 200 y datos, hay BOLA.
5. Repite con verbos no-GET (POST, PUT, PATCH, DELETE). Algunas APIs validan en lectura pero olvidan en escritura.

El testing manual encuentra el 100% de los BOLA si lo aplicas sistemáticamente, pero es lento — no escala a APIs con 200 endpoints y releases semanales.

Detección automatizada

Aquí es donde entra el DAST orientado a APIs. Un escáner automatizado que sepa lo que es BOLA hace, en esencia, lo mismo que el procedimiento manual, pero a escala:

• Parsea tu especificación OpenAPI / Swagger para conocer todos los endpoints y los parámetros que aceptan.
• Crea (o consume) sesiones de al menos dos roles distintos del mismo nivel.
• Ejecuta cada endpoint con el ID de un recurso que pertenece al rol A, autenticado con el token del rol B.
• Compara la respuesta con la línea base. Si devuelve datos en lugar de un 403/404, marca el endpoint como vulnerable y guarda la evidencia (request, response, contexto).

La diferencia entre un escáner DAST genérico y uno spec-aware es enorme para BOLA. Un escáner que no entiende tu OpenAPI se limita a fuzzing ciego de IDs y se pierde la mitad de los endpoints. Un escáner que parsea tu spec sabe exactamente qué probar y con qué token.

Limitaciones de la detección automática

La automatización cubre la mayoría de los BOLA, pero hay tres situaciones donde sigues necesitando un humano.

Lógica de negocio compleja. Si tu autorización depende de relaciones que no están en la URL (un usuario puede acceder a un proyecto si pertenece al equipo que pertenece al departamento que pertenece a la empresa…), un escáner automatizado solo puede probar la primera capa. Las cadenas de autorización profundas requieren modelar la lógica, y eso lo tiene que hacer un pentester.

Endpoints sin OpenAPI. Si tu API no tiene spec actualizada, el escáner no sabe qué endpoints existen ni qué parámetros aceptan. Algunas plataformas hacen descubrimiento por crawling, pero la cobertura nunca es del 100%. Mantener el OpenAPI actualizado es prerrequisito de cualquier estrategia seria de seguridad de APIs — y, de paso, evita el problema de Improper Inventory Management (API9) y las Shadow APIs.

BOLA en escritura con efectos secundarios. Probar PUT /api/invoices/update con un ID ajeno puede modificar datos reales. Los escáneres serios tienen modos de "lectura segura" que solo prueban GETs, pero la cobertura completa requiere un entorno de staging con datos sintéticos. Si solo escaneas en producción y solo en GET, te perderás los BOLA en POST/PUT/DELETE.

Estas tres limitaciones no invalidan la automatización — la siguen haciendo imprescindible para cobertura continua. Pero te dicen dónde necesitas todavía manos humanas: pentest manual periódico para lógica compleja, mantenimiento del OpenAPI como práctica de equipo, y un staging fiable para escaneos destructivos.

Cómo prevenir BOLA en tu código

Detectar es necesario. Prevenir es mejor. Tres patrones que deberían estar en tu codebase si tienes APIs en producción.

1. Autorización en la query, no en la lógica

El error que da pie a BOLA es separar "obtener el recurso" de "comprobar que el usuario puede verlo". La forma más robusta de evitarlo es hacer una sola query que ya incluya la condición de pertenencia:

// Mal: dos pasos, fácil de olvidar el segundo
const invoice = await db.invoices.findById(req.params.id);
if (invoice.companyId !== req.user.companyId) return res.status(403).end();
return res.json(invoice);

// Bien: un solo paso, imposible de olvidar
const invoice = await db.invoices.findOne({
  id: req.params.id,
  companyId: req.user.companyId,
});
if (!invoice) return res.status(404).end();
return res.json(invoice);

Bonus: devolver 404 en lugar de 403 evita filtrar la existencia del recurso a un atacante.

2. Middleware o decorador de autorización por endpoint

En APIs grandes, repetir la condición en cada handler es propenso al olvido. Centraliza la autorización en un middleware que se aplica explícitamente a cada ruta que toca un recurso identificado:

router.get(
  "/companies/:companyId/invoices",
  requireAuth,
  requireMembership({ resource: "company", paramName: "companyId" }),
  invoicesController.list
);

requireMembership consulta una tabla de pertenencia y devuelve 404 si el usuario no está vinculado. La política queda explícita en la definición de la ruta — un revisor de PR ve inmediatamente si falta.

3. Tests de autorización en CI

Por cada endpoint que toca un recurso identificado, escribe al menos un test que pruebe el caso "usuario A intenta acceder al recurso del usuario B" y espera un 404 o 403. Estos tests son rápidos, no requieren infraestructura adicional y atrapan BOLA antes de que llegue a producción.

test("usuario A no puede leer facturas de empresa B", async () => {
  const tokenA = await loginAs(userA);
  const res = await request(app)
    .get(`/api/companies/${companyB.id}/invoices`)
    .set("Authorization", `Bearer ${tokenA}`);
  expect(res.status).toBe(404);
});

Esto te da una red de seguridad permanente. Cada nuevo endpoint que añadas tendrá que tener su test de autorización; cualquier regresión la atrapa CI antes del deploy. Es disciplina, no magia, pero es lo que separa los equipos que tienen BOLA en producción de los que no.

Cómo te ayuda Vulnerabbit a detectar BOLA

La solución de seguridad de APIs de Vulnerabbit automatiza exactamente el procedimiento que hemos descrito en la sección de detección. Parsea tu OpenAPI o Swagger, configura sesiones con múltiples roles del mismo nivel, y ejecuta pruebas sistemáticas de acceso cruzado contra cada endpoint que acepta un identificador.

Cuando encuentra un BOLA, no te devuelve un finding genérico. Te da la petición exacta que lo demostró, la respuesta del servidor con los datos expuestos, y el endpoint vulnerable en formato OpenAPI para que tu equipo sepa dónde mirar en el código. La detección se integra en CI/CD: cada PR que introduce un endpoint nuevo se prueba contra el patrón BOLA antes de llegar a main. Y los resultados se priorizan por impacto real (qué tipo de datos se expusieron, qué tabla está detrás del endpoint) en lugar de severidad teórica.

Para cobertura más amplia del OWASP API Top 10, DAST de Vulnerabbit cubre BOLA junto con el resto de las categorías, y el escáner gratuito te da una primera aproximación sin instalar nada.

Conclusión

BOLA no es un problema de seguridad sofisticado. Es la ausencia de una comprobación que cualquier framework moderno te facilita implementar. La razón por la que aparece en prácticamente todas las APIs auditadas no es desconocimiento — es escala. Cuando tu API tiene cientos de endpoints, dependes de que cada desarrollador se acuerde de añadir la verificación de autorización en cada uno, y la estadística termina ganando.

La forma de salir de ese juego es estructural: autorización en la query en lugar de la lógica, middleware explícito en cada ruta que toca un recurso identificado, tests de autorización obligatorios en CI, y escaneo automatizado spec-aware como red de seguridad continua. Ninguna de esas cosas es opcional si tienes una API multi-tenant en producción.

La buena noticia es que BOLA es de los problemas más fáciles de prevenir una vez que el equipo lo tiene interiorizado. La mala noticia es que cuesta meses cambiar la cultura del equipo y, mientras tanto, los endpoints siguen creciendo. Empieza hoy: audita los 10 endpoints más sensibles que tienes (los que tocan datos de cliente, facturación, configuración de cuenta) y comprueba manualmente si protegen frente a BOLA. Si encuentras uno solo vulnerable, ya tienes justificación para meter la detección automática en tu pipeline.

¿Quieres saber si tus APIs tienen BOLA hoy?

La plataforma de seguridad de APIs de Vulnerabbit parsea tu OpenAPI, crea sesiones multi-rol y prueba acceso cruzado sistemático contra cada endpoint. Sin tarjeta para empezar.

Lanzar escaneo gratuito → · Ver /solutions/api-security →