APIs inseguras: qué son BOLA e IDOR y cómo se explotan

Cuando una aplicación mueve su lógica a una API, los datos dejan de estar escondidos detrás de pantallas y pasan a viajar como peticiones directas y predecibles: pide el pedido 1234, el usuario 56, la factura 890. Esa claridad es lo que hace a las APIs potentes, y también lo que las vuelve el blanco favorito de una falla tan simple como devastadora. Se llama BOLA, por Broken Object Level Authorization, aunque muchos la conocen por su nombre clásico, IDOR. Es el primer riesgo del OWASP API Security Top 10, y por buenas razones: es común, fácil de explotar y suele exponer datos a gran escala.

La idea es incómodamente sencilla. Pides un recurso identificándolo por su número —/api/pedidos/1234—, cambias ese número por otro —/api/pedidos/1235— y el servidor te entrega el pedido de otra persona sin preguntarse si ese pedido es tuyo. No hubo que romper nada: el sistema confió en el identificador que le mandó el cliente y nunca verificó quién estaba pidiendo qué.

Por qué es tan común

La raíz del problema es una confusión entre dos cosas que suenan parecidas pero no lo son: autenticación y autorización. La autenticación responde "¿quién eres?" y casi todas las aplicaciones la implementan bien: pides iniciar sesión y recibes un token. La autorización responde "¿tienes permiso para acceder a este objeto en particular?", y es la que se olvida. El servidor confirma que estás logueado, pero no comprueba que el pedido 1235 efectivamente te pertenezca antes de entregártelo.

A eso se suma la costumbre de usar identificadores secuenciales y predecibles. Si tu pedido es el 1234, adivinar que existen el 1233 y el 1235 no requiere talento. Y el frontend suele reforzar la ilusión de seguridad: la interfaz solo te muestra tus pedidos, así que es fácil asumir que el backend hace lo mismo. Pero el atacante no usa tu interfaz; habla directamente con la API, donde esa supuesta protección nunca existió. Cuando además la aplicación crece hacia decenas de endpoints y microservicios, cada uno que recibe un identificador de objeto es una oportunidad nueva para que el control de autorización falte en algún lado.

Cómo se ve un ataque real

Un atacante que encuentra un endpoint vulnerable rara vez se conforma con ver un pedido ajeno. Lo que hace es automatizar: recorre los identificadores de forma masiva —del 1 al 999999— y descarga todo lo que el servidor le entregue. Así, una sola falla de autorización se convierte en una fuga completa de la base de datos: nombres, correos, direcciones, historiales de compra, documentos. No hay un "exploit" espectacular detrás, solo un bucle que pide números y guarda respuestas.

El daño va más allá de lo técnico. Una fuga de datos personales golpea la confianza de los clientes, puede activar obligaciones regulatorias y expone a la empresa justo donde más duele. Y lo más frustrante es que el costo de prevenirlo era mínimo comparado con el de limpiarlo después.

Cómo se prueba

Detectar BOLA no es trabajo de un escáner, porque una herramienta automática no sabe qué objeto pertenece a quién: para ella, una respuesta exitosa es una respuesta exitosa, sea legítima o no. La prueba es manual y metódica, y su forma mínima es clara:

1. Crear al menos dos cuentas distintas, por ejemplo un usuario A y un usuario B.
2. Autenticarse como A y capturar las peticiones que la aplicación hace a la API.
3. Repetir esas peticiones cambiando el identificador por uno que pertenece a B, o reenviándolas con el token de B.
4. Observar la respuesta: si el servidor entrega el objeto que no corresponde, hay BOLA.

Ese patrón se repite endpoint por endpoint, sobre cada petición que reciba un identificador de objeto. Conviene además revisar las variantes: a veces el acceso de lectura está protegido pero el de modificación o borrado no, o un rol de menor privilegio puede ejecutar acciones reservadas a otro, una falla hermana conocida como autorización a nivel de función. Este tipo de evaluación es parte central de un trabajo serio de seguridad web y de pentesting, donde el análisis manual es justamente lo que un escáner no puede reemplazar.

Cómo se previene

La defensa de fondo es una sola regla aplicada sin excepciones: el servidor debe verificar, en cada acceso a un objeto, que el usuario autenticado tiene permiso sobre ese objeto específico. No alcanza con confirmar que está logueado; hay que comparar la propiedad del recurso contra la sesión que lo pide, siempre del lado del servidor y nunca confiando en lo que diga el cliente. Centralizar esa comprobación en una capa común, en vez de reimplementarla en cada endpoint, reduce la probabilidad de que un desarrollador la olvide en alguno.

Usar identificadores no predecibles, como UUID en lugar de números correlativos, ayuda como defensa en profundidad porque dificulta la enumeración masiva, pero no reemplaza la verificación de autorización: si esta falta, un atacante que consiga el identificador igual accede. Construir estas comprobaciones desde el diseño, y no parchearlas después, es exactamente el tipo de criterio que aporta el desarrollo seguro.

BOLA no es una vulnerabilidad glamorosa ni difícil de entender, y esa es justamente la razón por la que sigue apareciendo año tras año en las APIs de empresas que hacen todo lo demás bien. Probar tus endpoints con dos cuentas y un poco de paciencia, antes de que lo haga alguien sin autorización, es una de las inversiones de seguridad con mejor retorno que existen.