IDOR: como testar se um usuário vê os dados de outro

IDOR (referência direta insegura a objetos) é a falha em que alguém acessa os dados de outro usuário só por mudar um identificador, como trocar /faturas/1042 por /faturas/1043. Acontece quando o servidor confirma que há sessão, mas não confirma de quem são os dados. Para testar, entre com dois usuários e tente abrir os recursos de um com a sessão do outro.

Por que isso importa tanto?

A OWASP coloca o controle de acesso quebrado em primeiro lugar no Top 10 de 2025, e o IDOR é um dos exemplos que ela dá. É um erro fácil de não notar: o app funciona na demonstração, porque nela cada pessoa só clica nos próprios dados.

Como é uma rota vulnerável?

Esta rota devolve a fatura a quem tiver o id:

export async function GET(_: Request, { params }: { params: Promise<{ id: string }> }) {
  const { id } = await params;
  const fatura = await db.faturas.find(id);
  return Response.json(fatura);
}

Faltam duas verificações: quem está pedindo, e se essa pessoa é dona da fatura. Mesmo com login na interface, qualquer pessoa pode chamar esse endereço diretamente.

Como corrijo?

Confirme a sessão no servidor e inclua o dono na própria consulta. O id do usuário precisa vir da sessão, nunca da requisição:

export async function GET(_: Request, { params }: { params: Promise<{ id: string }> }) {
  const session = await getSession();
  if (!session) return new Response(null, { status: 401 });

  const { id } = await params;
  const fatura = await db.faturas.findFirst({ where: { id, userId: session.userId } });
  if (!fatura) return new Response(null, { status: 404 });

  return Response.json(fatura);
}

getSession e db são exemplos: use o que a sua stack oferecer. Devolver 404 em vez de 403 também evita confirmar que o recurso existe.

Como testo o meu app?

Faça estes testes só no seu app, de preferência em um ambiente de teste.

1. Crie dois usuários de teste, A e B, cada um com dados próprios.
2. Com a sessão de A, abra um recurso de A e copie o endereço e a requisição nas ferramentas de desenvolvedor.
3. Com a sessão de B, repita essa requisição.
4. Sem sessão, repita mais uma vez.
5. Faça o mesmo para alterar e apagar, não só para ler.

Se B ou um visitante sem sessão receberem os dados de A, ou conseguirem alterá-los, você tem um IDOR.

Onde devo procurar?

• Rotas de API e Server Actions que recebem um id.
• Arquivos e faturas com links diretos.
• Exportações, como PDF ou CSV.
• Funções de administração sem verificação de papel.
• Identificadores no corpo da requisição, como um userId que o cliente envia. O servidor nunca deve confiar nele.

IDs difíceis de adivinhar resolvem?

Não. Um UUID torna mais difícil adivinhar, mas não verifica nada. Os ids aparecem em links compartilhados, logs e respostas de outras rotas. Use-os se quiser, mas mantenha a verificação de dono.

Se você usa Supabase, as regras de RLS ajudam a impor essa verificação no próprio banco de dados. Leia o guia sobre Supabase RLS.

Fontes

• OWASP Top 10:2025, A01: controle de acesso quebrado