IDOR y BOLA: el fallo de autorización que puede exponer una API entera

En seguridad web solemos hablar mucho de contraseñas, doble factor y sesiones robadas. Todo eso importa, pero hay un fallo menos vistoso que puede ser igual de peligroso: permitir que un usuario acceda a recursos que no son suyos. Ahí entran IDOR y BOLA, dos términos muy usados en seguridad de APIs. No describen un ataque sofisticado, sino una aplicación que confía demasiado en el identificador que recibe. A veces basta con cambiar un número en una URL para ver una factura, modificar un pedido o descargar un documento ajeno.

Autenticarse no es lo mismo que estar autorizado

El primer error conceptual aparece cuando se confunde autenticación con autorización. Autenticarse es demostrar quién eres: usuario, contraseña, SSO, certificado, passkey o token. Autorizar es decidir qué puedes hacer una vez dentro.

Una API puede estar perfectamente protegida con login y, aun así, ser vulnerable si no comprueba los permisos sobre cada recurso. Imaginemos una aplicación de facturación que expone una ruta para descargar documentos. Si el backend solo valida que la sesión es válida, pero no verifica que esa factura pertenece al usuario conectado, el sistema está incompleto.

Este matiz es clave en arquitecturas donde front-end, apps móviles y servicios internos consumen APIs constantemente. En Tecnoic ya hemos hablado de arquitectura web moderna, pero aquí conviene bajar un nivel más: cada endpoint debe aplicar reglas de acceso propias.

Qué es IDOR y por qué sigue apareciendo

IDOR significa Insecure Direct Object Reference. Es una referencia directa e insegura a un objeto interno de la aplicación: una factura, un pedido, una conversación, una reserva o una imagen privada.

El patrón típico es sencillo. Una aplicación usa una URL como /facturas/12345. El usuario legítimo accede a su factura, pero prueba a cambiar 12345 por 12346 y obtiene otra. El problema no es que el identificador sea visible. El problema es que el servidor acepta el cambio sin comprobar propiedad, rol, organización o contexto.

La Web Security Academy de PortSwigger lo explica como un fallo de control de acceso cuando una aplicación usa entradas proporcionadas por el usuario para acceder directamente a objetos. Usar UUID en lugar de números secuenciales ayuda a que los IDs sean menos adivinables, pero no arregla el fondo: un identificador difícil no sustituye una comprobación de autorización.

BOLA: el problema aplicado a las APIs

BOLA significa Broken Object Level Authorization. Es el nombre que OWASP utiliza para describir fallos de autorización a nivel de objeto en APIs. OWASP lo sitúa como primer riesgo en el API Security Top 10 de 2023.

La diferencia entre IDOR y BOLA no siempre es nítida. IDOR es el caso clásico: manipular una referencia directa. BOLA es una categoría más amplia y orientada a APIs: cualquier endpoint que opere sobre un objeto debe comprobar si el usuario puede leerlo, modificarlo, borrarlo o ejecutar una acción sobre él.

Por ejemplo, no basta con proteger GET /pedidos/88. También hay que revisar PATCH /pedidos/88, DELETE /pedidos/88 o POST /pedidos/88/cancelar. Muchas brechas no están en la lectura, sino en acciones de cambio de estado. Ver datos ajenos es grave; modificar datos ajenos puede ser crítico.

Dónde se esconden estos fallos

Los fallos IDOR/BOLA suelen aparecer en zonas donde el diseño parece razonable, pero la autorización se queda corta. Un caso típico son las aplicaciones multiempresa: el usuario pertenece a una organización, pero la API solo comprueba el usuario y no el tenant. Resultado: acceso cruzado entre clientes.

También son frecuentes en paneles con roles intermedios. No todo es “usuario” o “administrador”. Puede haber responsables de equipo, gestores regionales, técnicos de soporte o perfiles de solo lectura. Cuanto más fina es la matriz de permisos, más fácil es olvidar una comprobación en un endpoint secundario.

Otro punto delicado son las apps móviles. Aunque la interfaz oculte botones, filtros o documentos, la API sigue ahí. La seguridad no puede depender de que el cliente “no enseñe” una opción. Cualquier persona puede inspeccionar tráfico, repetir peticiones y alterar parámetros.

Cómo reducir el riesgo en una API real

La primera medida es clara: comprobar autorización en el servidor para cada operación sensible. No en el front-end. No solo en el API Gateway. No solo al iniciar sesión. En el punto exacto donde se accede al objeto.

Una regla práctica: toda función que reciba un ID desde fuera debe preguntarse “¿este sujeto puede hacer esta acción sobre este objeto?”. Sujeto, acción y objeto. Ese triángulo obliga a pensar con precisión: no es lo mismo leer una factura que borrarla, ni ver un pedido propio que modificar uno de otra empresa.

También conviene centralizar la lógica de permisos. Si cada endpoint implementa condiciones a mano, la aplicación acabará llena de excepciones. Mejor usar políticas reutilizables, middleware de autorización, modelos RBAC o ABAC cuando el dominio lo requiera: roles, propietario, tenant, estado del recurso y nivel de sensibilidad.

API Gateway, tokens y logs no bastan

Un API Gateway ayuda mucho. Puede autenticar peticiones, aplicar rate limiting, validar esquemas, bloquear tráfico extraño y centralizar observabilidad. Pero no conoce, por sí solo, todas las reglas de negocio. Sabe que un token es válido; no siempre sabe si la factura 12345 pertenece al usuario que la pide.

Los tokens también se malinterpretan. Un JWT con el identificador del usuario no resuelve la autorización si el backend no lo usa para filtrar datos. Sin esa verificación, el token solo acredita identidad, no permiso sobre cada recurso.

Los logs y trazas ayudan a detectar patrones sospechosos: muchos accesos consecutivos a IDs distintos, errores 403 repetidos o acciones inusuales sobre recursos sensibles. Pero la detección no sustituye el diseño seguro. En modelos de Zero Trust, la idea es sencilla: no asumir confianza; verificar contexto y permiso antes de actuar.

Conclusión

IDOR y BOLA recuerdan una idea básica: estar dentro de una aplicación no significa tener derecho a verlo todo. En APIs, esa diferencia es crítica porque cada endpoint puede abrir una puerta directa a datos y acciones. La solución no pasa por ocultar botones ni usar IDs largos, sino por autorizar cada operación con criterio de negocio. ¿Te has encontrado un fallo de este tipo? El debate está abierto.