IDOR: El fallo de autorización de 1.000 millones que debes corregir

Introducción: La vulnerabilidad más sencilla con mayor impacto

Imagina cambiar un solo número en una URL —de user_id=123 a user_id=124— y de repente acceder a los registros médicos, estados bancarios o mensajes privados de otra persona. Esto no es un hackeo sofisticado que requiera herramientas avanzadas o exploits de día cero. Es una Insecure Direct Object Reference (IDOR), y sigue siendo una de las vulnerabilidades más devastadoras pero menos detectadas en las aplicaciones web modernas.

A pesar de décadas de conciencia en seguridad, las vulnerabilidades IDOR representan el 15% de las recompensas pagadas por organizaciones de retail y comercio electrónico, y constituyen la principal vulnerabilidad en programas gubernamentales (18%), tecnología médica (36%) y servicios profesionales (31%). El impacto financiero es asombroso: aunque las cifras exactas varían por incidente, el coste colectivo de brechas de datos con fallos en control de acceso alcanza miles de millones anualmente.

¿Qué es exactamente un IDOR?

En esencia, una vulnerabilidad IDOR ocurre cuando una aplicación expone acceso directo a objetos —como registros de bases de datos, archivos o cuentas de usuario— basándose en entradas suministradas por el usuario sin verificaciones de autorización adecuadas. La aplicación confía en que si puedes hacer referencia a un identificador de objeto, deberías tener acceso a él.

Considera este escenario típico:

https://banking.example.com/api/statement?account_id=98765

Si la aplicación no verifica que el usuario autenticado realmente posee la cuenta 98765, un atacante puede simplemente cambiar el parámetro a 98764 o 98766 y acceder a los estados financieros de otros clientes. Este fallo fundamental proviene de una única omisión en el control de seguridad: la validación de autorización.

IDOR cae bajo “Broken Access Control” en el OWASP Top 10, indicando claramente su gravedad. A diferencia de vulnerabilidades complejas que requieren encadenar múltiples exploits, los IDOR son directos —pero su simplicidad no los hace menos peligrosos.

La anatomía de un ataque IDOR

Cómo se manifiestan los IDOR

Las vulnerabilidades IDOR aparecen en diversas formas en las aplicaciones:

1. Parámetros en URL La forma más reconocible, donde los identificadores de objetos aparecen directamente en las URLs:

/profile?user_id=1337
/invoice.pdf?doc_id=5829
/messages?conversation_id=abc123

2. Endpoints de API Las aplicaciones modernas dependen mucho de APIs, convirtiéndolas en territorio IDOR:

POST /api/v1/user/update
{
  "user_id": "549302",
  "email": "attacker@email.com"
}

3. Campos ocultos en formularios Parámetros incrustados en solicitudes POST que los usuarios no ven:

cinput type="hidden" name="order_id" value="88291"e
cinput type="hidden" name="user_guid" value="a8f5f167"e

4. Cookies y cabeceras Ubicaciones menos evidentes donde pueden esconderse referencias a objetos:

X-User-ID: 12345
Authorization: Bearer eyJ1c2VyX2lkIjoxMjM0NX0=

Tipos de vulnerabilidades IDOR

Los expertos en seguridad categorizan los IDOR en varios tipos: los IDOR horizontales permiten a atacantes acceder a datos de otros usuarios en el mismo nivel de privilegio, mientras que los IDOR verticales permiten acceder a datos con mayores privilegios. Los IDOR a nivel de objeto implican modificar o eliminar objetos, y los IDOR a nivel de función permiten acceder a funciones o acciones no autorizadas.

Impacto real: Consecuencias millonarias

Descubrimientos destacados de IDOR

La comunidad de bug bounty ha documentado miles de hallazgos IDOR, algunos con recompensas sustanciales:

Vulnerabilidad IDOR que permite añadir usuarios secundarios en cuentas de negocio de PayPal y ganar $10,500
Vulnerabilidad de eliminación en el sistema de certificación de HackerOne pagada con $12,500
IDOR en una app bancaria que permite acceder a datos de transacciones de otros usuarios y generó una recompensa de $3,500
IDOR que expone detalles privados de informes a través del endpoint bugs.json de HackerOne reportada

Un cazador de bug bounty experimentado reportó que a lo largo de su carrera ha descubierto innumerables IDOR, filtrando aproximadamente 250 millones de registros. Esta estadística ilustra la escala en que estas vulnerabilidades pueden exponer datos sensibles.

Industrias en riesgo

Ningún sector está exento a las vulnerabilidades IDOR:

Salud: registros médicos, datos de recetas, información de pacientes Finanzas: estados bancarios, historial de transacciones, datos de tarjetas de crédito E-commerce: historial de pedidos, información de pagos, direcciones de envío Redes sociales: mensajes privados, listas de contactos, datos de ubicación Plataformas SaaS: datos empresariales, registros de clientes, análisis

Las fallas en control de acceso, incluyendo IDOR, representaron una parte significativa de las brechas en 2024, con un investigador que encontró una vulnerabilidad que permitía a atacantes modificar conexiones API en varias organizaciones, causando potencialmente interrupciones masivas y filtraciones de datos.

Por qué persisten los IDOR en 2025

A pesar de estar bien documentados desde hace más de una década, las vulnerabilidades IDOR siguen afectando las aplicaciones modernas. Varios factores contribuyen a su persistencia:

1. Dificultad en detección

Los IDOR no pueden ser detectados solo con herramientas automáticas y requieren creatividad y pruebas manuales de seguridad para identificarlos. Aunque algunos escáneres detectan actividad, es necesaria la revisión humana para analizar, evaluar e interpretar los hallazgos. Las pruebas de penetración tradicionales pueden pasar por alto estas vulnerabilidades si los testers no examinan cada parámetro en cada endpoint.

2. Complejidad en desarrollo

Las aplicaciones modernas involucran múltiples capas —frameworks frontend, gateways API, microservicios y bases de datos—. La lógica de autorización debe implementarse de forma coherente en todas estas capas. Un solo descuido en cualquier componente puede crear un vulnerabilidad IDOR.

3. La creencia en UUIDs

Muchos desarrolladores creen que usar UUIDs (Identificadores Únicos Universales) en lugar de enteros secuenciales previene ataques IDOR. Aunque los UUIDs dificultan la adivinanza, es importante evaluar si la referencia a un objeto es realmente difícil de adivinar o fácil de enumerar, ya que los UUIDs pueden divulgarse en otras partes de la aplicación. Si un UUID se filtra por otro endpoint, la vulnerabilidad IDOR persiste.

4. Desarrollo API-First

Las APIs priorizan funcionalidad y velocidad, y los desarrolladores a menudo omiten implementar controles de acceso adecuados para cada endpoint de objeto, generando vulnerabilidades IDOR. La prisa por entregar funciones puede opacar las consideraciones de seguridad.

Técnicas avanzadas de explotación IDOR en 2025

A medida que evolucionan las medidas de seguridad, también lo hacen las metodologías de ataque. En 2025, ya no basta con manipular parámetros simples, y las vulnerabilidades IDOR han evolucionado, requiriendo técnicas avanzadas más allá de la simple manipulación de parámetros.

1. IDOR ciegos

En ataques IDOR ciegos, no se ven inmediatamente los resultados de la explotación. Por ejemplo: - Eliminar elementos guardados de otro usuario (sin confirmación visible) - Modificar direcciones de correo (los cambios ocurren en silencio) - Darse de baja de servicios de otros (la acción se completa sin retroalimentación)

Estos requieren métodos creativos de validación, como crear dos cuentas de prueba y monitorear efectos entre ellas.

2. Referencias codificadas y hashed

Las aplicaciones pueden codificar o hashear identificadores:

/document?id=ZTRkYTNiN2ZiYmNlMjM0NWQ3NzcyYjA2NzRhMzE4ZDU

Esto parece estar en base64, que al decodificarlo resulta en un hash MD5. Los atacantes decodifican, crackean o descubren patrones en estos identificadores para explotar el IDOR subyacente.

3. Vulnerabilidades de asignación masiva

Los atacantes pueden inyectar parámetros adicionales no previstos por los desarrolladores:

POST /api/update_profile
{
  "username": "attacker",
  "bio": "Nuevo texto de biografía",
  "user_id": "12345",  // Parámetro inyectado
  "role": "admin"       // Intento de escalada de privilegios
}

Si la aplicación procesa todos los parámetros sin filtrar, puede permitir modificaciones no autorizadas.

4. Condiciones de carrera IDOR

Combinar IDOR con ataques de temporización puede sortear ciertas protecciones. Enviando múltiples solicitudes simultáneamente con diferentes identificadores, los atacantes pueden explotar ventanas temporales donde las verificaciones de autorización aún no se han completado.

5. IDOR en GraphQL y REST API

Las arquitecturas modernas de API introducen nuevas superficies de ataque. Las consultas GraphQL, en particular, permiten solicitudes complejas anidadas que pueden saltarse restricciones del frontend:

query {
  user(id: "target_user_id") {
    email
    phone
    creditCards {
      last4digits
      expiryDate
    }
  }
}

Cómo encontrar IDOR: metodología de un cazador de bug bounty

Fase de reconocimiento

Los IDOR pueden existir en toda la aplicación, así que cada vez que encuentres IDs, debes probarlos —incluso si parecen ser GUIDs o valores encriptados.

Paso 1: Mapear la aplicación - Crear varias cuentas de prueba con diferentes niveles de privilegio - Documentar toda la funcionalidad disponible para cada tipo de cuenta - Identificar cada endpoint que acepte identificadores de objetos

Paso 2: Interceptar todo el tráfico Utiliza herramientas como Burp Suite para capturar cada solicitud: - Solicitudes HTTP GET/POST - llamadas API (REST, GraphQL, SOAP) - mensajes WebSocket - solicitudes AJAX de aplicaciones de página única

Paso 3: Catalogar referencias a objetos Construir una lista completa de todos los parámetros que hacen referencia a objetos: - id, uid, user_id, account_id - doc_id, file_id, attachment_id - order_id, transaction_id, invoice_id - Cualquier GUID, UUID o identificador codificado

Fase de prueba

Manipulación de parámetros La prueba fundamental de IDOR —modificar valores de identificadores—:

Original: /api/orders/12345
Prueba 1:   /api/orders/12344  (decremento)
Prueba 2:   /api/orders/12346  (incremento)
Prueba 3:   /api/orders/1      (valor límite)
Prueba 4:   /api/orders/99999  (valor alto)

Pruebas entre cuentas Usando varias cuentas, intenta acceder a objetos de otros: 1. Usuario A crea/accede a un recurso (anota el ID) 2. Usuario B intenta acceder al recurso del Usuario A usando el ID capturado 3. Analiza la respuesta en busca de filtraciones o accesos no autorizados

Pruebas ciegas Para acciones sin retroalimentación inmediata: 1. Usuario A crea un recurso (dirección guardada, ítem en lista de deseos) 2. Usuario B intenta eliminar/modificar usando el ID del recurso del Usuario A 3. Usuario A verifica si su recurso fue afectado

Inyección de parámetros Intenta agregar parámetros que no deberían estar:

// Solicitud original
{"email": "user@example.com"}

// Prueba con user_id inyectado
{"email": "user@example.com", "user_id": "target_id"}

Técnicas avanzadas de descubrimiento

Enumeración a escala Usa Burp Intruder o scripts personalizados para probar rangos de identificadores:

for user_id in range(1000, 2000):
    response = request(f"/api/profile?id={user_id}")
    if response.status_code == 200:
        analyze_data(response)

Análisis en JavaScript Busca posibles filtraciones de IDs en perfiles públicos, publicaciones o patrones que te permitan generar tus propios IDs y probar con herramientas como Burp Suite’s Intruder. El JavaScript del frontend a menudo revela endpoints de API y formatos de identificadores.

Pruebas en aplicaciones móviles Las apps móviles suelen consultar APIs con IDs de usuario, y estos IDs pueden manipularse para ver información de otros usuarios. Intercepta el tráfico móvil con herramientas como Burp Suite Mobile Assistant o mitmproxy.

Prevención: Construir autorización adecuada

Para desarrolladores

1. Implementar verificaciones robustas de autorización Cada endpoint debe verificar:

def get_user_order(order_id, current_user):
    order = database.get_order(order_id)
    
    # Verificación crítica de autorización
    if order.user_id != current_user.id:
        raise UnauthorizedException("Acceso denegado")
    
    return order

2. Usar referencias indirectas a objetos En lugar de exponer IDs internos, usa tokens únicos e impredecibles como UUIDs o cadenas aleatorias. El servidor mapea estos tokens a IDs internos, vinculándolos de forma segura a la sesión del usuario.

# Generar referencia específica de sesión
token_seguro = generate_secure_token()
sesion_map[token_seguro] = {
    'user_id': current_user.id,
    'object_id': actual_object_id
}
return token_seguro

3. Validar la entrada del usuario Validar estrictamente todos los parámetros suministrados por el usuario en cuanto a formato, longitud y contenido, y esta validación debe hacerse en el servidor, ya que las verificaciones en cliente son fácilmente evadibles.

4. Limitar consultas Asegurar que las consultas a la base de datos filtren automáticamente por el usuario autenticado:

-- Consulta vulnerable
SELECT * FROM orders WHERE id = ?

-- Consulta segura con scoping
SELECT * FROM orders WHERE id = ? AND user_id = ?

5. Pruebas exhaustivas - Implementar pruebas automáticas de autorización en tu pipeline de CI/CD - Realizar revisiones de código de seguridad centradas en lógica de autorización - Contratar testers de penetración para verificar manualmente los controles de autorización

Para equipos de seguridad

Defensa en profundidad Implementa múltiples capas de autorización: - Autenticación en el gateway - Autorización en el servicio - Controles de acceso a nivel de base de datos - Registro de auditoría para todo acceso a objetos

Seguridad desde el diseño Los proveedores, diseñadores y desarrolladores de frameworks y aplicaciones web deben aplicar principios de seguridad por diseño y por defecto, asegurando que el software implemente verificaciones de autenticación y autorización en cada solicitud.

Estadísticas y tendencias en bug bounty de IDOR

Panorama actual

Las vulnerabilidades válidas en la plataforma HackerOne han aumentado un 12% en el último año, con 78,042 problemas válidos en más de 1,300 programas de clientes. Aunque las organizaciones mejoran su postura de seguridad, el número absoluto de vulnerabilidades sigue creciendo a medida que más empresas adoptan programas de bug bounty.

En HackerOne, se detectan y reportan de forma segura más de 200 vulnerabilidades IDOR cada mes, demostrando la persistencia de esta clase de vulnerabilidades.

Por qué los IDOR siguen siendo las principales hallazgos en recompensas

Varios factores hacen que los IDOR sean atractivos para los cazadores de bug bounty:

Impacto alto, prueba clara: Los IDOR proporcionan evidencia concreta de acceso no autorizado a datos
Escalabilidad: Un solo IDOR puede explotarse en miles de registros
Comprensión de la lógica de la aplicación: Encontrar IDOR requiere conocimiento de la app, no solo escaneo automatizado
Pagos consistentes: Las empresas reconocen la gravedad y recompensan consistentemente los hallazgos de IDOR

Evolución en las pruebas

La comunidad de investigadores en seguridad está perfeccionando sus habilidades, con más miembros enfocándose en móviles, APIs y despliegues de IA a medida que el alcance de las pruebas se expande a superficies de ataque más variadas. Esto significa que las pruebas de IDOR cada vez involucran: - Flujos complejos de autorización en APIs - Manipulación de consultas GraphQL - Explotación de arquitecturas de microservicios - Pruebas en aplicaciones nativas en la nube

Errores comunes y conceptos erróneos

“Usamos UUIDs, así que estamos seguros”

Aunque los UUIDs (por ejemplo, 550e8400-e29b-41d4-a716-446655440000) no son fáciles de adivinar, no eliminan los riesgos de IDOR: - Los UUIDs pueden filtrarse en otros endpoints - Pueden ser descubiertos mediante patrones de fuerza bruta - El problema principal —la falta de autorización— sigue presente

“Nuestros IDs están encriptados”

La encriptación añade una capa de oscuridad, pero no reemplaza la autorización. Si el servidor desencripta un ID sin verificar si el usuario debe acceder a ese objeto, sigue siendo un IDOR.

“Solo usuarios autenticados pueden acceder a nuestra API”

La autenticación (demostrar quién eres) y la autorización (demostrar qué puedes acceder) son aspectos separados. Estar logueado no garantiza automáticamente el acceso a todos los recursos.

“Limitamos las llamadas a la API”

Limitar la tasa previene abusos a gran escala, pero no detiene un ataque IDOR dirigido. Un atacante solo necesita acceder a unos pocos registros no autorizados para demostrar la vulnerabilidad.

El contexto de seguridad más amplio

Broken Access Control: El panorama general

IDOR forma parte de “Broken Access Control” que ocupa el puesto #1 en OWASP Top 10, con altas probabilidades de descubrimiento. Esta categoría incluye: - Falta de control de acceso a nivel de funciones - Referencias directas a objetos inseguras - Vulnerabilidades de traversal de rutas - Navegación forzada a páginas autenticadas - Manipulación de metadatos

El impacto económico

Aunque atribuir cifras específicas a IDOR es complejo, el contexto general es claro: - El coste medio de una brecha de datos es de 4.88 millones de dólares globalmente - Las organizaciones con programas de bug bounty identifican fallos críticos con recompensas de cuatro cifras - El coste colectivo de brechas evitadas mediante divulgación responsable alcanza miles de millones

Los programas de bug bounty reducen efectivamente la carga financiera a largo plazo de incidentes cibernéticos y complementan los equipos internos de seguridad con la experiencia de hackers éticos globales.

Herramientas del oficio

Herramientas esenciales para bug bounty

Burp Suite: Proxy estándar de la industria para interceptar y modificar solicitudes HTTP Postman: Plataforma para pruebas y automatización de APIs OWASP ZAP: Escáner de seguridad web de código abierto y gratuito Burp Intruder: Para pruebas automatizadas de parámetros y enumeración Scripts personalizados: Python/JavaScript para enumeración masiva de identificadores

Tecnologías emergentes

La búsqueda avanzada de IDOR cada vez involucra más: - Herramientas específicas para GraphQL (GraphQL Voyager, InQL) - Interceptación de tráfico en apps móviles (Frida, Objection) - Frameworks de fuzzing para APIs (RESTler, Dredd) - Escáneres de seguridad nativos en la nube

Conclusión: El bug persistente de 1.000 millones

Las referencias directas a objetos inseguras representan una paradoja en ciberseguridad: son fáciles de entender y, al mismo tiempo, increíblemente difíciles de eliminar por completo. El error fundamental —confiar en identificadores suministrados por el usuario sin verificaciones de autorización— se manifiesta en innumerables variaciones en las aplicaciones modernas.

Para las organizaciones, el camino a seguir requiere: - Prácticas de desarrollo con enfoque en seguridad - Pruebas exhaustivas de autorización - Participación en programas de bug bounty con la comunidad de investigadores - Monitoreo y validación continua de controles de acceso

Para los investigadores de seguridad, los IDOR siguen siendo una clase de vulnerabilidad lucrativa y de gran impacto. El éxito requiere: - Profundo entendimiento de la lógica de la aplicación - Pensamiento creativo más allá de las herramientas automatizadas - Pruebas metódicas en todas las superficies de ataque - Reportes claros y detallados de vulnerabilidades

A medida que las aplicaciones se vuelven más complejas con microservicios, APIs y arquitecturas nativas en la nube, surgirán nuevos vectores IDOR. Sin embargo, el principio central permanece: nunca confíes en referencias a objetos suministradas por el usuario sin una validación explícita de autorización.

La próxima vez que veas una URL con un parámetro ID, recuerda —ese número simple podría ser la clave para una vulnerabilidad de seguridad crítica que valga miles en recompensas de bug bounty, o peor aún, una brecha de datos que exponga millones de registros. En 2025 y más allá, los IDOR seguirán desafiando a los desarrolladores y recompensando a los investigadores vigilantes que entienden que la autorización no es opcional — es esencial.

Mantente seguro, prueba a fondo y recuerda: cada referencia a un objeto es una vulnerabilidad potencial hasta que se demuestre lo contrario.