Do IDOR ao BOPLA: decifrando a sopa de letrinhas da autorização em APIs (e como blindar seu código)

Se você desenvolve software hoje, provavelmente já se deparou com este mantra: "autenticação não é autorização".

Implementar um login seguro com JWT, OAuth2 ou MFA é apenas metade do caminho. O verdadeiro desafio começa no momento seguinte: quando o usuário já está logado e sua aplicação precisa decidir, a cada milissegundo, se ele tem permissão para visualizar, alterar ou excluir um dado específico.

Com a evolução das arquiteturas para APIs REST, GraphQL e microsserviços, a OWASP atualizou o vocabulário para descrever essas falhas. O clássico IDOR ganhou derivados mais precisos no OWASP API Security Top 10: BOLA, BFLA e BOPLA.

1. IDOR e BOLA: o clássico e sua versão para APIs

O conceito

IDOR (Insecure Direct Object References): O termo clássico cunhado pela OWASP. Ocorre quando a aplicação recebe um identificador fornecido pelo usuário e acessa diretamente o recurso no banco sem validar se quem fez a requisição é o dono legítimo daquele registro.

BOLA (Broken Object Level Authorization): É a classificação moderna da OWASP para APIs (API1:2023). Na prática, é a versão contemporânea e focada em endpoints do IDOR.

O cenário real

Imagine uma rota para buscar faturas:

Se você alterar o ID para 1043 e a API retornar a fatura do seu vizinho, temos um caso clássico de BOLA/IDOR.

# CÓDIGO VULNERÁVEL (Python/FastAPI)
@app.get("/invoices/{invoice_id}")
async def get_invoice(invoice_id: int, current_user: User = Depends(get_current_user)):
    # Falha: busca apenas pelo ID do recurso, ignorando o dono
    invoice = db.query(Invoice).filter(Invoice.id == invoice_id).first()
    return invoice

# CORREÇÃO SEGURA
@app.get("/invoices/{invoice_id}")
async def get_invoice(invoice_id: int, current_user: User = Depends(get_current_user)):
    # Valida tanto o ID do recurso quanto o vínculo com o usuário logado
    invoice = db.query(Invoice).filter(
        Invoice.id == invoice_id, 
        Invoice.user_id == current_user.id
    ).first()
    
    if not invoice:
        raise HTTPException(status_code=404, detail="Invoice not found")
    return invoice

2. BFLA: quando o usuário comum veste a capa de admin

O conceito

BFLA (Broken Function Level Authorization - API5:2023) trata do acesso indevido a ações e funções, e não a objetos específicos. É a famosa falha de controle de acesso vertical ou entre módulos administrativos.

Muitas vezes, a equipe esconde o botão "Deletar Usuário" no front-end para usuários normais, mas esquece de proteger o endpoint correspondente no back-end.

O cenário real

Um usuário com perfil Viewer percebe a requisição de atualização de perfil e tenta enviar um método administrativo:

• Requisição legítima: POST /api/v1/documents
• Tentativa maliciosa: DELETE /api/v1/admin/documents/export-all ou PUT /api/v1/users/42/role

Se o middleware de autenticação validar apenas se o token é válido, mas não checar se a role do usuário possui o escopo necessário para aquela função específica, o endpoint cede.

3. BOPLA: o pesadelo das propriedades ocultas

O conceito

No OWASP API Security Top 10 (2023), BOPLA (Broken Object Property Level Authorization - API3:2023) unificou dois problemas conhecidos:

• Mass Assignment: O usuário envia campos sensíveis que o backend aceita e persiste cegamente.
• Excessive Data Exposure: O backend devolve o objeto inteiro serializado, expondo campos confidenciais.

O cenário real

Ao atualizar o próprio perfil (PATCH /api/v1/profile), o usuário envia:

{
  "name": "Carlos Dev",
  "email": "carlos@empresa.com",
  "is_admin": true,
  "account_balance": 999999
}

Se o código injeta o JSON diretamente na entidade de banco (como um User.update(req.body) no Node.js ou db.merge(user_data) em ORMs), o usuário se torna administrador ou altera seu próprio saldo.

Comparativo rápido: diferenciando as siglas

Da teoria ao código: como aprender a mitigar de verdade?

Ler sobre OWASP é simples; identificar essas sutilezas no meio de milhares de linhas de código em produção, com ORMs complexos e regras de negócio encadeadas, é outra história.

É por isso que criamos a Umbrella Academy, a plataforma de capacitação prática da Umbra Offensive Security.

Diferente de CTFs convencionais que focam apenas no lado ofensivo de explorar falhas, a nossa abordagem foi desenhada para desenvolvedores e times de AppSec:

• Laboratórios Práticos: Você explora a vulnerabilidade em um ambiente simulado e realista.
• Code Review & Remediation: Após o exploit, você tem acesso direto ao código-fonte vulnerável.
• Validação Automática: O seu desafio é codificar a correção, submeter o patch e passar pelos testes de segurança da nossa engine.
• Minicursos Sob Demanda: Trilhas técnicas focadas em frameworks modernos, desenhadas para elevar a barra de AppSec do seu time.