IDOR — Insecure Direct Object Reference — é o bug enganosamente simples por trás de boa parte dos vazamentos reais. O ataque inteiro é: mude um número na URL, obtenha os dados de outro. Sem exploit, sem ferramentas — só curiosidade e um controle de permissão que falta.

O que é IDOR

Uma app expõe uma referência a um objeto interno — normalmente um ID de banco — na URL ou no body. O IDOR ocorre quando o servidor retorna esse objeto sem verificar que quem pede tem permissão.

    # Logado como usuário A, vendo seu próprio pedido:
GET /api/orders/1001   → 200 OK (seu pedido)
# Você muda o ID...
GET /api/orders/1002   → 200 OK (o pedido de outro)  ← IDOR

O IDOR é a instância mais comum de Broken Access Control (risco #1 do OWASP); em APIs se chama BOLA, o #1 do OWASP API Security Top 10.

Por que "IDs não adivinháveis" não resolvem

Mito comum: "usamos UUIDs, não há IDOR". UUIDs dificultam a enumeração, mas não são controle de acesso. IDs vazam (emails, referrers, links). Assim que um atacante tem um ID válido, uma app sem verificação entrega os dados. Obscuridade não é autorização.

Como prevenir IDOR

    // Vulnerável: buscar e (esquecer) verificar
const order = await db.order.findUnique({ where: { id: params.id } })

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

Centralize a autorização, use RLS se o cliente consulta o banco direto, e teste: faça login como dois usuários e tente acessar os recursos do outro (deve dar 403/404).

Ache seus IDOR antes de outro

O IDOR é invisível para quem o construiu — a app funciona bem com seus dados. O Nurbak escaneia sua app por autorização quebrada em nível de objeto e o resto do checklist de segurança de APIs.

Artigos relacionados