Volver al glosario

Broken object level authorisation (BOLA)

2 min de lectura

En seguridad de APIs, la broken object level authorisation (BOLA) es el fallo de no comprobar que quien llama tiene derecho sobre el objeto concreto que nombra su petición. Es la primera entrada del OWASP API Security Top 10 y, en una prueba de API, el defecto que más veces deja a la vista los registros de otro tenant.

29 de julio de 2026
Compartir:

Cómo funciona

Un endpoint de API recibe el identificador de un objeto como segmento de la ruta, parámetro de consulta, campo del cuerpo o cabecera, lo resuelve, y devuelve o modifica el objeto. La autorización de nivel de objeto es la comprobación que va entre resolver y actuar: si la identidad que hay detrás de este token tiene con este objeto una relación que permita esta operación. Cuando esa comprobación falta, es parcial o se hace contra datos que ha suministrado el cliente, el endpoint está roto.

BOLA e IDOR describen el mismo defecto de fondo. IDOR es el nombre más antiguo y se usa en los informes de aplicación web; BOLA es el nombre que se usa para APIs y el que debe usar un informe de API, porque separa la comprobación de nivel de objeto de la comprobación de nivel de función, que es otro fallo con otro arreglo.

Qué sale mal

En las APIs esto es peor que en las aplicaciones web clásicas por un motivo estructural: el grafo de objetos queda expuesto directamente, un identificador cada vez, sin ninguna página renderizada en el servidor por medio que lo esconda. Cada recurso, subrecurso y relación es su propio endpoint, así que una sola comprobación que falte en una ruta anidada derrota a una comprobación correcta en la ruta padre.

El fallo que más vemos es delimitar el alcance por una afirmación del token sin volver a leer el objeto. El manejador se fía de un identificador de tenant sacado de la petición en vez de deducirlo de la sesión, así que el cliente sencillamente envía otro. Muy cerca va la aplicación incoherente entre verbos y entre representaciones: GET está protegido y PATCH no; la ruta JSON está protegida y la exportación masiva no; la ruta versionada está protegida y la versión anterior sigue desplegada y no lo está. El aislamiento entre tenants que aguanta en la interfaz de usuario y se cae en la API es la forma habitual del hallazgo.

Dónde aparece esto en una auditoría

Enumeramos los endpoints a partir de la especificación, después probamos cada uno con los identificadores de una segunda cuenta, y probamos todos los verbos que el endpoint acepta y no solo el que enseña la documentación. El informe indica el endpoint, el verbo, el identificador sustituido y los campos exactos que se devolvieron y pertenecían a otro tenant. Registramos también si la operación quedó en el log, porque una lectura entre tenants sin registro es un incidente mucho más difícil de reconstruir. Esto forma parte de cómo recorremos una API objeto a objeto.

¿Quieres ver cómo trabajamos en Asperis Security?

Agenda 30 minutos con uno de nuestros especialistas. Revisamos tu stack y te decimos qué conviene probar primero.