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})parafindById(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.
Sua app em produção passa por essa análise?
Rode uma varredura autônoma em ~60 segundos. Sem cadastro.