BOLA: la vulnerabilidad de API que pasa desapercibida

Imagina que inicias sesión en la aplicación de banca en línea y ves el saldo de tu cuenta, el historial de transacciones y tus datos personales. Todo funciona exactamente como esperas. Ahora imagina que cambias un solo número en la URL (el ID de cuenta) y, de repente, ves los datos financieros de otra persona. No necesitas herramientas de hacking. Tampoco una cadena de exploits sofisticada. Solo un dígito.

No es un escenario hipotético. Este es exactamente el tipo de vulnerabilidad que permitió que T-Mobile expusiera los datos de 37 millones de clientes en una filtración divulgada en 2023, lo que finalmente derivó en un acuerdo de demanda colectiva por 350 millones de dólares.

Es la misma clase de falla que permitió a los atacantes acceder a los datos personales y las estadísticas de entrenamiento de cualquier usuario de Peloton con solo intercambiar los ID de usuario en las solicitudes de API. También es el mismo patrón de vulnerabilidad que, en Harbor (un registro de contenedores ampliamente utilizado), permitió que un usuario con un rol básico de mantenimiento cambiara todo un proyecto privado a público e implementara imágenes no verificadas al manipular los metadatos del proyecto mediante una llamada de API no autorizada.

La vulnerabilidad que está en el centro de todos estos incidentes tiene un nombre: autorización rota a nivel de objeto (BOLA). Ocupa el puesto n.º 1 en OWASP API Security Top 10 y podría decirse que es la falla más frecuente, peligrosa y subestimada en la seguridad de API moderna.

¿Qué es BOLA?

La autorización rota a nivel de objeto es una falla de autorización por la que una API o aplicación web no verifica si el usuario que realiza una solicitud tiene permiso legítimo para acceder al objeto de datos específico que intenta consultar o modificar. Cuando un usuario solicita un recurso, como un registro de base de datos, un archivo o una transacción, la aplicación debe comprobar no solo que el usuario esté autenticado (que sea quien dice ser), sino también que tenga autorización para interactuar con ese objeto en particular (que tenga derecho a verlo o cambiarlo).

Cuando falta esa comprobación de autorización, es débil o se aplica de forma inconsistente, un atacante puede acceder a los datos de otros usuarios con solo manipular el identificador del objeto en la solicitud. Cambia un número de cuenta en un parámetro de URL. Intercambia un ID de usuario en un encabezado de API. Modifica el ID de un recurso en una carga JSON. Si el servidor no valida la propiedad del objeto en cada solicitud, entrega datos que no debería.

Vale la pena distinguir esto de la autenticación. La autenticación responde a la pregunta «¿quién eres?» y verifica la identidad mediante credenciales, tokens o mecanismos multifactor. La autorización responde a la pregunta «¿qué tienes permitido hacer?» y determina qué recursos y acciones específicos están permitidos para esa identidad. BOLA aprovecha una falla en la segunda comprobación. El usuario está autenticado, inició sesión y verificó su identidad. Simplemente accede a objetos que no le pertenecen y la aplicación no hace nada para impedirlo.

BOLA e IDOR: la misma falla desde perspectivas distintas

Si llevas tiempo trabajando en seguridad de aplicaciones, reconocerás que lo que OWASP llama BOLA suena sorprendentemente parecido a otra vulnerabilidad bien conocida: referencias directas a objetos inseguras (IDOR). Este es un verdadero punto de debate en la comunidad de ciberseguridad, y la superposición de nombres genera una confusión que vale la pena abordar directamente.

IDOR tiene sus raíces en OWASP Web Application Security Top 10, donde apareció ya en 2007. El término describe un patrón de ataque específico: una aplicación expone una referencia directa a un objeto interno, como una clave de base de datos, un nombre de archivo o un ID secuencial, y un atacante manipula esa referencia para acceder a algo que no debería. IDOR se centraba principalmente en el mecanismo del exploit: el identificador predecible, fácil de adivinar o enumerar que manipula el atacante.

BOLA, introducida en OWASP API Security Top 10 en 2019, describe la misma falla fundamental, pero desde una perspectiva más amplia. Mientras IDOR se enfocaba en la referencia manipulable, BOLA replantea el problema como lo que realmente es: una comprobación de autorización rota a nivel de objeto.

El énfasis pasa del vector de ataque («la referencia es insegura») a la causa raíz («la autorización está rota»). BOLA también reconoce explícitamente que estas fallas van más allá de la simple manipulación de URL: pueden manifestarse en cuerpos de solicitudes de API, encabezados, grafos de objetos anidados y límites entre microservicios, donde la lógica de autorización puede implementarse de forma inconsistente.

En la práctica, ambos términos describen la misma familia de vulnerabilidades. Ya sea que la llames IDOR o BOLA, el problema central es idéntico: una aplicación confía en los identificadores proporcionados por el usuario sin realizar las comprobaciones de autorización adecuadas en el servidor para el objeto específico solicitado. Las defensas son las mismas. El impacto en el negocio también.

Sin embargo, la diferencia en la nomenclatura importa por dos razones:

• Primero, BOLA es un marco más útil para las arquitecturas modernas basadas en API porque centra la conversación en la lógica de autorización, en lugar de en un patrón técnico específico. En un mundo de microservicios, arquitecturas componibles y ecosistemas de API cada vez más complejos, es más productivo pensar en la autorización de forma integral —en cada endpoint y para cada objeto— que preguntarse si un parámetro de URL es fácil de adivinar.

• Segundo, como BOLA ocupa el puesto n.º 1 en OWASP API Security Top 10 e IDOR forma parte de la categoría más amplia «Broken Access Control» de OWASP Web Application Top 10, usar ambos términos con precisión demuestra que entiendes todo el alcance del problema, tanto en contextos web como de API.

En el resto de este artículo, usaremos BOLA como término principal, pero cuando veas BOLA, recuerda que IDOR también forma parte de esta historia.

Por qué BOLA es especialmente peligrosa

BOLA ocupa una posición particularmente peligrosa en el panorama de vulnerabilidades porque combina tres características que rara vez aparecen juntas: es fácil de explotar, difícil de detectar y devastadora por su impacto.

Fácil de explotar.

Los ataques BOLA no requieren herramientas sofisticadas, conocimientos técnicos avanzados ni cadenas de exploits complejas. Un atacante puede buscar estas vulnerabilidades con nada más que un navegador, una herramienta proxy o un script sencillo. Cambia un parámetro y observa la respuesta. Si aparecen datos que no deberían estar ahí, la aplicación es vulnerable. La barrera de entrada es prácticamente nula, lo que significa que una variedad mucho más amplia de actores de amenazas puede explotar estas fallas en comparación con la mayoría de las otras clases de vulnerabilidades.

Difícil de probar. 

Los métodos tradicionales de pruebas de seguridad tienen dificultades con BOLA porque no son fallas técnicas en el sentido convencional; son errores de lógica. Una inyección SQL deja un patrón detectable en una consulta. Una vulnerabilidad de cross-site scripting (XSS) genera cargas reconocibles. En cambio, BOLA implica una solicitud de API perfectamente bien formada y sintácticamente correcta que simplemente devuelve datos de otro usuario. No hay entradas malformadas, cargas sospechosas ni patrones anómalos. La solicitud parece legítima. La respuesta parece legítima. Lo único incorrecto es que la persona que hizo la solicitud no debería haber recibido esa respuesta en particular.

Puede evadir las defensas modernas. 

Las organizaciones con una postura de seguridad madura —firewalls de aplicaciones web, gateways de API, limitación de velocidad y controles de autenticación— todavía pueden ser vulnerables a BOLA. Estas defensas están diseñadas para detectar accesos no autorizados, solicitudes malformadas y patrones de ataque conocidos. BOLA opera completamente dentro de los límites del tráfico normal y autenticado. El usuario tiene credenciales válidas. El formato de la solicitud es correcto. El gateway de API ve a un usuario autenticado que realiza una solicitud aparentemente legítima. Nada activa una alerta.

Las consecuencias para el negocio son proporcionales a la gravedad: filtraciones de datos que exponen millones de registros, sanciones regulatorias, demandas colectivas y daños a la reputación que tardan años en repararse. Cuando el ataque es tan sencillo como cambiar un número en una URL, la pregunta no es si los atacantes lo intentarán, sino si tus aplicaciones los detendrán cuando lo hagan.

¿Cuál es la causa de BOLA?

Las vulnerabilidades BOLA rara vez son el resultado de un único error de ingeniería. Suelen surgir de una serie de suposiciones profundamente equivocadas sobre cómo se diseñan, desarrollan y mantienen las API.

Los desarrolladores suelen confiar demasiado en las comprobaciones del lado del cliente y asumir que los usuarios no manipularán los ID de objeto ni los tokens. Esta suposición es fundamentalmente errónea, y los ejemplos de filtraciones anteriores lo demuestran una y otra vez. Además, la lógica de autorización suele implementarse de forma inconsistente entre endpoints. Cuando no existe un marco de autorización centralizado —y cada endpoint implementa sus propias comprobaciones de control de acceso (o se olvida de hacerlo)—, las brechas son inevitables. Una aplicación puede aplicar correctamente la autorización en 99 de cada 100 endpoints. El endpoint que se pasó por alto se convierte en el punto de entrada.

Las prácticas de prueba agravan el problema. Las pruebas de seguridad manuales y la automatización con poca cobertura rara vez detectan BOLA porque estas vulnerabilidades no se basan en patrones. No puedes encontrarlas buscando firmas conocidas. Detectar BOLA eficazmente requiere comprender la lógica del negocio, la propiedad de los datos y el contexto de cada solicitud; históricamente, estas capacidades han estado fuera del alcance de las herramientas automatizadas.

Y luego está la realidad del desarrollo de software moderno: la velocidad manda. Los equipos de desarrollo están bajo presión constante para publicar API rápidamente y responder a las necesidades del negocio, por lo que con frecuencia se deja de lado la validación de autorización para priorizar la entrega de funcionalidades. La vulnerabilidad BOLA que resulta de esta decisión puede pasar inadvertida durante meses o años, hasta que la encuentra un atacante.

El desafío de la detección

Identificar BOLA a escala es uno de los problemas más difíciles de la seguridad de aplicaciones, y vale la pena entender por qué.

El desafío central es que detectar BOLA eficazmente requiere comprender el contexto. El escáner debe saber no solo que una API devuelve datos, sino también si ese usuario específico que hace la solicitud debería tener acceso a ellos. ¿Este recurso es público o privado? ¿El usuario que realiza la solicitud es el propietario de este objeto? ¿Un usuario con este rol debería poder ver este campo? Son preguntas que dependen por completo de la lógica de negocio y las reglas de autorización de la aplicación, y no se pueden responder mediante la coincidencia de patrones o la detección basada en firmas.

Los métodos sencillos para detectar BOLA, como comprobar si cambiar un ID devuelve datos diferentes, generan una cantidad inaceptable de falsos positivos. Muchas API ofrecen intencionalmente recursos públicos a los que puede acceder cualquier usuario autenticado. Un catálogo de productos, un perfil público o un documento compartido deben estar disponibles para distintos usuarios. Marcar cada caso en que dos usuarios pueden acceder al mismo recurso como un posible problema de BOLA genera tanto ruido que oculta los hallazgos reales. Los equipos de AppSec, que ya tienen recursos limitados, no pueden darse el lujo de investigar cientos de falsos positivos para encontrar unas pocas fallas de autorización reales.

Por eso algunos competidores que aseguran ofrecer detección de BOLA entregan resultados superficiales. Sin la capacidad de comprender el contexto de lo que se está consultando y si debería estar restringido, los mecanismos de detección siguen siendo ingenuos y la relación entre señal y ruido sigue siendo deficiente.

Por qué esto importa más que nunca

La urgencia de detectar BOLA no es teórica. Varias fuerzas convergentes están haciendo que esta clase de vulnerabilidad sea más frecuente y peligrosa que nunca.

1. La superficie de ataque de las API está en expansión. 

Las aplicaciones modernas ya no son bases de código monolíticas: están compuestas por microservicios que se comunican a través de API, y las arquitecturas componibles están reemplazando a los antiguos monolitos de código. Cada microservicio nuevo, cada endpoint de API nuevo y cada integración nueva representan un posible punto de exposición a BOLA. El volumen de endpoints de API en un entorno empresarial típico ha crecido varios órdenes de magnitud, y la lógica de autorización debe implementarse correctamente en todos ellos.

2. El código generado por IA está acelerando el problema. 

El 76 % de los desarrolladores ya usa o planea usar herramientas de programación con IA (Stack Overflow, 2024), y un estudio de cinco modelos importantes de IA encontró que al menos el 48 % de sus fragmentos de código generados contenía vulnerabilidades. Cuando el código se genera a velocidad de máquina, la superficie de riesgo de errores de autorización se multiplica en consecuencia. Los desarrolladores que trabajan con asistentes de programación con IA publican más código y con mayor rapidez, pero la lógica de autorización de ese código depende de la calidad de las instrucciones y los procesos de revisión. En muchos casos, el código generado funciona correctamente, pero omite las verificaciones de autorización que habría implementado un desarrollador consciente de la seguridad.

3. Los agentes de IA están creando nuevos vectores de exposición. 

El auge de los agentes autónomos de IA que interactúan con datos y servicios internos a través de API agrega otra dimensión al problema. Estos agentes se comunican mediante los mismos endpoints de API que atienden a los usuarios, pero operan a velocidad de máquina y pueden encadenar varias llamadas a API de formas que no corresponden a los patrones de uso humano. Si esos endpoints de API tienen vulnerabilidades BOLA, un agente puede convertirse en un arma, o un atacante puede explotar los mismos endpoints que usa el agente, para exfiltrar datos o modificar recursos a gran escala.

Un agente que usa una API vulnerable a BOLA no es simplemente una vulnerabilidad: es una máquina automática de exfiltración de datos.

Cuatro de las cinco primeras entradas de OWASP API Security Top 10 son problemas de autorización y autenticación. BOLA no es un problema aislado; es el síntoma más visible de un desafío sistémico en la forma en que las aplicaciones modernas gestionan el control de acceso. Resolver la detección de BOLA abre la puerta a abordar la familia más amplia de fallas de autorización, responsables de la mayoría de los riesgos críticos de seguridad de las API.

Un nuevo enfoque: detección de BOLA con IA

El desafío de detección que ha hecho que BOLA persista se debe, fundamentalmente, a la necesidad de comprender el contexto. Y es precisamente aquí donde los avances recientes en IA y modelos de lenguaje grandes (LLM) están cambiando las reglas del juego.

El enfoque que Snyk API & Web ha impulsado utiliza LLM para analizar el contexto de las solicitudes a las API y la lógica de autorización. Así, va más allá de las técnicas DAST tradicionales para clasificar la propiedad del contenido y determinar si el usuario que realiza la solicitud debería poder acceder a una respuesta. En lugar de depender de heurísticas simples que intercambian identificadores y generan falsos positivos, el motor de detección con IA puede razonar si los datos son públicos o privados, si el usuario que realiza la solicitud es su propietario legítimo y si realmente se ha vulnerado el límite de autorización.

Esto no se trata de reemplazar los fundamentos de las pruebas dinámicas de seguridad de aplicaciones. DAST sigue siendo esencial: prueba las aplicaciones desde el exterior, sondea la superficie de ataque con cargas útiles a gran escala, tal como lo haría un atacante. La IA aporta la capacidad de superponer inteligencia contextual a esa metodología de pruebas, lo que permite detectar vulnerabilidades invisibles para los enfoques basados en la coincidencia de patrones. El resultado es una detección de BOLA con tasas de falsos positivos mucho más bajas, por lo que los equipos de AppSec reciben hallazgos útiles sobre los que pueden actuar de inmediato, en vez de ruido que deben filtrar.

Y BOLA es solo el comienzo. Este mismo enfoque basado en IA se está ampliando para abordar otras fallas de autorización y autenticación de OWASP API Security Top 10, porque el desafío técnico de comprender el contexto de la lógica de negocio se aplica a toda la familia de vulnerabilidades de control de acceso. Resolver la detección de BOLA sienta las bases para un enfoque de pruebas de seguridad de API mucho más inteligente.

Qué deberían preguntar los líderes de seguridad

Si eres responsable del programa de seguridad de aplicaciones de tu organización, BOLA debería estar entre las principales prioridades de tu evaluación de riesgos. Considera estas preguntas:

¿Tienes visibilidad sobre cómo se implementa la autorización en tus endpoints de API y esa implementación es coherente? La falta de coherencia es terreno fértil para BOLA. Un marco de autorización centralizado, aplicado en todos los servicios, es la defensa arquitectónica más eficaz.

¿Tus herramientas de pruebas actuales realmente pueden detectar BOLA, o afirman hacerlo, pero generan sobre todo falsos positivos? No todos los métodos de detección de BOLA son iguales. Pide pruebas de su precisión: tasas de falsos positivos, metodología de detección y resultados en situaciones reales.

¿Cómo tienes en cuenta las implicaciones de autorización del código generado por IA? Si tus desarrolladores usan asistentes de programación con IA, el código que publican puede ser funcionalmente correcto, pero tener una autorización incompleta. Tu metodología de pruebas debe detectar lo que podría pasar por alto una revisión de código.

Y, por último: ¿haces pruebas desde el exterior? Las fallas de autorización como BOLA solo se hacen plenamente visibles cuando pruebas la aplicación como lo haría un atacante: sondeando las API y aplicaciones web en ejecución con solicitudes y cargas útiles reales, y con la perspectiva de alguien que intenta acceder a lo que no debería. El análisis estático puede identificar posibles problemas en el código. Las pruebas dinámicas demuestran si realmente se pueden explotar.

BOLA ocupa el primer lugar de OWASP API Security Top 10 por una razón. Es generalizada, difícil de detectar y, cuando se explota, sus consecuencias se miden en millones de dólares y millones de registros comprometidos. La buena noticia es que el problema de detección ya tiene solución: los enfoques basados en IA permiten encontrar estas fallas con la precisión y la comprensión contextual que las herramientas tradicionales nunca pudieron ofrecer. La pregunta es si tu organización las encontrará antes que un atacante.