IDOR: como testar se um utilizador vê os dados de outro

IDOR (referência direta insegura a objetos) é a falha em que alguém acede aos dados de outro utilizador 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, entra com dois utilizadores e tenta abrir os recursos de um com a sessão do outro.

Porque é que isto importa tanto?

A OWASP coloca o controlo de acesso quebrado em primeiro lugar no Top 10 de 2025, e o IDOR é um dos exemplos que dá. É um erro fácil de não notar: a app funciona na demonstração, porque nela cada pessoa só clica nos seus 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);
}

Há duas verificações em falta: quem está a pedir, e se essa pessoa é dona da fatura. Mesmo com login na interface, qualquer pessoa pode chamar este endereço diretamente.

Como corrijo?

Confirma a sessão no servidor e inclui o dono na própria consulta. O id do utilizador tem de vir da sessão, nunca do pedido:

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: usa o que a tua stack oferecer. Devolver 404 em vez de 403 também evita confirmar que o recurso existe.

Como testo a minha app?

Faz estes testes só na tua app, de preferência num ambiente de teste.

1. Cria dois utilizadores de teste, A e B, cada um com dados próprios.
2. Com a sessão de A, abre um recurso de A e copia o endereço e o pedido nas ferramentas de programador.
3. Com a sessão de B, repete esse pedido.
4. Sem sessão, repete-o outra vez.
5. Faz 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 os conseguirem alterar, tens um IDOR.

Onde devo procurar?

• Rotas de API e Server Actions que recebem um id.
• Ficheiros e faturas com links diretos.
• Exportações, como PDF ou CSV.
• Funções de administração sem verificação de papel.
• Identificadores no corpo do pedido, 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 partilhados, registos e respostas de outras rotas. Usa-os se quiseres, mas mantém a verificação de dono.

Se usas Supabase, as regras de RLS ajudam a impor esta verificação na própria base de dados. Lê o guia sobre Supabase RLS.

Fontes

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