Qué es IDOR: broken access control, ejemplos y defensa

IDOR (insecure direct object reference, referencia directa insegura a objetos) es una vulnerabilidad de broken access control en la que una aplicación expone un identificador de un recurso interno (el id de una factura, el número de un pedido, el UUID de un documento) y confía en ese valor para servir el objeto sin comprobar si el usuario que lo solicita tiene permiso sobre él. El atacante no rompe la autenticación ni roba credenciales: inicia sesión con su propia cuenta legítima, cambia un parámetro y accede a datos de otras personas. Por eso IDOR se clasifica dentro de Broken Access Control (A01), la categoría número uno del OWASP Top 10.

Lo esencial. IDOR aparece cuando la autorización se delega en un identificador manipulable por el cliente en lugar de verificarse en el servidor contra la identidad de la sesión. La defensa no consiste en ocultar el identificador (los UUID no protegen por sí solos), sino en comprobar la propiedad del objeto en cada petición, aplicar deny by default y centralizar el control de acceso a nivel de objeto. Herramientas como Burp Suite con la extensión Autorize permiten detectarlo comparando dos sesiones.

Qué es IDOR y broken access control

Broken access control agrupa todos los fallos en los que un usuario puede realizar acciones o acceder a datos fuera de los permisos que le corresponden. Dentro de esa categoría, IDOR es el patrón más común y directo: la aplicación recibe una referencia a un objeto (habitualmente en la URL, en un parámetro de formulario, en el cuerpo de una petición JSON o en una cabecera) y devuelve ese objeto sin verificar que pertenece al usuario autenticado.

El nombre lo describe con precisión. La referencia es directa porque apunta al identificador real del recurso en el backend (la clave primaria de la base de datos, el nombre de un fichero, la posición en un array). Y es insegura porque el único control que se aplica es la autenticación (saber quién eres), no la autorización (saber si puedes ver ese objeto concreto). La aplicación asume que si el navegador envía id=1043, el usuario tiene derecho a ver el objeto 1043, cuando lo único que ha hecho es teclear otro número.

La diferencia entre autenticación y autorización es el núcleo del problema. La autenticación resuelve la identidad: la sesión es válida, el token no ha caducado, la cookie es correcta. La autorización resuelve el permiso: este usuario concreto puede leer, modificar o borrar este recurso concreto. Un IDOR ocurre cuando el primer control existe y el segundo falta. Es un fallo de diseño, no de configuración, y por eso los escáneres automáticos lo detectan mal: la petición es sintácticamente perfecta y la respuesta es un 200 legítimo.

Ejemplo técnico de un exploit IDOR

El caso canónico es un endpoint que sirve un recurso a partir de su identificador. Un usuario autenticado consulta su propia factura:

GET /api/invoices/1043 HTTP/1.1
Host: app-victima.tld
Cookie: session=<sesión válida del atacante>

Si el servidor recupera la factura 1043 y la devuelve sin comprobar que pertenece a la cuenta del solicitante, basta con enumerar identificadores contiguos para leer facturas ajenas:

GET /api/invoices/1044 HTTP/1.1
GET /api/invoices/1042 HTTP/1.1

El mismo patrón se repite en parámetros de escritura. Un endpoint que actualiza un perfil confiando en el user_id enviado por el cliente permite modificar la cuenta de otra persona:

POST /api/profile/update HTTP/1.1
Content-Type: application/json

{ "user_id": 5012, "email": "atacante@malicio.tld" }

Los identificadores no siempre son secuenciales. Cuando la aplicación usa UUID, la enumeración ciega deja de funcionar, pero el IDOR sigue vivo si esos UUID se filtran en otros endpoints (listados, respuestas de búsqueda, notificaciones, logs, URLs compartidas o el Referer). La lección es clara: un identificador difícil de adivinar reduce la enumeración masiva, pero no sustituye a la comprobación de autorización. Confiar solo en la imposibilidad de adivinar el valor es seguridad por oscuridad.

Estos patrones se reproducen en laboratorios controlados como PortSwigger Web Security Academy, OWASP Juice Shop o entornos propios, y forman parte de cualquier auditoría web responsable.

IDOR horizontal y vertical: tipos de escalada

Los accesos indebidos por IDOR se clasifican según hacia dónde se mueve el atacante en el modelo de permisos.

En el mundo de las APIs, IDOR recibe el nombre de BOLA (broken object level authorization) y es, de hecho, el riesgo número uno del OWASP API Security Top 10. La variante que afecta a funciones completas en lugar de a objetos individuales es BFLA (broken function level authorization). La distinción importa porque la remediación difiere: BOLA exige comprobar propiedad objeto a objeto, mientras que BFLA exige verificar el rol antes de exponer la función.

Cómo testear IDOR en una auditoría

IDOR es un hallazgo de revisión manual asistida. El flujo típico requiere al menos dos cuentas de prueba con datos distintos:

1. Autenticarse con la cuenta A y capturar cada petición que referencia un objeto (identificadores en URL, parámetros, cuerpo JSON y cabeceras) con Burp Suite.
2. Repetir la petición de la cuenta A usando la sesión de la cuenta B. Si la respuesta devuelve el objeto de A, hay IDOR horizontal.
3. Automatizar la comparación con la extensión Autorize de Burp, que reenvía cada petición con las cookies de una sesión de menor privilegio y marca en verde, naranja o rojo si el control de acceso se aplica, es dudoso o está ausente. Auth Analyzer ofrece una función equivalente.
4. Enumerar identificadores contiguos con Intruder cuando sean secuenciales, y buscar fugas de UUID en otros endpoints cuando no lo sean.
5. Probar variantes de método (cambiar GET por POST, PUT o DELETE), parámetros duplicados, wrappers de array (id[]=1044) y rutas alternativas que apunten al mismo objeto.

El punto crítico es que los escáneres automáticos (DAST) rara vez detectan IDOR por sí solos, porque no entienden qué objeto debería pertenecer a qué usuario. La confirmación siempre requiere el contexto de al menos dos identidades y el juicio del auditor. Estas técnicas forman parte estándar de una auditoría de aplicaciones web y de APIs REST y GraphQL.

Defensas y remediación

Autorización a nivel de objeto en el servidor

La única defensa que resuelve el problema de raíz es comprobar, en cada petición y en el servidor, que el objeto solicitado pertenece a la identidad de la sesión. En la práctica significa que la consulta a la base de datos incluya la propiedad como condición: en lugar de SELECT * FROM invoices WHERE id = :id, usar SELECT * FROM invoices WHERE id = :id AND owner_id = :session_user. Nunca se debe confiar en un user_id, account_id o role enviado por el cliente para decidir el alcance.

Deny by default y validación de propiedad

El control de acceso debe partir de la negación por defecto: si no hay una regla explícita que autorice, se deniega. Cada endpoint que recibe una referencia a un objeto debe validar la propiedad o la pertenencia antes de leer, escribir o borrar. Es preferible fallar de forma cerrada (403) que abierta.

Referencias indirectas por sesión

Un patrón defensivo adicional es sustituir el identificador real por una referencia indirecta con ámbito de sesión: la aplicación mantiene un mapa que traduce, por ejemplo, 1, 2, 3 (índices locales del usuario) a las claves primarias reales, de forma que un índice de la sesión de un usuario no significa nada en la de otro. No sustituye a la comprobación de autorización, pero reduce la superficie de enumeración y evita exponer la estructura interna.

Control de acceso centralizado (RBAC y ABAC)

Dispersar las comprobaciones de permisos por cada controlador garantiza que antes o después una se olvide. La práctica madura es centralizar la decisión en una capa o política única (RBAC basado en roles, ABAC basado en atributos, o motores como OPA) que todos los endpoints consultan. Frameworks como Spring Security, Django, Laravel o ASP.NET ofrecen mecanismos de autorización declarativa a nivel de objeto que conviene usar en lugar de reinventar el control en cada ruta.

Registro y detección

Registrar los accesos denegados y monitorizar picos de peticiones a identificadores contiguos ayuda a detectar enumeración en curso. Un usuario legítimo no recorre secuencialmente miles de facturas ajenas en pocos segundos.

IDOR en APIs REST y GraphQL

Las APIs concentran hoy la mayoría de los IDOR reales porque exponen identificadores de objeto de forma explícita y numerosa. En REST, cada recurso anidado (/users/{id}/orders/{orderId}) es un punto potencial de fallo si la autorización no se comprueba en cada nivel. En GraphQL, el riesgo se traslada a los argumentos de queries y mutations: un node(id: ...) o un campo que acepta un identificador puede servir objetos ajenos si el resolver no valida la propiedad. La introspección de GraphQL, además, facilita al atacante descubrir qué tipos y campos existen. El tratamiento en profundidad está en pentesting de GraphQL.

Conviene recordar que IDOR es primo hermano de otros fallos de confianza mal ubicada. Al igual que CSRF explota la confianza del servidor en el navegador, SSRF la confianza del servidor en sus peticiones salientes y CORS la relajación de la política de mismo origen, IDOR explota la confianza del servidor en un identificador que el cliente controla.

Casos reales y CVEs públicos

IDOR no es un problema teórico. En 2019, First American Financial Corporation expuso cerca de 885 millones de documentos financieros sensibles porque bastaba con modificar el número de registro en una URL para acceder a documentos ajenos, un IDOR de manual. El servicio Informed Delivery de USPS sufrió un BOLA que permitía consultar datos de decenas de millones de cuentas. Casos posteriores de scraping masivo en redes sociales se apoyaron en identificadores secuenciales sin control de acceso.

En el NVD, las búsquedas por IDOR, insecure direct object reference o broken access control devuelven un flujo constante de entradas que afectan a CMS, plugins, paneles de administración, dispositivos con interfaz web y software SaaS. El patrón común se repite: identificador manipulable, autenticación presente, autorización a nivel de objeto ausente.

Encaje con OWASP Top 10

Broken Access Control es la categoría A01 y encabeza el OWASP Top 10 desde 2021, por delante de inyección o de fallos criptográficos. IDOR es su manifestación más frecuente y aparece de forma explícita en la descripción de la categoría. En el ámbito de las APIs, BOLA ocupa el primer puesto del OWASP API Security Top 10. La lectura es directa: si tuviera que priorizarse un único tipo de fallo en una auditoría web o de API moderna, el control de acceso a nivel de objeto sería el candidato. El detalle de la categoría está en la guía del OWASP Top 10 2025 y una visión general en las cinco vulnerabilidades web más comunes.

Preguntas frecuentes

¿En qué se diferencia IDOR de un fallo de autenticación?

En que la autenticación funciona. El atacante inicia sesión con una cuenta legítima propia y la sesión es válida. Lo que falla es la autorización: la aplicación no comprueba si el objeto solicitado pertenece a ese usuario. Un fallo de autenticación deja entrar a quien no debería; un IDOR deja ver a quien ya ha entrado datos que no le corresponden.

¿Usar UUID en lugar de IDs numéricos elimina el IDOR?

No. Un UUID dificulta la enumeración masiva, pero no impide el acceso si el valor se filtra en un listado, una URL compartida, una notificación o un log. Confiar únicamente en la imposibilidad de adivinar el identificador es seguridad por oscuridad. La defensa correcta es comprobar la propiedad del objeto en el servidor.

¿Qué diferencia hay entre IDOR horizontal y vertical?

En la escalada horizontal el atacante accede a objetos de otro usuario con su mismo nivel de privilegio (la factura de otro cliente). En la escalada vertical accede a funciones u objetos reservados a un rol superior (una operación de administración). Ambas son broken access control, pero la vertical suele tener mayor impacto.

¿Qué es BOLA y en qué se relaciona con IDOR?

BOLA (broken object level authorization) es el nombre que el OWASP API Security Top 10 da al IDOR en el contexto de APIs, y ocupa el puesto API1. Es exactamente el mismo fallo: un identificador de objeto expuesto sin comprobación de autorización. BFLA (API5) es su equivalente a nivel de función.

¿Detectan los escáneres automáticos los IDOR?

Rara vez de forma fiable. Un escáner no sabe qué objeto debería pertenecer a qué usuario, y la petición vulnerable es sintácticamente correcta con respuesta 200. La detección requiere al menos dos cuentas de prueba y comparación manual, habitualmente con Burp y la extensión Autorize o Auth Analyzer.

Recursos relacionados

• Pentesting de aplicaciones web
• Pentesting de APIs REST y GraphQL
• Qué es CSRF: cross-site request forgery
• Qué es SSRF: server-side request forgery
• OWASP Top 10 2025 para empresas
• Las 5 vulnerabilidades web más comunes en 2025

Auditar IDOR y control de acceso con Secra

Secra realiza auditorías de aplicaciones web y APIs alineadas con OWASP Top 10, OWASP API Security Top 10 y la OWASP Web Security Testing Guide. Probamos control de acceso a nivel de objeto y de función con múltiples identidades, enumeración de identificadores, escalada horizontal y vertical, y revisión de la lógica de autorización del framework para confirmar que la propiedad se verifica en el servidor y no en el cliente.

Entregamos hallazgos priorizados, pruebas de concepto reproducibles con dos cuentas y recomendaciones de hardening concretas: consultas con condición de propiedad, deny by default, centralización del control de acceso y casos de regresión que se integran en CI para evitar reintroducir IDOR al añadir endpoints.

Si necesitáis una revisión profesional de broken access control, IDOR y el resto del catálogo OWASP, escribidnos desde nuestro servicio de auditoría web y móvil o a través de /es/contacto/ y planificamos una auditoría adaptada al alcance de vuestra plataforma.