IDOR y BOLA: qué son, cómo se encuentran y cómo se evitan

Qué es

Un IDOR (Insecure Direct Object Reference) aparece cuando una aplicación te da acceso a un recurso solo porque conoces su identificador. La aplicación comprueba que has iniciado sesión, pero no comprueba que ese pedido, esa factura o ese mensaje sean tuyos. En las APIs se le llama BOLA (Broken Object Level Authorization) y encabeza desde hace años la lista OWASP API Security Top 10.

La idea cabe en una línea: si cambias el número de la petición y recibes los datos de otra persona, hay un IDOR.

- GET /api/facturas/10432 HTTP/1.1
+ GET /api/facturas/10433 HTTP/1.1

Dónde suele aparecer

• Identificadores en la URL (/pedido/123), en el cuerpo JSON ("user_id": 123) o en parámetros ocultos de formularios.
• Acciones de escritura, no solo de lectura: borrar, editar o compartir un recurso ajeno suele ser más grave que verlo.
• Funciones secundarias que se programan con menos cuidado: exportar a PDF, descargar adjuntos, invitaciones, notificaciones o versiones antiguas de la API.
• Aplicaciones móviles, cuyos endpoints a menudo no se revisan tanto como los de la web.

Usar identificadores largos y aleatorios (UUID) no lo arregla: solo lo hace más difícil de explotar. Si el identificador aparece en otra respuesta, en un enlace compartido o en un correo, el fallo sigue ahí.

Cómo se busca

1. Crea dos cuentas propias (A y B) en el programa. Nunca pruebes con datos de usuarios reales.
2. Recorre la aplicación con la cuenta A y anota todas las peticiones que incluyan un identificador.
3. Repite esas peticiones con la sesión de B, sin cambiar el identificador de A.
4. Fíjate también en los métodos: a veces GET está protegido y PUT o DELETE sobre el mismo recurso no.
5. Prueba a añadir identificadores donde no los hay: algunos endpoints aceptan un user_id que la aplicación no envía pero el servidor sí lee.

Cómo se evita

• Comprobar la autorización en el servidor, en cada petición y para cada objeto: "¿este recurso pertenece a quien lo pide, o tiene permiso sobre él?".
• Centralizar esa comprobación (por ejemplo, filtrando siempre las consultas por el propietario) en lugar de repetirla a mano en cada endpoint.
• Añadir pruebas automáticas con dos usuarios que intenten acceder a recursos del otro.

Al reportarlo

Demuestra el acceso usando solo tus dos cuentas y explica qué datos o acciones quedan expuestos. El impacto depende de qué se puede leer o modificar, no de que el identificador sea fácil de adivinar.