Tema 9
Pocas fallas son tan frecuentes y tan dañinas en APIs como la autorización rota a nivel de objeto y de función. BOLA y BFLA no requieren técnicas sofisticadas: suelen aparecer cuando la API autentica bien, pero decide mal quién puede acceder a qué recurso o ejecutar qué operación. Por eso son dos de los riesgos más graves y persistentes en APIs REST.
Cuando una API sufre una brecha grave, con frecuencia el problema no está en criptografía, ni en una librería, ni en una inyección exótica. Está en que un actor autenticado pudo hacer algo que nunca debió permitírsele. Ese es el terreno de las autorizaciones rotas.
Dentro de ese terreno, BOLA y BFLA ocupan un lugar central:
Ambas pueden coexistir en la misma API y ambas suelen pasar desapercibidas porque, desde el punto de vista técnico, la solicitud puede parecer perfectamente válida.
Broken Object Level Authorization ocurre cuando la API no verifica correctamente si la identidad autenticada tiene permiso para acceder a un objeto específico. En otras palabras, el endpoint existe, el usuario está autenticado, pero el recurso consultado, modificado o eliminado no le pertenece o no debería estar a su alcance.
Ejemplos típicos:
Broken Function Level Authorization ocurre cuando la API permite a un actor ejecutar una función que no corresponde a su rol, contexto o nivel de privilegio. Aquí el problema no es tanto el objeto, sino la capacidad expuesta por la ruta o acción.
Ejemplos comunes:
En BFLA, la API permite llegar a una función que debería estar bloqueada para ese actor, aunque el endpoint y la autenticación sean válidos en sentido técnico.
Ambas son fallas de autorización, pero atacan niveles distintos de decisión.
| Tipo | Pregunta que falla | Ejemplo típico |
|---|---|---|
| BOLA | ¿Puede este actor acceder a este objeto concreto? | Leer el pedido de otro usuario cambiando el ID |
| BFLA | ¿Puede este actor ejecutar esta función o acción? | Acceder a un endpoint administrativo sin privilegio suficiente |
En la práctica, una misma operación puede involucrar ambas capas. Por ejemplo, un endpoint administrativo que además opera sobre objetos de otros usuarios puede sufrir BFLA y BOLA al mismo tiempo.
Las APIs suelen exponer recursos identificados por IDs, UUIDs, claves de negocio o relaciones navegables. Eso hace natural que el cliente indique sobre qué objeto quiere operar. Si el backend no recalcula y valida el ownership real, aparece la brecha.
BOLA es frecuente porque muchas implementaciones hacen algo parecido a esto:
Lo que falta en el medio es la pregunta decisiva: “¿este actor tiene permiso sobre este objeto?”
BFLA suele aparecer cuando la API crece rápido, incorpora roles nuevos, mantiene endpoints heredados o confía demasiado en que el frontend ocultará funciones sensibles. También aparece cuando se reutilizan controladores o rutas sin revisar si todos los consumidores deberían tener acceso.
Ejemplos de causas típicas:
Un error común es pensar que usar UUIDs o identificadores largos elimina el riesgo de BOLA. Eso puede dificultar la enumeración simple, pero no corrige el problema real. Si un atacante obtiene o deduce un ID válido por cualquier medio, la API sigue necesitando verificar si ese recurso le corresponde.
El control correcto no es ocultar identificadores. Es autorizar correctamente el objeto cada vez que se lo usa.
La explotación de BOLA suele ser simple y altamente efectiva. Un atacante autenticado modifica un identificador en la URL, el body o un parámetro y observa si obtiene datos distintos, puede editar registros ajenos o descargar recursos que no le pertenecen.
Señales típicas de explotación:
La explotación de BFLA suele comenzar con reconocimiento: documentación, tráfico capturado, endpoints ocultos en frontend, convenciones de nombres o versiones antiguas. El atacante prueba funciones que sospecha sensibles y observa si el backend las bloquea realmente o no.
Indicadores típicos:
El impacto de BOLA suele ser inmediato sobre confidencialidad e integridad. Permite acceso horizontal entre usuarios, cuentas o tenants, y a veces incluso modificación o eliminación de datos ajenos.
Consecuencias comunes:
BFLA puede afectar tanto integridad como operación general del sistema. El actor obtiene acceso a funciones que no forman parte de su perfil y puede alterar datos críticos, ejecutar acciones administrativas o activar procesos internos.
Consecuencias frecuentes:
Aunque BOLA y BFLA se manifiestan de manera distinta, sus causas raíz suelen repetirse:
Prevenir BOLA exige validar acceso al objeto real en backend, en cada operación relevante. No basta con proteger el endpoint general.
Buenas prácticas clave:
Prevenir BFLA requiere asegurar que cada función sensible tenga una política explícita de acceso y que esa política se aplique en backend, sin depender de la interfaz.
Recomendaciones:
En incidentes reales es frecuente que varias fallas convivan. Por ejemplo:
Ese caso combina BFLA con BOLA. Por eso es importante no analizar hallazgos en aislamiento. La API puede tener una cadena de decisiones de acceso defectuosa en más de un punto.
Las pruebas deben ser deliberadas y sistemáticas. No alcanza con verificar que un usuario legítimo acceda a sus propios datos. Hay que comprobar que no acceda a los ajenos y que no alcance funciones fuera de su perfil.
Casos mínimos de prueba:
Si la observabilidad está bien planteada, BOLA y BFLA pueden dejar señales detectables:
La detección no reemplaza la prevención, pero ayuda a reducir tiempo de exposición y a entender patrones de abuso.
BOLA y BFLA representan dos de las fallas más críticas en APIs REST porque atacan el corazón de la seguridad de acceso: la decisión sobre qué puede hacer cada identidad autenticada. Son peligrosas precisamente porque no requieren romper la autenticación; basta con encontrar un camino mal autorizado. Diseñar, probar y monitorear estas decisiones con rigor es esencial para cualquier API expuesta.
En el próximo tema estudiaremos validación de entradas, sanitización y manejo seguro de parámetros, otro pilar central para evitar que la API procese datos maliciosos o ambiguos.