Teste IDOR para vulnerabilidades de visualização por link compartilhado

Como “copy-link viewing” aparece em apps reais

“Copy-link viewing” é quando alguém consegue abrir uma página no seu app apenas colando um link, mesmo sem ter autorização para ver aquele registro. Isso aparece em faturas, projetos, tickets de suporte, documentos compartilhados e às vezes em telas de admin que têm um botão “Copy link”.

O ponto de risco não é a funcionalidade de compartilhamento. O risco é o app carregar dados baseado apenas no que há na URL (como um ID) sem verificar se o usuário atual tem permissão para ver aquilo.

Um exemplo comum: um cliente copia o link da sua fatura e manda para o contador. O contador clica enquanto está logado na própria conta (ou nem está logado) e ainda assim vê a fatura. Pior: se a URL é /invoice/1042, mudar para /invoice/1043 mostra a fatura de outro cliente.

Muitas equipes assumem que estão seguras porque o link “parece aleatório” (uma string longa). Mas aleatoriedade não é permissão. Se o servidor não verificar o acesso toda vez, um link que parece aleatório ainda pode vazar dados por compartilhamento, encaminhamento, histórico do navegador, screenshots ou alguém reutilizando uma mensagem antiga.

Pessoas costumam relatar isso como comportamento “estranho”, tipo:

• “Cliquei em um link e vi o nome ou e-mail de outra pessoa.”
• “Consigo abrir um link antigo em uma janela privada e ele ainda funciona.”
• “Meu colega consegue ver meu registro sem ter sido adicionado.”
• “O suporte pediu um link, e agora qualquer um com ele pode ver o ticket.”

Este guia explica um teste simples de IDOR com duas contas para identificar insecure direct object access sem ler código. Você vai aprender o que tentar, o que conta como vazamento e como capturar provas claras para um desenvolvedor corrigir rápido.

IDOR explicado sem jargão de segurança

IDOR é a sigla para insecure direct object access. Em termos simples, significa que você pode trocar um ID em um link (ou requisição) e ver os dados de outra pessoa. O app está retornando um objeto real (um projeto, fatura, mensagem ou arquivo) baseado principalmente em um identificador, sem checar corretamente se você tem permissão para vê-lo.

Um padrão típico: você abre uma página e a URL contém um ID do item. Se você troca esse ID por outro e o app mostra o item de outra pessoa, isso é um bug de autorização.

A distinção chave é simples:

• Autenticação responde: “Você está logado?”
• Autorização responde: “Você tem permissão para acessar este item específico?”

Muitos apps acertam a primeira e ainda falham na segunda. Estar logado só prova que você é um usuário. Não prova que deve ver qualquer registro.

Um modelo mental útil:

• Object: a coisa que você tenta acessar (documento, pedido, ticket)
• Owner: o usuário ou time a que o objeto pertence
• Permission check: o app deve confirmar, toda vez, que o usuário atual tem acesso a esse objeto

Se essa checagem de permissão estiver ausente ou frouxa, o comportamento de “copy link” vira exposição acidental de dados.

Onde bugs de IDOR se escondem com mais frequência

Problemas de IDOR não aparecem em páginas de marketing. Eles aparecem nas partes de “trabalho real” do app, onde registros carregam por ID e existem ações como download ou export.

Páginas que carregam um registro por ID

Isto é comum porque a URL muitas vezes mapeia exatamente um registro:

• Faturas, recibos, propostas, relatórios, PDFs assinados
• Projetos, tarefas, tickets, notas, comentários
• Perfis, páginas de cobrança, configurações, telas de admin de time ou workspace
• Anexos, exports, downloads de imagens/arquivos
• Páginas de “share” que parecem públicas mas deveriam ser privadas

Um teste rápido: se a página muda completamente ao alterar apenas um número ou um token no endereço, pode estar confiando demais no ID.

APIs em segundo plano que ainda vazam

Muitos apps carregam dados via API em segundo plano. Às vezes a tela está protegida, mas o endpoint da API não está.

Exemplo: a página do ticket está bloqueada, mas um endpoint como “getTicket?id=123” ainda retorna detalhes do ticket para qualquer usuário logado.

Se você pegou um app gerado por IA (Lovable, Bolt, v0, Cursor, Replit), fique ainda mais atento. O controle de acesso costuma ser inconsistente entre rotas, especialmente para downloads, exports e endpoints “laterais”.

Configure o teste de duas contas com segurança

Você está imitando o que um usuário real faria com um link compartilhado. Mantenha-o seguro: contas de usuário normais, dados apenas de teste, sessões separadas.

1. Crie dois usuários regulares: Conta A e Conta B. Não dê a nenhum deles privilégios de admin ou papéis de “ver tudo”.
2. Se seu app tem workspaces, orgs ou times, coloque A e B em diferentes conjuntos.
3. Com a Conta A, crie 1-2 itens de teste óbvios que você reconhecerá depois (por exemplo, um doc intitulado “IDOR Test - A” ou uma fatura dummy de $1). Use dados falsos.
4. Anote o que deveria acontecer. Por exemplo: “Apenas o proprietário pode ver” vs “Qualquer um com o link pode ver, mas não editar.”
5. Separe as sessões para que os logins não se misturem:

• Conta A em uma janela normal do navegador
• Conta B em uma janela anônima/privada (ou em outro perfil de navegador)

Passo a passo: o teste de copy-link viewing

O teste é direto: a Conta A vê um item, depois a Conta B tenta abrir o mesmo link copiado.

1. Faça login como Conta A e abra o item alvo (fatura, projeto, ticket, documento, thread de mensagem).
2. Copie a URL completa da barra de endereços. Observe qualquer coisa que pareça um identificador (número, string tipo UUID, slug).
3. Na sessão separada, faça login como Conta B.
4. Cole o link exato e carregue a página.
5. Se algo carregar, tente uma pequena variação mudando apenas o identificador e recarregue.

Depois de testar a visualização, repita o mesmo padrão nas “portas laterais” que costumam vazar mais que a tela principal. Não faça nada destrutivo.

• Se houver uma rota de edição, veja se a Conta B consegue carregar o formulário de edição.
• Se houver ação de download/export (PDF, CSV, anexo), veja se o arquivo é retornado.
• Se a página carregar, preste atenção em quais dados extras aparecem (nomes, e-mails, valores, notas internas).

Se a Conta B conseguir ver qualquer coisa real, mesmo um preview ou metadado, trate como um bug de autorização.

Como interpretar os resultados (e o que conta como vazamento)

Não fique só esperando um grande “consigo ver tudo”. Muitos problemas reais vazam apenas o suficiente para causar dano.

Que resultados significam o quê

Compare o que a Conta B consegue com o link da Conta A:

• Full access: B vê o mesmo conteúdo que A. Vazamento claro.
• Partial data: B não usa a página normalmente, mas ainda vê nomes, valores, mensagens, anexos. Ainda é vazamento.
• Metadata only: B descobre que o registro existe (título, dono, timestamps). Ainda é vazamento.
• Proper denial: B é bloqueado de forma consistente e nenhum dado privado aparece.

Um “404 Not Found” nem sempre é seguro. Se alguns IDs retornam 404 enquanto outros retornam erro diferente, página diferente ou tempo de resposta diferente, você pode estar vazando quais registros existem.

Fique atento a vazamentos silenciosos

Alguns apps escondem a UI mas ainda carregam os dados. A página pode parecer em branco, mas a resposta (ou um arquivo baixado) contém informações privadas.

Também repare em confusões de permissão: a visualização é bloqueada, mas a Conta B ainda consegue editar, deletar, baixar ou exportar.

Teste tanto em desktop quanto em mobile. Visualizações móveis às vezes usam endpoints diferentes.

Capturar evidência que um desenvolvedor possa usar

Um bom relatório economiza horas.

Colete:

• A URL exata usada (caminho completo e qualquer ID visível)
• Data/hora, ambiente (produção vs staging) e navegador/dispositivo
• Provas das duas contas (screenshots ou uma pequena gravação)

Ao capturar screenshots, inclua algo que prove qual conta está logada (ícone de perfil, e-mail, nome da conta). Caso contrário você ouvirá “não conseguimos reproduzir”.

Escreva a regra que deveria ter sido aplicada, em linguagem simples:

• “A Conta B só deve ver suas próprias faturas.”
• “Apenas membros convidados do projeto podem ver este documento.”
• “Apenas remetente e destinatário podem ler esta conversa.”

Depois liste exatamente o que foi exposto (nomes, e-mails, endereços, valores, notas, anexos). Use dados de teste falsos e inofensivos.

Checklist rápido: um scan de IDOR em 5 minutos

Use duas contas regulares (sem admin). Escolha alguns tipos de item que deveriam ser privados entre usuários.

• Confirme que as duas contas têm a mesma função e permissões.
• Teste pelo menos três tipos de item (por exemplo: um documento, um arquivo enviado e uma página de cobrança).
• Para cada tipo, teste mais que “visualizar” (editar/carregar formulário, baixar/exportar).
• Faça uma mudança “adivinhável” (por exemplo, /items/104 para /items/105, ou troque um slug legível).
• Verifique comportamento de negação: acesso não autorizado e IDs inválidos devem falhar de forma segura e consistente.

Também tente abrir o link deslogado em uma janela privada. Páginas privadas não devem mostrar conteúdo apenas porque alguém tem a URL.

Erros comuns de teste que fazem você perder o bug

Equipes costumam rodar isso uma vez, não ver nada óbvio e seguir em frente. Alguns padrões escondem o problema rotineiramente.

• Testar duas contas no mesmo workspace ou org (o bug geralmente aparece entre orgs).
• Confundir links de “compartilhar” reais (acessíveis intencionalmente) com links privados (que ainda devem exigir a conta certa).
• Assumir que IDs longos são seguros. Se o servidor não checar permissão, qualquer ID válido basta.
• Verificar apenas o que a UI mostra, não downloads/exports ou dados em segundo plano.
• Parar depois de uma página. Telas similares frequentemente usam regras diferentes.

Um método prático: teste a página de detalhe, o endpoint de download/export e qualquer visualização relacionada (atividade/comentários) para o mesmo objeto.

Um exemplo simples para comparar com o seu app

Imagine um portal de clientes onde cada cliente vê suas faturas. Na Conta A, abra uma fatura e clique em “Copy link”.

Mude para a Conta B (outro cliente) e cole a mesma URL da fatura.

Se a Conta B consegue ver totais, itens da linha, nome do cliente ou baixar o PDF, isso é uma vulnerabilidade de copy-link viewing. O app está confiando no link (ou no ID nele) mais do que deveria confiar nas permissões do usuário logado.

O que deveria acontecer: o app bloqueia o acesso a menos que a Conta B tenha permissão para ver aquela fatura. Pode ser uma tela de acesso negado, um redirecionamento ou um pedido de login. Se o produto suporta compartilhamento, o link deve funcionar apenas quando foi explicitamente compartilhado e o compartilhamento deve ser revogável.

Ao reportar internamente, seja específico:

• Impacto: “Qualquer usuário logado pode ver faturas de outros clientes colando um link copiado.”
• Áreas afetadas: “Página de detalhe da fatura e download do PDF.”
• Repro: “Login como A, copiar link, login como B, colar link, observar dados/PDF carregando.”
• Dados de exemplo vistos: “Total da fatura $X, nome de cobrança, conteúdo do PDF.”

Como consertar e o que fazer depois

A correção que realmente funciona

Se o seu teste de duas contas mostra copy-link viewing, a correção quase nunca é na UI. A correção é no servidor: toda vez que o app lê ou altera um registro, deve confirmar que o usuário logado tem permissão para acessar aquele registro específico.

Não confie em botões escondidos, checagens no cliente ou IDs “inacreditáveis”. Se um usuário pode colar um link, mudar um ID e ver os dados de outra pessoa, a checagem de permissão está ausente ou incompleta.

O que aplicar em cada endpoint vulnerável:

• Exigir autenticação quando a página não for pública
• Verificar autorização para aquele objeto exato (proprietário, membro do workspace, papel)
• Negar por padrão
• Aplicar a mesma regra para leituras, escritas, exports e downloads
• Logar tentativas negadas para detectar abuso

Próximos passos

Depois que as mudanças forem deployadas, rode de novo o mesmo teste de duas contas nas mesmas páginas e downloads que você usou antes. Corrigir uma rota frequentemente deixa uma “porta lateral” aberta.

Se o app foi gerado rapidamente com ferramentas como Lovable, Bolt, v0, Cursor ou Replit, planeje tempo extra. Esses projetos frequentemente têm múltiplas rotas que tocam os mesmos dados.

Se quiser ajuda para confirmar o escopo e aplicar patches de autorização corretamente, FixMyMess (fixmymess.ai) se especializa em diagnosticar e corrigir codebases gerados por IA, incluindo bugs de autorização, endurecimento de segurança e preparação para deploy.