La Referencia Directa a Objetos Inseguros (IDOR, por sus siglas en inglés) es consistentemente una de las vulnerabilidades de mayor impacto en aplicaciones web y APIs — y una de las más fáciles de pasar por alto en un pentest estándar si no sabes dónde buscar.

No requiere payloads complejos. Sin corrupción de memoria. Sin shellcode personalizado. Encuentras un ID, lo cambias por otro, y de repente estás leyendo los datos de otra persona. O borrándolos. O tomando el control de su cuenta.

Esta guía cubre todo lo que necesitas para encontrar y explotar IDOR en 2026: metodología de detección, técnicas de explotación, herramientas de automatización, bypass de WAF y cómo encadenar IDOR con otras vulnerabilidades para maximizar el impacto.

¿Qué es IDOR?

Referencia Directa a Objetos Inseguros (IDOR) ocurre cuando una aplicación usa entrada controlada por el usuario para acceder directamente a objetos (registros de base de datos, archivos, funciones) — sin verificar que el usuario solicitante está realmente autorizado a acceder a ese objeto específico.

El ejemplo más simple:

GET /api/v1/facturas/1042

Eres el usuario ID 55. La factura 1042 pertenece al usuario ID 89. Si la aplicación la devuelve de todas formas — eso es IDOR.

La vulnerabilidad no está en que el ID esté expuesto. Está en la verificación de autorización ausente. El servidor asume que si conoces el ID, estás autorizado a verlo. Esa suposición es incorrecta.

IDOR cae bajo Control de Acceso Roto en el OWASP Top 10 — la categoría #1 desde 2021 — y es la causa raíz de algunas de las filtraciones de datos más dañinas de la última década.

Por Qué IDOR Sigue Dominando el Bug Bounty en 2026

Tres razones por las que IDOR está en todas partes:

  1. Los desarrolladores asumen que la oscuridad = seguridad. Los UUIDs son “suficientemente aleatorios”, piensan. Los GUIDs son “impredecibles”. Excepto que hacen las pruebas con su propia cuenta y nunca intentan usar el ID de otro usuario.

  2. La autorización es difícil de probar sistemáticamente. Las herramientas de análisis estático son pésimas para encontrar IDOR. Necesitas múltiples cuentas con diferentes niveles de privilegio y debes sondear activamente.

  3. Las APIs modernas multiplican la superficie de ataque. Cada endpoint REST que acepta un ID es un posible IDOR. Una aplicación SaaS típica tiene cientos de estos. La mayoría nunca se prueba manualmente.

Los programas de bug bounty pagan bien por IDOR porque el impacto comercial es real: exposición de PII, exfiltración de datos, toma de control de cuentas, escalación de privilegios. Los hallazgos P1/críticos en HackerOne y Bugcrowd frecuentemente son IDOR.

IDOR vs BOLA: ¿Cuál es la Diferencia?

BOLA (Autorización Rota a Nivel de Objeto) es el nombre de OWASP API Security para lo mismo — IDOR en el contexto de APIs. Si ves BOLA referenciado en documentación de seguridad de APIs, es IDOR.

La distinción importa solo para la comunicación:

  • Usa IDOR cuando hablas de aplicaciones web tradicionales
  • Usa BOLA en informes de seguridad de APIs
  • Funcionalmente la misma clase de vulnerabilidad

Tipos de Vulnerabilidades IDOR

1. IDs Enteros Secuenciales

El clásico. IDs de usuario, IDs de pedido, números de factura, IDs de documento — enteros secuenciales que se incrementan de forma predecible.

/api/pedidos/10041
/api/pedidos/10042   ← el tuyo
/api/pedidos/10043

Cambia 10042 por cualquier otro número. Si el servidor no verifica la propiedad, puedes enumerar todos los pedidos del sistema.

2. IDs Codificados (Base64, Hex)

Las aplicaciones a veces codifican IDs para que parezcan “más seguros”:

/perfil?id=MTAwNDI=

Decodifica ese base64 → 10042. El mismo IDOR, a un paso de decodificación.

import base64
base64.b64decode("MTAwNDI=")  # b'10042'

Busca cadenas que terminen en = o == en los parámetros. Siempre intenta la decodificación base64 primero.

3. IDOR Basado en GUID/UUID

Los GUIDs parecen aleatorios pero no necesariamente lo son:

/api/documentos/550e8400-e29b-41d4-a716-446655440000

Los GUIDs generados con entropía débil o semillas predecibles pueden ser fuerza bruta. Más importante, los GUIDs frecuentemente se filtran — en respuestas de API, notificaciones por email, redirecciones de URL, encabezados de referrer. Encuentra el GUID de otro usuario a través de un endpoint diferente y úsalo directamente.

4. IDOR Multi-Paso

La operación vulnerable no está en la primera solicitud — está en un flujo de trabajo:

  1. POST /carrito/agregar → agrega ítem al carrito
  2. POST /carrito/checkout → procesa el pago
  3. GET /pedidos/{id_pedido} → aquí vive el IDOR

El paso 3 devuelve el pedido de otro usuario si adivinas su ID de pedido. El IDOR multi-paso frecuentemente se pasa por alto porque los testers se enfocan en los endpoints obvios.

5. IDOR por Contaminación de Parámetros

Las aplicaciones que aceptan JSON o datos de formulario a veces procesan parámetros ocultos:

POST /api/perfil/actualizar
{
  "nombre": "Juan",
  "email": "[email protected]",
  "user_id": 9999
}

El campo user_id no se muestra en la UI pero el servidor lo procesa. Agregarlo a la solicitud cambia el perfil de quién se actualiza. Asignación masiva clásica / contaminación de parámetros que lleva a IDOR.

6. IDOR por Ruta de Archivo

Descargas de archivos con rutas controladas por el usuario:

GET /descargar?archivo=informes/usuario_1042/reporte-q3.pdf

Cambia 1042 por el ID de otro usuario. O prueba path traversal:

GET /descargar?archivo=../../../etc/passwd

Esto es IDOR + path traversal combinado — común en funcionalidades de exportación/descarga.

7. IDOR Indirecto por Referencias

No todo IDOR es directo. Algunas aplicaciones usan referencias que mapean a objetos:

GET /api/mensajes?hilo_id=abc123

abc123 es un ID de hilo que pertenece a la conversación de otro usuario. Si el mapeo no se verifica en el servidor, puedes leer cualquier hilo.

Detección de IDOR: Dónde Buscar

Comienza cada pentest de aplicación web con un escaneo sistemático de referencias a objetos. Aquí está dónde buscar:

Parámetros de URL

/usuarios/1042/configuracion
/facturas/ver?id=9847
/admin/eliminar?registro=334

Cuerpos de Solicitudes JSON

{"user_id": 1042, "accion": "obtener_perfil"}
{"id_documento": "abc123", "formato": "pdf"}
{"cuenta": {"id": 9847}}

Encabezados

X-User-ID: 1042
X-Resource-Token: abc123
Authorization: Bearer <JWT con claim sub>

Los JWTs son comunes — decodifica el payload y verifica si algún campo mapea a objetos que puedes manipular.

Campos de Formulario Ocultos

<input type="hidden" name="user_id" value="1042">
<input type="hidden" name="ref_pedido" value="PED-9847">

El escaneo pasivo de Burp Suite destacará estos. Siempre verifica los campos ocultos.

Respuestas de API que Filtran IDs

Las respuestas frecuentemente filtran IDs que luego puedes usar en otras solicitudes:

{
  "usuario": {"id": 1042, "email": "[email protected]"},
  "creado_por": 89,          ← ID de otro usuario
  "asignado_a": 331,         ← ID de otro usuario
  "org_id": 7                ← referencia a nivel de organización
}

Recopila todos los IDs de cada respuesta. Prueba cada uno contra cada endpoint.

Metodología Manual de Prueba de IDOR

Paso 1: Configura Dos Cuentas

Necesitas como mínimo dos cuentas con el mismo nivel de privilegio. Crea:

  • Cuenta A (tu cuenta principal de prueba)
  • Cuenta B (tu cuenta “víctima”)

Para IDOR de mayor severidad, también crea:

  • Cuenta de administrador (si tu scope incluye escalación de privilegios)

Paso 2: Mapea Todas las Referencias a Objetos

Navega la aplicación como Cuenta A. Usa Burp Suite para interceptar todo. Crea una lista de cada ID/referencia que veas en:

  • Rutas de URL
  • Parámetros de consulta
  • Cuerpos de solicitudes
  • Cuerpos de respuestas

Paso 3: Genera Datos con la Cuenta B

Inicia sesión como Cuenta B y crea los mismos tipos de objetos (facturas, pedidos, documentos, mensajes). Anota los IDs asignados a los objetos de B.

Paso 4: Prueba como Cuenta A con las Referencias de B

Vuelve a iniciar sesión como Cuenta A. Toma cada endpoint que acepta una referencia a un objeto y reemplaza la referencia de A por la de B:

GET /api/facturas/ID_FACTURA_A  → 200 OK (esperado)
GET /api/facturas/ID_FACTURA_B  → debería ser 403, prueba si es 200

Documenta cada endpoint y resultado.

Paso 5: Prueba Operaciones que Cambian Estado

IDOR de solo lectura es P3. IDOR de escritura/eliminación es P1. Prueba:

PUT /api/pedidos/ID_PEDIDO_B  (como Cuenta A)
DELETE /api/mensajes/ID_MENSAJE_B  (como Cuenta A)
POST /api/transferencia?desde=CUENTA_B  (como Cuenta A)

Paso 6: Prueba Escalación de Privilegios

Usa B como cuenta de bajo privilegio. Prueba si A (también de bajo privilegio) puede acceder a recursos solo de administrador:

GET /api/admin/usuarios/lista  (como Cuenta A)
PUT /api/usuarios/ID_USUARIO_B/rol  {"rol": "admin"}  (como Cuenta A)

Descubrimiento Automatizado de IDOR

La prueba manual cubre los endpoints conocidos. La automatización cubre la superficie que de otra forma pasarías por alto.

Burp Suite — Extensión Authorize

Authorize es la extensión de Burp preferida para pruebas de IDOR. Intercepta cada solicitud de la Cuenta A y automáticamente la reproduce usando el token de sesión de la Cuenta B. Las diferencias en la respuesta indican IDOR potencial.

Configuración:

  1. Instala Authorize desde BApp Store
  2. Inicia sesión como Cuenta B, copia la cookie de sesión/encabezado de autenticación
  3. Pégalo en el campo “Auth Header” de Authorize
  4. Navega la app como Cuenta A
  5. Authorize reproduce cada solicitud como B — busca respuestas 200 OK donde B no debería tener acceso

Param Miner

Extensión de Burp que descubre parámetros ocultos no visibles en la UI. Frecuentemente descubre parámetros user_id, account_id, role que la aplicación procesa pero no expone al frontend.

Extensiones → Param Miner → Clic derecho en solicitud → Guess params

ffuf para Enumeración de IDOR

Una vez que encuentras un IDOR, fuzzea el rango completo:

ffuf -u "https://objetivo.com/api/facturas/FUZZ" \
  -H "Cookie: sesion=TU_COOKIE" \
  -w /usr/share/wordlists/numbers.txt \
  -mc 200 \
  -o resultados_idor.json

Genera un wordlist de enteros secuenciales:

seq 1 100000 > /tmp/numeros.txt

Script Python Personalizado

Para objetivos con muchas APIs, un script rápido supera al intercambio manual:

import requests

URL_BASE = "https://api.objetivo.com"
ENCABEZADOS_A = {"Authorization": "Bearer TOKEN_A"}
ENCABEZADOS_B = {"Authorization": "Bearer TOKEN_B"}

# Obtén los IDs de recursos de B
recursos_b = requests.get(f"{URL_BASE}/api/facturas", headers=ENCABEZADOS_B).json()
ids_b = [r["id"] for r in recursos_b["facturas"]]

# Prueba cada uno como A
for id_recurso in ids_b:
    r = requests.get(f"{URL_BASE}/api/facturas/{id_recurso}", headers=ENCABEZADOS_A)
    if r.status_code == 200:
        print(f"[IDOR] {id_recurso} accesible por Cuenta A → {r.text[:100]}")

Técnicas de Explotación

Escalación de Privilegios Horizontal

La más común: acceder a los datos de otro usuario con el mismo nivel de privilegio.

El impacto depende de lo que está expuesto:

  • Datos financieros (facturas, métodos de pago): P1-P2
  • PII (perfil, direcciones, SSN): P1
  • Mensajes/comunicaciones: P2
  • Datos genéricos de la app (preferencias, configuración): P3-P4

Documenta el alcance completo de la exposición. Si puedes leer 1 registro, puedes enumerar todos los registros. Calcula el radio de daño.

Escalación de Privilegios Vertical via IDOR

Mayor severidad: usa IDOR para escalar privilegios.

Escenario 1 — Modificación de rol:

PUT /api/usuarios/TU_USER_ID
{"rol": "admin", "nombre": "Tu Nombre"}

Si el campo de rol no se filtra en el servidor y puedes modificar tu propio objeto de usuario, has escalado a administrador.

Escenario 2 — Acceso a objetos de administrador:

GET /api/admin/registros-auditoria?usuario=1  (como usuario de bajo privilegio)

Sin verificación de privilegios en un endpoint “solo para administradores” — IDOR otorga acceso.

Escenario 3 — IDOR a nivel de función:

POST /api/admin/crear-usuario  (como usuario regular)

El endpoint existe y procesa solicitudes independientemente del rol del llamador. Esto es IDOR combinado con Autorización Rota a Nivel de Función.

Cadenas de IDOR

El daño real viene de encadenar IDOR con otras vulnerabilidades:

IDOR → Toma de Control de Cuenta:

  1. IDOR en /api/usuarios/{id}/email — puedes leer el email de cualquier usuario
  2. Usa el email para desencadenar restablecimiento de contraseña
  3. IDOR en /api/tokens-restablecimiento/{token} — puedes leer el token de restablecimiento
  4. Usa el token para restablecer la contraseña de la víctima → toma de control de cuenta

IDOR → SSRF:

  1. La aplicación tiene una función de webhook: POST /api/webhooks/{id}/probar
  2. IDOR te permite activar el webhook de otro usuario
  3. La URL del webhook apunta a servicios internos
  4. Ahora puedes enviar solicitudes SSRF a través del webhook de otro usuario

IDOR → Exfiltración de Datos a Escala:

  1. IDOR en /api/exportar/{id_trabajo}/descargar
  2. Los trabajos de exportación contienen volcados completos de datos
  3. Enumera IDs de trabajos → descarga exportaciones completas de otros usuarios

Bypass de WAF para IDOR

Los WAF no pueden prevenir IDOR — bloquean patrones de entrada maliciosa, e IDOR requiere solo un ID válido. No hay nada malicioso en el payload en sí. Un WAF que bloquea inyección SQL no bloqueará GET /api/facturas/1043 cuando solo deberías tener acceso a 1042.

Dicho esto, algunas aplicaciones implementan reglas de WAF personalizadas o limitación de velocidad que puede interferir con la enumeración de IDOR:

Bypass de Límite de Velocidad

Solicitudes distribuidas a través de múltiples IPs de origen:

ffuf -u "https://objetivo.com/api/facturas/FUZZ" \
  -H "Cookie: sesion=COOKIE" \
  -w numeros.txt \
  -rate 10 \
  -p 0.1-0.3

O rota a través de encabezados:

X-Forwarded-For: 1.2.3.4
X-Real-IP: 1.2.3.5
True-Client-IP: 1.2.3.6

Variaciones de Codificación de ID

Si la enumeración directa de enteros está bloqueada, prueba formas codificadas:

/api/facturas/1043         → prueba
/api/facturas/MTAzNA==     → base64
/api/facturas/0x40B        → hex
/api/facturas/1.043e3      → notación científica

Variación de Ubicación de Parámetros

Si el endpoint bloquea la modificación de ID en una ubicación, prueba otra:

GET /api/facturas?id=1043           → bloqueado
POST /api/facturas {"id": "1043"}   → prueba
GET /api/facturas/yo?override_id=1043  → prueba

Enumeración de Referencia Indirecta

Si la enumeración directa de ID activa la limitación de velocidad, encuentra el ID primero a través de un endpoint diferente:

GET /api/[email protected]  → devuelve user_id
GET /api/usuarios/{user_id_filtrado}/perfil   → IDOR con objetivo específico, sin fuerza bruta

Ejemplos Reales de IDOR

IDOR de Facebook — Eliminación de Posts de Usuarios (2015)

El investigador Laxman Muthiyah encontró que los usuarios autenticados podían eliminar cualquier post de otros usuarios modificando el parámetro post_id. Afectó cada cuenta de Facebook. Bounty: $12,500.

IDOR de Uber — Toma de Control de Cuenta de Conductor (2016)

IDOR en el flujo de activación de conductores permitió a atacantes interceptar tokens de activación y tomar el control de cuentas de conductores. La cadena de exploit combinó IDOR con una filtración de token en la respuesta de la API.

Departamento de Defensa de EE.UU. — Exposición de Datos IDOR (2019)

Divulgación pública de HackerOne: un IDOR en el portal de un contratista del DoD expuso PII de miles de empleados gubernamentales. IDs enteros secuenciales en endpoints de perfil, sin verificación de autorización.

IDOR del Panel de Partners de Shopify (2020)

Un investigador descubrió que la API de partners de Shopify aceptaba IDs de partners sin verificación de propiedad. Un atacante con cualquier cuenta de partner podía leer análisis, pedidos y datos de clientes de cualquier tienda de otros partners.

Patrones Modernos de IDOR en APIs (2025-2026)

La tendencia actual: BOLA en GraphQL. Las consultas GraphQL aceptan IDs de objetos en línea:

query {
  pedido(id: "ped_1043") {
    total
    cliente { email, direccion }
    pago { ultimos4, vencimiento }
  }
}

Sin introspección deshabilitada + verificaciones de autorización ausentes = modelo de datos completo expuesto a IDOR. Los hallazgos de BOLA en GraphQL dominaron los programas de bug bounty en 2025.

Laboratorios de Práctica

La mejor manera de aprender IDOR es con práctica real. Estos laboratorios te dan entornos seguros para practicar:

DVWA (Damn Vulnerable Web Application)

# Usa un VPS desechable para practicar
# Vultr Basic: $6/mes, instala Ubuntu 22.04
# https://www.vultr.com/?ref=9888008

docker run --rm -p 80:80 vulnerables/web-dvwa

El módulo IDOR de DVWA cubre enumeración básica de IDs. Configura la dificultad a Media/Alta para practicar técnicas de bypass.

WebGoat (OWASP)

docker run -p 8080:8080 -t webgoat/webgoat

WebGoat tiene lecciones dedicadas de IDOR que incluyen:

  • Referencias Directas a Objetos Inseguros
  • Control de Acceso a Nivel de Función Ausente
  • Referencia a Objetos Indirecta

PortSwigger Web Security Academy

Laboratorios gratuitos basados en navegador con dificultad creciente. No necesitas infraestructura — todo funciona en el navegador.

Bug Bounty en la Práctica

HackerOne tiene programas públicos con scope favorable para IDOR. Comienza con programas marcados como “Bueno para Principiantes” y plataformas SaaS con múltiples tipos de cuentas de usuario.

Un VPS de $6/mes en Vultr o DigitalOcean es suficiente para ejecutar múltiples contenedores Docker vulnerables simultáneamente y practicar el flujo completo de enumeración.

Resumen de Herramientas

HerramientaCaso de Uso
Burp Suite ProIntercepción principal, extensión Authorize, Param Miner
Authorize (Burp)Pruebas automatizadas de IDOR con múltiples sesiones
Param Miner (Burp)Descubrimiento de parámetros ocultos
ffufEnumeración de IDOR / fuzzing de IDs
NucleiEscaneo automatizado con plantillas de IDOR
OWASP ZAPAlternativa gratuita a Burp para pruebas de IDOR
Postman/InsomniaPruebas manuales de IDOR en APIs
jwt_toolManipulación de claims JWT para IDOR vía token

Lista de Verificación para Pruebas de IDOR

Antes de cerrar cualquier engagement de aplicación web, revisa esto:

  • Enumerados todos los endpoints que aceptan IDs de objetos (URL, cuerpo, encabezados)
  • Probado con dos cuentas del mismo nivel de privilegio (horizontal)
  • Probado con cuentas en diferentes niveles de privilegio (vertical)
  • Probados todos los métodos HTTP: GET, POST, PUT, PATCH, DELETE
  • Verificados campos de formulario ocultos y parámetros de cuerpo JSON
  • Decodificados y probados IDs codificados (base64, hex, claims JWT)
  • Probada toda la funcionalidad de exportación/descarga
  • Verificados cuerpos de respuesta de API en busca de IDs filtrados de otros usuarios
  • Intentadas cadenas de IDOR (IDOR → ATO, IDOR → escalación de privilegios)
  • Documentado el radio de daño (cuántos registros están expuestos)

Resumen

IDOR es simple en concepto, brutal en impacto, y sigue presente en la mayoría de las aplicaciones web y APIs probadas en 2026. No requiere herramientas especiales, no requiere payloads exóticos — solo pruebas sistemáticas con dos cuentas y atención a cada referencia de objeto que la aplicación expone.

La metodología:

  1. Mapea todas las referencias a objetos en la aplicación
  2. Prueba el acceso con una segunda cuenta del mismo nivel de privilegio
  3. Prueba operaciones que cambian estado (escritura, eliminación, modificación)
  4. Busca oportunidades de escalación de privilegios
  5. Encadena con otras vulnerabilidades para maximizar el impacto

Si haces bug bounty o evaluaciones de red team, IDOR debería ser una de las primeras cosas que pruebas sistemáticamente — antes de pasar horas en XSS o cadenas de inyección complejas. La relación recompensa-esfuerzo es difícil de superar.

¿Necesitas informes de pentest y entregables de red team que realmente se vean profesionales? CipherWrite se encarga de la escritura técnica para equipos de seguridad — informes, whitepapers y documentación para clientes.