Segurança de API.

A segurança de API abrange superfícies REST, GraphQL, gRPC e webhooks que muitas vezes expõem a lógica de negócio diretamente. Ela se alinha ao OWASP API Security Top 10 (2023), que coloca em primeiro lugar a autorização quebrada a nível de objeto (BOLA/API1), seguida de autenticação quebrada, autorização quebrada a nível de propriedade, consumo de recursos sem limite, autorização quebrada a nível de função e SSRF.

Por que o BOLA domina. A maioria das brechas de API não é exótica: são verificações de propriedade por objeto que faltam. Na brecha da Optus (setembro de 2022), um endpoint acessível pela internet não exigia autenticação e expunha registros endereçáveis por IDs sequenciais, permitindo enumerar cerca de 10 milhões de australianos. Em janeiro de 2023, a T-Mobile revelou o abuso de uma API que autenticava a sessão mas não limitava quais registros ela podia ler, expondo cerca de 37 milhões de contas. Ambos são casos clássicos de falha de autorização a nível de objeto.

Controles. Programas eficazes combinam identidade forte (OAuth 2.0/OIDC, tokens com escopo e curta duração, mTLS), uma verificação de propriedade no lado servidor em toda referência de objeto, validação de requisição e resposta baseada em schema, rate limiting e cotas contra scraping, e logs estruturados alimentando um SIEM. Testes contínuos com SAST, DAST e fuzzing específico de API detectam regressões. Descobrir e inventariar APIs sombra e zumbi é fundamental: não se defende o que não se sabe que existe.

flowchart TD
  A[Requisição do cliente + token bearer] --> B{Token válido?}
  B -->|Não| R[401 Não autorizado]
  B -->|Sim| C{O escopo permite esta operação?}
  C -->|Não| F[403 Proibido]
  C -->|Sim| D{O chamador É DONO do ID do objeto?}
  D -->|Não - risco BOLA| F
  D -->|Sim| E{Dentro do limite e schema válido?}
  E -->|Não| G[429 / 400 rejeitado]
  E -->|Sim| H[Retornar apenas os campos permitidos]