/ TL;DR

IDOR — Insecure Direct Object Reference — é o achado mais comum em apps B2B em 2026. Custa uma linha de código introduzir e milhões para o cliente descobrir. Este guia mostra como detectar, corrigir e testar sistematicamente.

IDOR é o achado #1 no OWASP Top 10 2026 (Broken Access Control). É também o achado que a Varredura mais encontra em apps B2B brasileiros. E é o mais fácil de introduzir sem perceber.

O padrão

Rota GET /api/orders/12345 retorna o pedido 12345. Sem verificar se quem pediu é dono do pedido. Qualquer usuário logado busca qualquer pedido.

Em código:

app.get('/api/orders/:id', async (req, res) => {
  const order = await db.orders.findById(req.params.id);
  res.json(order);
});

Falta a cláusula AND user_id = ?.

Onde nasce

  • Rota nova criada rapidamente, sem middleware de autorização.
  • Refactor que mudou o padrão de findOne({id, user_id}) para findById(id).
  • Endpoint interno "só admin usa" que virou público.
  • Feature de "compartilhar" que gera URL sem token.

Como detectar

Se você é o dono, logue como usuário A, capture o ID de um recurso. Logue como usuário B, tente acessar com o ID de A. Se responder com dado, tem IDOR.

Faça isso para: pedidos, faturas, uploads, mensagens, projetos, times, membros, exports, anexos, comentários, notificações.

Como corrigir sem refatorar tudo

Introduza um authorize() middleware por rota:

async function authorize(req, res, next) {
  const resource = await db.orders.findOne({ id: req.params.id, user_id: req.user.id });
  if (!resource) return res.status(404).end();
  req.resource = resource;
  next();
}

app.get('/api/orders/:id', authorize, (req, res) => res.json(req.resource));

O 404 é intencional — não vaza existência.

Impacto real

Uma B2B com 500 clientes brasileiros. IDOR em endpoint de invoice. Cliente A pediu invoice de cliente B por erro. Cliente B era concorrente. Vazou preço interno. Deu processo.

O bug foi 3 caracteres a menos no código. O custo foi R$ 400k em correção, comunicação e retenção.

Como testar sistematicamente

Escreva um script:

Para cada rota /api/X/:id do backend:
  Cria usuário A e B.
  A cria recurso, obtém id.
  B tenta GET /api/X/{id de A}.
  Espera 404 ou 403.

Rode no CI. Se um caso passar sem 404/403, PR é bloqueado.

Anti-padrão comum: UUID protege

Não. UUID torna adivinhação mais difícil, mas o atacante consegue via referrer, link compartilhado, log, cache do CDN.

Correção: UUID + autorização. Nunca UUID sozinho.

TL;DR

  • IDOR é a falha #1 em B2B em 2026.
  • Middleware authorize() por rota.
  • Teste automatizado com 2 usuários.
  • 404 em vez de 403 (não vaza existência).
  • UUID não substitui autorização.

A Varredura testa IDOR em todas rotas indexadas por ID. Rodar agora.

EV

Equipe Varredura

Time de pesquisa de segurança · Varredura

Sua app em produção passa por essa análise?

Rode uma varredura autônoma em ~60 segundos. Sem cadastro.

Analisar minha aplicação →