La mitigación de IDOR busca impedir que un usuario autenticado acceda, modifique o elimine objetos que pertenecen a otras personas mediante la manipulación de identificadores. Esta guía presenta controles de autorización en backend, ejemplos en PHP/PDO y Node.js/Express, y una validación posterior basada en una matriz de acceso.
Ficha de la remediación
ID01 de Referencia
SEC-BAC-01
CWE
CWE-639 (Authorization Bypass Through User-Controlled Key) / CWE-284 (Improper Access Control)
Severidad
Alta / Crítica
Descripción del fallo
Una vulnerabilidad IDOR (Insecure Direct Object Reference) ocurre cuando una aplicación utiliza una entrada provista por el usuario para acceder directamente a un objeto o recurso en la base de datos (por ejemplo, /api/invoice?id=1024 o /user/profile/55) sin validar si el usuario autenticado tiene permisos legítimos para acceder a dicho recurso.
Un atacante puede simplemente modificar el parámetro numérico o el identificador en la petición para leer, editar o eliminar registros pertenecientes a otros usuarios del sistema.
Alcance y prerrequisitos
Gestión de identidades y sesiones
Implementación de un sistema de gestión de identidades y sesiones (tokens JWT, cookies de sesión).
Acceso requerido
Acceso al código fuente backend donde se procesan las consultas a la base de datos y la lógica de negocio.
Impacto técnico y de negocio
Impacto técnico
La falta de autorización a nivel de objeto puede permitir la lectura, edición o eliminación de registros ajenos, aunque el atacante tenga una sesión válida con privilegios limitados.
Impacto de negocio
El acceso indebido a facturas, perfiles, órdenes o documentos puede comprometer la confidencialidad y la integridad de la información, afectar la confianza y generar impactos operativos, reputacionales o de cumplimiento.
Cómo implementar la mitigación de IDOR
La solución requiere implementar controles de acceso basados en el contexto de la sesión activa y no confiar únicamente en los parámetros enviados por el cliente. opcionalmente, se pueden utilizar identificadores no predecibles (UUIDs).
Remediación Principal: Validación de Pertenencia/Permisos en Backend
❌ Código Vulnerable (PHP / PDO):
// Consulta directa usando el ID enviado por el usuario sin verificar propiedad
$invoice_id = $_GET['id'];
$stmt = $pdo->prepare("SELECT * FROM invoices WHERE id = :id");
$stmt->execute(['id' => $invoice_id]);
$invoice = $stmt->fetch(); // Retorna la factura de CUALQUIER usuario✅ Código Remediado (PHP / PDO):
// Validar que el objeto pertenezca al usuario autenticado en la sesión
$user_id = $_SESSION['user_id'];
$invoice_id = $_GET['id'];
$stmt = $pdo->prepare("SELECT * FROM invoices WHERE id = :invoice_id AND user_id = :user_id");
$stmt->execute(['invoice_id' => $invoice_id, 'user_id' => $user_id]);
$invoice = $stmt->fetch();
if (!$invoice) {
http_response_code(403);
echo json_encode(["error" => "Acceso denegado o recurso no encontrado"]);
exit();
}Remediación en Frameworks Modernos (Uso de Políticas/Middleware)
Ejemplo en Node.js / Express (Con verificación explicita):
app.get('/api/orders/:orderId', async (req, res) => {
const { orderId } = req.params;
const currentUserId = req.user.id; // Obtenido del JWT/Sesión validada
const order = await Order.findOne({ _id: orderId });
// Verificación de autorización explícita
if (!order || order.userId !== currentUserId) {
return res.status(403).json({ error: 'No tiene permisos para ver esta orden' });
}
res.json(order);
});Medida Complementaria: Uso de UUIDs (Identificadores Unívocos Aleatorios)
En lugar de exponer IDs secuenciales (1, 2, 3), utiliza UUIDv4 (e43f1122-38a6-4b88-b219-91896a848a31). Aunque no reemplaza la validación de autorización en el servidor, dificulta la enumeración masiva por fuerza bruta.
Verificación posterior a la remediación
Pruebas de Control de Acceso (Matriz de Autorización)
- Inicia sesión con el Usuario A y solicita un recurso propio (ej.
/api/documents/101). - Inicia sesión con el Usuario B y anota su ID de recurso (ej.
/api/documents/102). - Con la sesión del Usuario A, intenta acceder a
/api/documents/102.
| Estado | Comportamiento observado o esperado |
|---|---|
| Comportamiento Vulnerable | El Usuario A puede ver el documento 102 del Usuario B (Respuesta 200 OK). |
| Comportamiento Remediado | La aplicación retorna un código de error 403 Forbidden o 404 Not Found. |
Riesgos residuales y limitaciones
Los UUIDs no sustituyen la autorización
El documento establece que los identificadores no predecibles dificultan la enumeración, pero no reemplazan la validación de permisos en el servidor.
Rollback no suministrado
El documento fuente no incluye un procedimiento de reversión. Cualquier rollback debe definirse y probarse de acuerdo con la arquitectura, el modelo de autorización y el proceso de despliegue de la aplicación.
Recomendaciones complementarias
La mitigación de IDOR debe aplicarse en cada operación sobre objetos —consulta, creación, actualización, descarga y eliminación— y no solo en las rutas usadas como ejemplo.
Centralizar las políticas
Use políticas, middleware o funciones de autorización reutilizables para reducir diferencias de implementación entre endpoints y operaciones.
Ampliar la matriz de pruebas
Incluya distintos roles, organizaciones, estados del recurso y métodos HTTP, y compruebe tanto accesos horizontales como escalamiento vertical de privilegios.
Registrar intentos denegados
Monitoree patrones de enumeración y accesos rechazados sin revelar en la respuesta si un objeto ajeno existe o cuáles son sus atributos.
¿Cómo puede apoyar Password?
Password Consulting Services puede acompañar la identificación y validación de fallas IDOR mediante Pentesting Avanzado y pruebas de código SAST/DAST. El objetivo es evaluar la autorización a nivel de objeto, verificar la eficacia de los controles implementados y fortalecer el ciclo de desarrollo seguro. También puede consultar otras guías de remediación relacionadas con el control de acceso.
Valide los controles de acceso de sus aplicaciones
Conozca cómo Password puede acompañar la evaluación técnica de autorizaciones y la validación posterior de la remediación.
Solicitar diagnósticoPreguntas frecuentes
¿Qué diferencia existe entre autenticación y autorización frente a IDOR?
La autenticación confirma quién es el usuario; la autorización determina qué objetos y acciones puede utilizar. Una sesión válida no debe permitir acceso automático a cualquier identificador recibido por la aplicación.
¿Cambiar identificadores secuenciales por UUID elimina IDOR?
No. Los UUID dificultan la enumeración, pero cada solicitud debe validar en el servidor que el usuario autenticado tenga permisos sobre el objeto solicitado.
¿Es preferible responder 403 Forbidden o 404 Not Found?
El documento contempla ambos resultados como comportamiento remediado. La elección debe ser consistente con la política de respuestas de la aplicación y evitar revelar innecesariamente la existencia de recursos ajenos.
¿Cómo comprobar que la mitigación de IDOR quedó aplicada?
Construya una matriz con al menos dos usuarios y recursos distintos, intente acceder al objeto ajeno desde la sesión incorrecta y confirme que la aplicación responda 403 o 404 sin entregar el contenido.
