Detectar un IDOR no consiste en cambiar un número en una petición y dar el hallazgo por cerrado. El valor real de la validación aparece cuando demuestras qué recurso queda expuesto, qué controles fallan, qué perfiles pueden explotarlo y cuál es el impacto efectivo sobre datos, operaciones o privilegios.
En entornos reales, muchos falsos positivos nacen de validaciones incompletas. También ocurre lo contrario: vulnerabilidades con un impacto alto pasan desapercibidas porque se prueban sin entender la lógica funcional.
1. Delimitar el contexto antes de tocar parámetros
Lo primero es identificar dónde existe una referencia directa a objetos internos. Puede aparecer en rutas, parámetros GET, cuerpos JSON, identificadores en GraphQL, valores ocultos del frontend o referencias devueltas por una API tras una búsqueda legítima.
- Identifica el recurso: usuario, pedido, ticket, documento, factura, expediente.
- Comprueba si el identificador es secuencial, predecible o reutilizable.
- Relaciona el recurso con el rol autenticado y con las reglas de autorización esperadas.
2. Capturar una petición legítima y entender su función
Antes de mutar el identificador, necesitas entender qué hace exactamente la petición original. No es lo mismo una lectura de perfil que una operación de descarga, edición, aprobación o borrado. El impacto depende de la acción.
GET /api/v2/customers/1042/invoices/8831 HTTP/1.1
Host: target.local
Authorization: Bearer eyJhbGciOi...
Accept: application/jsonLa pregunta no es solo si el servidor devuelve algo distinto al cambiar el identificador. La pregunta correcta es si ese objeto debería estar autorizado para ese usuario concreto en ese flujo concreto.
3. Mutar el identificador con criterio
Cambia el objeto por otro del mismo tipo y observa respuesta, estructura, códigos HTTP, mensajes de error y campos sensibles. Después repite la prueba con varios recursos: uno inexistente, uno ajeno y uno de otro rol o tenant.
Un IDOR bien validado no se apoya en una sola respuesta exitosa. Se apoya en un patrón consistente de ausencia de control.
Conviene distinguir entre cuatro escenarios: acceso total, acceso parcial, metadatos expuestos y operación permitida sin visualización previa. A veces el servidor oculta la vista, pero permite descargar, modificar o borrar el recurso.
4. Medir impacto real
Una vez confirmado el fallo, documenta el impacto por dimensión: confidencialidad, integridad, trazabilidad y posible escalada lateral. Un IDOR sobre perfiles públicos no equivale a un IDOR sobre facturas, historiales, expedientes o paneles administrativos.
- Datos expuestos: personales, financieros, operativos, internos.
- Capacidad de modificación: cambios de estado, edición, borrado, reasignación.
- Alcance: horizontal, vertical, cross-tenant, acceso masivo o automatizable.
5. Preparar evidencias para el informe
La evidencia debe permitir reproducir el hallazgo sin ruido. Incluye petición base, petición alterada, respuesta, recurso accedido, rol usado y explicación del control ausente. Si el objeto pertenece a otro usuario o cliente, indícalo explícitamente sin exponer más datos de los necesarios en la versión final del informe.
La remediación tampoco debe quedarse en “validar permisos”. Lo correcto es exigir comprobación server-side del acceso al objeto en cada operación, desacoplar el control del frontend y revisar los endpoints equivalentes que compartan la misma lógica de autorización.
