IDOR

IDOR (Insecure Direct Object Reference, ou referência direta insegura a objeto) é uma vulnerabilidade em que a aplicação usa um identificador vindo da requisição, como /api/orders/1043, para buscar um registro, mas nunca verifica se o usuário logado tem permissão para acessar aquele registro. Troque o ID para 1044 e você recebe o pedido de outra pessoa. Ela se enquadra em A01 Broken Access Control no OWASP Top 10 2021, e o OWASP API Security Top 10 chama o mesmo problema de Broken Object Level Authorization (BOLA).

Exemplo

A Alice está logada e vê o seu pedido:

GET /api/orders/1043
Authorization: Bearer <alice-token>

Ela troca o número:

GET /api/orders/1044
Authorization: Bearer <alice-token>

Se a resposta for 200 com o endereço e os itens do Bob, o endpoint autentica o usuário, mas não autoriza o acesso àquele objeto específico. UUIDs difíceis de adivinhar dificultam o palpite, mas não corrigem a falha; os IDs vazam por URLs, logs e links compartilhados.

O que o tester verifica

Crie dois usuários de teste, cada um com seus próprios dados, e depois use as credenciais do usuário A contra os objetos do usuário B em todos os endpoints e métodos: leitura, atualização, exclusão e rotas aninhadas como /users/{id}/invoices. Isso é fácil de automatizar. No Playwright:

import { test, expect, request } from '@playwright/test';

test("Alice cannot read Bob's order", async () => {
  const alice = await request.newContext({
    baseURL: process.env.API_URL,
    extraHTTPHeaders: { Authorization: `Bearer ${process.env.ALICE_TOKEN}` },
  });
  const res = await alice.get(`/api/orders/${process.env.BOB_ORDER_ID}`);
  expect([403, 404]).toContain(res.status());
  await alice.dispose();
});

Tanto 403 quanto 404 são aceitáveis; muitas APIs retornam 404 para nem sequer confirmar que o registro existe. Verifique também:

• IDs no corpo da requisição e na query string, não só no path.
• Operações de escrita, em que um IDOR permite que um usuário altere ou apague dados.
• Endpoints de operações em lote e de exportação que aceitam listas de IDs.
• Fronteiras entre tenants em sistemas multi-tenant.

Por que ele passa despercebido

Os testes funcionais normalmente fazem login com um usuário e usam os dados desse próprio usuário, então a verificação de autorização nunca é exercitada. O IDOR é encontrado perguntando, em cada endpoint, “e se este ID pertencesse a outra pessoa?”. Só execute esses testes em sistemas que você tem autorização para testar.