Saiba o que significa IDOR (Insecure Direct Object Reference), como os invasores o exploram e como os desenvolvedores podem evitar vulnerabilidades de IDOR usando práticas de codificação seguras, padrões de controle de acesso e plataformas de teste automatizadas.
O que é o IDOR?
O IDOR (Insecure Direct Object Reference) é uma vulnerabilidade de segurança em que um aplicativo expõe identificadores de objetos internos, como IDs de usuários, números de pedidos ou nomes de arquivos, sem verificar se o solicitante está autorizado a acessar esse objeto. Ao alterar um parâmetro em uma chamada de URL ou API, um invasor pode visualizar, modificar ou excluir dados aos quais não deveria ter acesso.
Entendendo a IDOR: por que essa vulnerabilidade ainda é importante
A IDOR pertence à ampla categoria de Controle de acesso quebradoque a OWASP classificou como um dos riscos mais críticos de segurança na Web durante anos. O perigo do IDOR está em sua simplicidade: o invasor não precisa de técnicas avançadas de exploração, codificação de carga útil ou escalonamento de privilégios. Um único parâmetro alterado, geralmente apenas um número, pode expor informações privadas.
Um padrão vulnerável típico é o seguinte:
bash
/api/user/profile?id=1002
Se o aplicativo não verificar a propriedade ou a autorização, alterar a ID para 1003 pode revelar os dados de outro usuário.
Os aplicativos modernos, especialmente os que envolvem APIs, microsserviços ou clientes móveis, geralmente dependem muito do acesso parametrizado a objetos. Essa arquitetura, embora rápida e flexível, pode facilmente introduzir a IDOR quando as verificações de autorização são inconsistentes ou ausentes.
CVE-2025-13526: um caso real de IDOR na natureza
Um dos exemplos mais recentes de alta visibilidade da exploração da IDOR é CVE-2025-13526que afeta o popular plug-in do WordPress OneClick Chat to Order (versões ≤ 1.0.8).
- A vulnerabilidade reside na seção
wa_order_thank_you_overridefunção. O plug-in confia em uma funçãoorder_idda string de consulta do URL, sem verificar se a solicitação vem do proprietário legítimo do pedido. - Os invasores (mesmo os não autenticados) poderiam simplesmente manipular o
order_idno URL da página de agradecimento (por exemplo, alterandoorder_id=123456paraorder_id=123455) e recuperar detalhes de pedidos de outros clientes. Os dados expostos incluem nomes, endereços de e-mail, números de telefone, endereços de cobrança/remessa, itens e preços do pedido, metadados do método de pagamento. wiz.io+2Gowri Infosec+2 - Como os IDs dos pedidos eram sequenciais e previsíveis, a enumeração em massa tornou-se trivial, o que significa que um invasor ou um script automatizado poderia coletar milhares de pedidos em minutos. Médio+1
- A vulnerabilidade recebeu uma pontuação básica CVSS v3.1 de 7,5 (Alta), refletindo a facilidade de exploração (sem necessidade de autenticação) e a gravidade da exposição dos dados.
- O desenvolvedor corrigiu o problema na versão 1.0.9A atualização do site para a versão mais recente do sistema, implementando verificações de autorização adequadas para garantir que somente os proprietários legítimos (ou usuários autorizados) possam visualizar os dados do pedido. Os proprietários de sites foram instados a fazer a atualização imediatamente. Gowri Infosec+1
Essa violação no mundo real mostra que o IDOR não é um bug teórico ou legado - ele continua ativo, explorável e com consequências potencialmente graves para a privacidade e a conformidade.
Cenários comuns do mundo real em que ocorre a IDOR
O IDOR pode aparecer em qualquer sistema que faça referência a objetos internos por meio de entradas controladas pelo usuário. Veja abaixo os contextos comuns:
| Tipo de aplicativo | Exemplo de objeto | Por que ocorre a IDOR |
|---|---|---|
| Sistemas de contas | userId | Exposição direta de identificadores de usuários |
| Aplicativos de comércio eletrônico | orderId | Validação inadequada de propriedade |
| Gerenciamento de arquivos | fileId | Falta de controle de acesso aos arquivos |
| Plataformas de emissão de bilhetes | ticketId | Os usuários acessam os tíquetes de outros usuários |
| Aplicativos SaaS multilocatários | tenantId | Vazamentos de dados entre locatários |
Os invasores geralmente enumeram IDs previsíveis, tentam IDs sequenciais ou reproduzem solicitações autenticadas com parâmetros modificados.
Como os invasores exploram o IDOR (exemplos seguros e controlados)
Abaixo estão exemplos de ilustrações seguras mostrando padrões vulneráveis típicos e suas contrapartes seguras. Essas explorações não são prejudiciais; elas modelam erros comuns para ajudar os desenvolvedores a reconhecer padrões inseguros.
Exemplo 1: IDOR em Node.js / Express
javascript
// Exemplo vulnerável: confiar na ID fornecida pelo usuário
app.get('/api/user/profile', (req, res) => {
const userId = req.query.id;
db.users.findById(userId).then(user => {
res.json(user);
});
});
// ✅ Exemplo seguro: impor autorização
app.get('/api/user/profile', (req, res) => {
const authenticatedId = req.user.id;
db.users.findById(authenticatedId).then(user => {
Se (!user) return res.status(404).json({ error: "User not found" });
res.json({ id: user.id, email: user.email, role: user.role });
});
});
Exemplo 2: Um padrão comum em Python / Flask
python
#❌ Inseguro: sem validação de propriedade
@app.get("/invoice")
def get_invoice():
invoice_id = request.args.get("id")
return get_invoice_by_id(invoice_id)
#✅ Secure: verificação de permissão adicionada
@app.get("/invoice")
def get_invoice_secure():
invoice_id = request.args.get("id")
user_id = session["user_id"]
invoice = get_invoice_by_id(invoice_id)
se invoice.owner_id != user_id:
return {"error": "Unauthorized"}, 403
devolver fatura
Exemplo 3: Defesa combinada de back-end e front-end (Java + React)
Java (Spring Boot)
java
// ❌ Falta de verificação de autorização
@GetMapping("/orders")
public Order getOrder(@RequestParam String orderId) {
return orderRepository.findById(orderId);
}
// ✅ Implementação segura
@GetMapping("/orders")
público ResponseEntity getOrder(
@RequestParam String orderId,
Principal principal) {
Order order = orderRepository.findById(orderId);
Se (!order.getUser().equals(principal.getName())) {
return ResponseEntity.status(HttpStatus.FORBIDDEN)
.body(Collections.singletonMap("error", "Access denied"));
}
return ResponseEntity.ok(order);
}
Solicitação segura no lado do React
javascript
função assíncrona fetchOrder(orderId) {
const res = await fetch(/orders?orderId=${orderId}, {
cabeçalhos: { "Authorization": Bearer ${localStorage.getItem("token")} }
});
Se (!res.ok) lançar um novo erro ("Não autorizado ou não encontrado");
retornar res.json();
}
Detecção de vulnerabilidades do IDOR: Abordagens práticas para desenvolvedores
Encontrar a IDOR geralmente é mais difícil do que explorá-la. Ao contrário das vulnerabilidades de injeção, a IDOR nem sempre produz erros técnicos óbvios - seus sintomas são lógicos e comportamentais.
As técnicas comuns de detecção incluem:
- Fuzzing diferencial (teste de várias IDs)
- Teste de repetição (captura → modificação → repetição)
- Troca de função multiusuário
- Enumeração de parâmetros
Pseudocódigo de fuzzing seguro:
python
Exemplo simples de fuzzing seguro
ids = ["1001", "1002", "1003"]
para i em ids:
res = client.get(f"/api/user/profile?id={i}")
print(i, res.status_code, len(res.text))
Prevenção de IDOR: práticas recomendadas que os desenvolvedores devem seguir
A prevenção de IDOR não se trata de ofuscação - trata-se de autorizaçãoO desempenho do servidor foi consistente.
Nunca confie nos identificadores de objeto do cliente
Todos os parâmetros são modificáveis. Até mesmo IDs criptografadas podem ser adulteradas.
Aplicar autorização no lado do servidor em cada solicitação
Use modelos reconhecidos de controle de acesso:
- RBAC (Controle de acesso baseado em função)
- ABAC (Controle de acesso baseado em atributos)
- ACLs (Listas de controle de acesso)
- Política como código sistemas como OPA
Recursos de autoridade:
- OWASP: https://owasp.org
PortSwigger Web Security Academy: https://portswigger.net/web-security/access-control
Prefira identificadores não enumeráveis
Os UUIDs reduzem, mas não eliminam, o risco de IDOR.
Validar os limites dos locatários em ambientes com vários locatários
O IDOR entre locatários é uma das formas mais graves e onerosas.
Use uma camada de back-end para front-end (BFF)
Um BFF pode centralizar a lógica de autorização, reduzindo as inconsistências entre os clientes.
Exemplos avançados adicionais
Exemplo 4: API Go com falta de autorização
ir
// Manipulador vulnerável
func GetDocument(w http.ResponseWriter, r *http.Request) {
id := r.URL.Query().Get("id")
doc := db.FindDocument(id)
json.NewEncoder(w).Encode(doc)
}
// ✅ Com validação de propriedade
func GetDocumentSecure(w http.ResponseWriter, r *http.Request) {
id := r.URL.Query().Get("id")
user := r.Context().Value("user").(string)
doc := db.FindDocument(id)
if doc.Owner != user {
http.Error(w, "Unauthorized", http.StatusForbidden)
retorno
}
json.NewEncoder(w).Encode(doc)
}
Exemplo 5: pontos de extremidade GraphQL e autorização de objeto
javascript
// ❌ Resolvedor vulnerável
const resolvers = {
Query: {
order: (_, { id }) => db.getOrder(id),
}
};
// ✅ Resolvedor seguro com verificação de propriedade
const resolversSecure = {
Query: {
order: (_, { id }, context) => {
const order = db.getOrder(id);
Se (order.owner !== context.user.id) {
lançar um novo erro ("Acesso negado");
}
ordem de devolução;
}
}
};
Exemplo 6: Acesso seguro em Rust (Actix Web)
ferrugem
// ❌ Vulnerável
async fn get_ticket(path: web::Path) -> impl Responder {
let id = path.into_inner();
let ticket = db::find_ticket(&id);
web::Json(ticket)
}
// ✅ Versão segura
async fn get_ticket_secure(
path: web::Path,
usuário: LoggedInUser
) -> impl Responder {
let id = path.into_inner();
let ticket = db::find_ticket(&id);
if ticket.owner != user.id {
return HttpResponse::Forbidden().json("Acesso negado");
}
HttpResponse::Ok().json(ticket)
}
Automatizando a detecção de IDOR: Por que as ferramentas tradicionais têm dificuldades
A maioria dos scanners de vulnerabilidade tradicionais não consegue detectar a IDOR de forma confiável porque a IDOR exige duas coisas que os scanners tradicionalmente não conseguem fazer:
- Consciência da lógica de negócios
- Teste contextual com vários usuários
As ferramentas de varredura que dependem exclusivamente da detecção baseada em assinatura ou de solicitações de usuário único geralmente não detectam o IDOR por completo, especialmente em APIs.
Como a Penligent ajuda a identificar o IDOR automaticamente
É aqui que PenligenteA Penligent, uma plataforma de testes de penetração orientada por IA, oferece uma vantagem exclusiva. Ao contrário dos scanners convencionais, a Penligent realiza:
- Simulação automática para vários usuários
- Inferência de parâmetros entre objetos
- Reconhecimento inteligente de padrões de identificação
- Análise diferencial comportamental
- Fuzzing de IA que se adapta com base nas respostas observadas
Uma amostra da saída de detecção segura e anônima da Penligent:
vbnet
`Potencial IDOR detectado:Ponto final: /orders?id=1002Observed behavior:
- O usuário A recebeu o pedido #1003 (de propriedade do usuário B) Risco: acesso não autorizado aos dados de outro usuário`
Esse tipo de insight é difícil de obter apenas com ferramentas estáticas ou revisão manual.
Reduzindo os riscos de IDOR em CI/CD com a Penligent
A Penligent se integra naturalmente aos pipelines de CI/CD e oferece cobertura contínua:
- Descoberta automática de API e rota
- Inferência de matriz de permissão em tempo real
- Varredura de ambientes de preparação e de produção
- Geração automática de sequências de PoC seguras e reproduzíveis
Isso reduz:
- Pontos cegos da lógica de negócios
- Exposição a vários locatários
- Riscos regulatórios (GDPR, HIPAA, SOC2)
Conclusão: A IDOR é simples, mas devastadora - e evitável
A IDOR continua sendo uma das formas mais comuns e prejudiciais de vulnerabilidades de controle de acesso. Como ela se oculta na lógica de negócios, muitas vezes passa despercebida pelas ferramentas tradicionais. Ao aplicar verificações de autorização consistentes, usar identificadores não previsíveis, validar limites de locatários e adotar plataformas de testes automatizados como a Penligent, as organizações podem reduzir drasticamente o risco de exposição de dados em grande escala.
A IDOR não pode ser totalmente eliminada por acaso ou por boas intenções - ela exige controle de acesso estruturado, princípios de engenharia consistentes e testes contínuos.
