BOLA, BOPLA y BFLA: las 3 fallas que dominan APIs en 2026

El OWASP API Top 10 empieza con BOLA, BFLA y BOPLA — tres clases de falla de autorización que dominan la lista desde 2019 y siguen dominando en 2026. No es casualidad. Son las 3 clases que más aparecen en programas internacionales de bug bounty, las que más tumban SaaS B2B en producción y las que ningún scanner detecta bien.

Este artículo explica cada una en profundidad, muestra cómo las ataca un investigador real y qué necesita hacer el equipo de producto para bloquearlas.

El contexto: API Top 10 versión 2023

En 2023 OWASP actualizó el API Top 10. Las 3 primeras posiciones son, en orden:

4 de las 5 primeras son fallas de autorización. La seguridad de APIs en 2026 es, antes que cualquier otra cosa, autorización correcta.

BOLA — Broken Object Level Authorization

Qué es

Conocida históricamente como IDOR (Insecure Direct Object Reference). Ocurre cuando un endpoint de API recibe un ID y devuelve el objeto correspondiente sin verificar si el usuario autenticado tiene permiso para acceder a ese objeto específico.

Ejemplo clásico

Endpoint: GET /api/orders/12345

La víctima accede legítimamente al pedido 12345. El atacante cambia el ID a 12346, 12347 y ve pedidos de otros usuarios. En un SaaS B2B eso es catastrófico — viola el contrato, viola la LGPD (la ley brasileña de protección de datos) y mata la renovación.

Variaciones modernas (que el scanner no detecta)

• UUID guessing — “el UUID es seguro”, dicen. No lo es. Los UUID se filtran a menudo en logs, en correos, en headers, en URLs compartidas. El atacante recolecta UUID por OSINT y prueba cada uno.
• Indirecto vía parámetro secundario — el endpoint GET /api/me/orders parece seguro porque usa “me”. Pero si el backend leeX-User-Id del header, el atacante cambia ese header y obtiene pedidos de otros.
• BOLA basado en búsqueda — el endpoint de búsqueda devuelve una lista. El filtro ?owner=<id> no tiene ACL. El atacante busca por owner=otro-tenant y lo ve todo.
• BOLA en acciones destructivas — DELETE /api/users/123 sin comprobar si el user 123 pertenece al tenant de quien lo solicita. El atacante borra usuarios de otros tenants.

Por qué el scanner no lo detecta

El scanner no tiene contexto de quién debería tener acceso a qué. Ve el endpoint respondiendo 200, devolviendo JSON, y lo marca como OK. Detectar BOLA exige crear dos usuarios en contextos distintos e intentar cruzarlos — trabajo manual.

Cómo bloquearlo

• Cada endpoint debe verificar la autorización a nivel de objeto, no solo la autenticación
• Patrón: extraer el tenant_id de la sesión JWT y compararlo con el tenant_id del objeto solicitado
• Centralizar la lógica de autorización en un middleware o policy engine (Casbin, OPA, Cedar)
• Pruebas automatizadas: para cada endpoint, crear 2 usuarios e intentar el acceso cruzado

BFLA — Broken Function Level Authorization

Qué es

Ocurre cuando un usuario sin el rol adecuado logra ejecutar una función que debería estar restringida a otros roles. Suele afectar a los endpoints administrativos.

Ejemplo clásico

El endpoint DELETE /api/admin/users/123 debería ser accesible solo para admins. Pero el frontend solo esconde el botón para los usuarios comunes — el backend no valida el rol. Un usuario común llama al endpoint vía curl y borra usuarios.

Variaciones modernas

• HTTP method confusion — el endpoint POST /api/users/{id}es válido para editar lo propio, pero PUT o PATCH en el mismo path se acepta sin validación adicional, y PATCH permite más campos
• Headers de override — X-HTTP-Method-Override: DELETE en un POST engaña a un middleware mal configurado
• Endpoints “paralelos” — /api/v2/users/{id}tiene ACL nueva, /api/v1/users/{id} todavía existe y no la tiene
• Endpoints administrativos sin prefijo — /api/users/promote sin el prefijo “admin” pasa desapercibido en la revisión de código

Cómo bloquearlo

• Default deny: ningún endpoint es público hasta que se autorice explícitamente
• RBAC o ABAC implementado en un middleware, no en cada handler individual
• Logs estructurados de toda autorización denegada (para la detección)
• Pruebas de matriz: para cada endpoint × cada rol, validar el comportamiento esperado

BOPLA — Broken Object Property Level Authorization

Qué es

BOPLA es la evolución de mass assignment + excessive data exposure. Se presenta en dos variantes:

1. Excessive data exposure: el endpoint devuelve más propiedades del objeto de las que el usuario debería ver. El frontend filtra en la vista, pero la API lo devuelve todo.
2. Mass assignment: el endpoint acepta más propiedades para escritura de las que el usuario debería poder modificar.

Ejemplo clásico — excessive data exposure

GET /api/users/123 devuelve { name, email, role, salary, ssn }. El frontend solo muestra name y email. Pero cualquier usuario con las DevTools del navegador ve el objeto completo.

Ejemplo clásico — mass assignment

PATCH /api/users/me acepta el cuerpo JSON y hace spread en user.update(req.body). El usuario envía { "role": "admin", "tenant_id": "otro" }. El backend lo guarda. Escalada inmediata.

Variaciones modernas

• Nested mass assignment — PATCH /api/posts/123 acepta author.role; el ORM actualiza no solo el post sino también al autor
• GraphQL field spreading — la query devuelve más campos de los que el resolver imagina; el frontend probó solo los campos pedidos, pero el atacante los pide todos
• Update vía include — las APIs estilo JSON:API permiten “include” de relaciones; los updates pueden propagarse en cascada
• Whitelist drift — se armó la lista permitida en enero, en febrero se agregaron campos nuevos al modelo y nadie actualizó la whitelist

Cómo bloquearlo

• Definir DTOs (Data Transfer Objects) explícitos para input y output, separados del modelo de dominio
• Whitelist de propiedades actualizables (allow-list, nunca block-list)
• En GraphQL: usar @auth directives en el schema, permisos por campo
• Para el output, proyección explícita (SELECT específico, no SELECT *)
• Code review obligatorio cuando cambia el modelo de dominio

El ataque combinado: chain BOLA + BOPLA

El exploit más devastador combina BOLA y BOPLA:

1. BOLA permite al atacante listar IDs de otros tenants (ej.: GET /api/users?search=*)
2. BOPLA permite al atacante editar un campo sensible de otro tenant (ej.: PATCH /api/users/<user_de_otro_tenant> con el email cambiado por el del atacante)
3. El atacante usa “olvidé mi contraseña” — recibe el enlace de reset en su correo
4. Account takeover total, en cualquier cuenta de la plataforma

Este patrón apareció en hallazgos públicos de bug bounty en 2023–2024 valiendo entre US$ 5.000 y US$ 25.000 por hallazgo. En un SaaS B2B brasileño, es el tipo de bug que termina el contrato con un cliente enterprise de un día para otro.

Cómo ataca un pentest serio

Una cobertura adecuada exige:

• Auth Matrix — mapeo sistemático de endpoints × roles × verbos. Una herramienta propia (No Vuln) lo automatiza para 200+ endpoints
• 2 cuentas en tenants distintos — requisito básico. Sin eso, no se puede probar el cross-tenant
• Diff de respuestas — entre roles distintos, ver qué campos solo aparecen para el admin
• Mass Assign Tester — fuzzing de propiedades en PATCH/PUT
• IDOR Wildcard Probe — rotación de IDs con distintos formatos (numérico, UUID, slug, base62)
• Revisión manual final, porque toda automatización tiene falsos negativos

Conclusión

BOLA, BFLA y BOPLA no son bugs raros. Son los 3 bugs más comunes en APIs de producción en 2026. Y son invisibles para los scanners. Si el pentest de tu API no menciona explícitamente la cobertura de estas 3 clases, con una matriz de prueba de roles × endpoints, está incompleto — sin importar el precio.

La cobertura correcta es trabajo manual calificado. Es exactamente el tipo de prueba que diferencia un “pentest con PDF bonito” de un “pentest que de verdad te protege”.