Guia Prático OWASP API Security Top 10: Como Identificar e Mitigar BOLA e Falhas de Autorização

Com a transição acelerada de arquiteturas monolíticas para ecossistemas distribuídos baseados em microsserviços, as APIs (Application Programming Interfaces) tornaram-se a principal superfície de ataque contra aplicações modernas.

Diferente das interfaces web tradicionais protegidas por WAFs e renderizadas em servidor, as APIs expõem diretamente a lógica de negócios, modelos de dados estruturados e parâmetros transacionais.

Neste guia técnico, dissecamos as vulnerabilidades mais prevalentes do OWASP API Security Top 10, com ênfase prática em BOLA (Broken Object Level Authorization), falhas de autenticação e vazamento excessivo de dados.

---

1. API1:2023 — Broken Object Level Authorization (BOLA / IDOR)

A falha BOLA (anteriormente conhecida como IDOR) continua sendo a vulnerabilidade mais crítica e comum em ecossistemas de APIs. Ela ocorre quando um endpoint recebe um identificador de objeto do cliente e não valida se o usuário autenticado tem permissão legal para acessar ou modificar aquele registro específico.

Cenário de Vulnerabilidade

Imagine um endpoint bancário para consulta de extrato:

GET /api/v1/accounts/849201/statement HTTP/1.1
Host: api.empresa.com.br
Authorization: Bearer [TOKEN_DO_USUARIO_A]

Se a aplicação apenas checar se [TOKEN_DO_USUARIO_A] é um token JWT válido, mas esquecer de verificar se o ID 849201 pertence àquele usuário, qualquer cliente poderá iterar sequencialmente sobre IDs numéricos ou UUIDs e descarregar extratos confidenciais de terceiros.

GET /api/v1/accounts/849202/statement HTTP/1.1
Host: api.empresa.com.br
Authorization: Bearer [TOKEN_DO_USUARIO_A]

Como Mitigar de Forma Efetiva

1. Validação em Nível de Domínio/Repositório: Nunca confie no ID enviado pela requisição. O filtro de consulta SQL deve sempre incluir o ID do locatário (tenant) ou do usuário extraído diretamente dos claims confiáveis do token JWT verificado:

   // Incorreto
   const statement = await db.statements.find({ accountId: req.params.id });
   
   // Correto
   const statement = await db.statements.find({ 
     accountId: req.params.id, 
     userId: req.user.id // Extraído com segurança do token autenticado
   });

2. Utilize Identificadores Não Sequenciais (UUID v4 ou NanoID): Embora não resolva a falha por si só, impede a enumeração massiva automatizada enquanto o controle de acesso é implementado.

---

2. API2:2023 — Broken Authentication (Quebra de Autenticação)

Mecanismos de autenticação mal configurados facilitam o comprometimento de credenciais ou o roubo de tokens de acesso.

Entre os vetores mais observados em nossos testes de invasão:

• Ausência de Rate Limiting em Rotas Críticas: Endpoints de login, redefinição de senha e envio de código OTP via SMS desprovidos de proteção contra força bruta.
• Falha de Validação na Assinatura JWT: Aceitação do algoritmo none ou uso de chaves secretas fracas e previsíveis que permitem a falsificação de tokens com privilégios de administrador.
• Tokens sem Expiração (Long-Lived Tokens): Tokens de acesso gerados sem claim de expiração exp ou sem mecanismos de revogação imediata (revocation lists) em caso de suspeita de comprometimento.

---

3. API3:2023 — Broken Object Property Level Authorization (Mass Assignment & Excessive Data Exposure)

Ocorre quando o endpoint permite que o cliente defina ou visualize propriedades sensíveis de um objeto sem a devida segregação de permissões.

Exposição Excessiva de Dados

Muitos desenvolvedores serializam entidades inteiras do banco de dados diretamente para JSON, confiando que o frontend irá ocultar os campos irrelevantes:

{
  "id": 104,
  "nome": "João Silva",
  "email": "joao@exemplo.com",
  "is_admin": false,
  "password_hash": "$2a$12$e8Y7zQ5...",
  "internal_role": "billing_user",
  "cpf": "123.456.789-00"
}

O atacante inspeciona as respostas HTTP no proxy (como Burp Suite) e obtém dados protegidos pela LGPD que jamais deveriam transitar na rede.

Mass Assignment (Atribuição em Massa)

No cadastro ou atualização de perfil (PUT /api/v1/users/me), o atacante adiciona campos adicionais no corpo da requisição:

{
  "nome": "João Silva",
  "is_admin": true,
  "subscription_tier": "enterprise"
}

Se o backend passar o req.body diretamente para o ORM (User.update(req.body)), o usuário consegue elevar privilégios sem autorização.

Mitigação

• Utilize sempre DTOs (Data Transfer Objects) estritos ou schemas com validação (Zod, Joi, Pydantic) com permissão estrita (whitelist) apenas para os campos explicitamente permitidos.

---

4. API4:2023 — Unrestricted Resource Consumption (Consumo Irrestrito de Recursos)

A ausência de limites sobre requisições e payloads permite que agentes maliciosos esgotem CPU, memória, I/O de disco ou conexões com bancos de dados.

• Falta de Paginação Limite: Requisições como GET /api/v1/logs?limit=1000000 que derrubam o banco por estouro de memória.
• Complexidade em Consultas GraphQL: Ataques de amplificação por meio de queries aninhadas recursivas circulares (user -> posts -> author -> posts...).
• Uploads sem Limite de Tamanho: Exaustão de espaço em disco ou de largura de banda do servidor.

---

5. Como a Nexo Security Testa Suas APIs

Nossos testes de intrusão em APIs não se limitam a scanners automáticos (que frequentemente param em erros 401 Unauthorized ou não entendem a ordem de execução das chamadas).

1. Análise de Especificação: Mapeamento de coleções Postman, OpenAPI/Swagger e schemas GraphQL.
2. Engenharia Reversa de Requisições: Interceptação de fluxos móveis e web para identificação de endpoints não documentados (Shadow APIs).
3. Simulação Multiusuário: Criação de matrizes de permissão cruzada entre múltiplos usuários e papéis organizacionais para comprovação matemática de BOLA e BFLA (Broken Function Level Authorization).
4. Relatório com Patches de Código: Instruções exatas e trechos de código para rápida correção pelo time de engenharia.

Para auditar as APIs da sua empresa antes do lançamento ou para homologação de compliance, conheça nosso serviço especializado de Pentest em APIs.