IDOR — Insecure Direct Object Reference — es el bug engañosamente simple detrás de gran parte de las filtraciones reales. El ataque entero es: cambiá un número en la URL, obtené los datos de otro. Sin exploit, sin herramientas — solo curiosidad y un control de permisos que falta.

Qué es IDOR

Una app expone una referencia a un objeto interno — normalmente un ID de base de datos — en la URL o el body. El IDOR ocurre cuando el servidor devuelve ese objeto sin verificar que quien lo pide tenga permiso.

    # Logueado como usuario A, viendo tu propia orden:
GET /api/orders/1001   → 200 OK (tu orden)
# Cambiás el ID...
GET /api/orders/1002   → 200 OK (la orden de otro)  ← IDOR

El IDOR es la instancia más común de Broken Access Control (riesgo #1 de OWASP); en APIs se llama BOLA, el #1 del OWASP API Security Top 10.

Por qué los "IDs no adivinables" no lo arreglan

Mito común: "usamos UUIDs, no hay IDOR". Los UUID dificultan la enumeración, pero no son control de acceso. Los IDs se filtran (emails, referrers, links compartidos). En cuanto un atacante tiene un ID válido, una app sin verificación entrega los datos. La oscuridad no es autorización.

Cómo prevenir IDOR

    // Vulnerable: buscar y (olvidar) verificar
const order = await db.order.findUnique({ where: { id: params.id } })

// Seguro: limitar al dueño
const order = await db.order.findFirst({
  where: { id: params.id, userId: session.user.id },
})
if (!order) return new Response(null, { status: 404 })

Centralizá la autorización, usá RLS si el cliente consulta la DB directo, y testealo: logueate como dos usuarios e intentá acceder a los recursos del otro (debe dar 403/404).

Encontrá tus IDOR antes que otro

El IDOR es invisible para quien lo construyó — la app anda bien con tus datos. Nurbak escanea tu app por autorización rota a nivel de objeto y el resto del checklist de seguridad de APIs.

Artículos relacionados