O OWASP API Security Top 10 existe porque as APIs quebram de formas que as aplicações web clássicas ignoram. Uma aplicação voltada ao navegador esconde sua lógica atrás de páginas renderizadas; uma API entrega os endpoints crus, os identificadores de objetos e o JSON, e confia que você só vai pedir o que é seu. É exatamente essa confiança que os atacantes exploram. Para senti-la em vez de apenas ler sobre ela, abra o curso API Security Testing da HackerDNA e acompanhe cada risco abaixo, mapeado para uma lição prática.
Esta lista é a companheira específica de APIs do OWASP Top 10 mais amplo. Ela foi reconstruída na edição de 2023 em torno das falhas que realmente aparecem em testes de intrusão de API: autorização no nível do objeto, autorização no nível da função e abuso de lógica de negócio. Este guia percorre os dez riscos com exemplos concretos, mostra como testar cada um e cobre as defesas que se sustentam em produção.
TL;DR: O OWASP API Security Top 10 (edição 2023) classifica os dez riscos de API mais críticos. Os três primeiros são todos falhas de autorização: Broken Object Level Authorization (BOLA), autenticação quebrada e autorização quebrada no nível das propriedades do objeto. Só a BOLA, em que você troca um identificador de objeto por outro e lê dados que não são seus, é o bug de API grave mais comum. Os outros sete cobrem abuso de recursos, autorização no nível da função, fluxos de negócio sensíveis, SSRF, má configuração, versões de API esquecidas e a confiança cega em APIs de terceiros. Aprenda a testar cada um e depois trave com verificações de autorização por objeto em vez de confiar no cliente.
O que é o OWASP API Security Top 10?
O OWASP API Security Top 10 é um documento padrão de conscientização que classifica os dez riscos de segurança mais sérios específicos de interfaces de programação (APIs). Publicado pela primeira vez em 2019 e revisado em 2023, é mantido pelo OWASP API Security Project como a contraparte focada em APIs da lista aplicativa web geral.
Ele existe porque as APIs têm uma superfície de ataque diferente. Uma página web tradicional acopla dados e apresentação, então boa parte da lógica fica no servidor, fora de alcance. Uma API REST ou GraphQL retira isso: expõe endpoints estruturados, identificadores de objetos previsíveis e objetos de dados completos diretamente ao cliente. O resultado é que as falhas que mais importam para APIs não são as mesmas que lideram a lista web.
Injeção e cross-site scripting dominam o teste de aplicações web. No teste de APIs, a constante é a autorização quebrada: um endpoint que autentica você corretamente e depois nunca verifica se o registro específico que você pediu realmente pertence a você. Sete dos dez itens abaixo são, no fundo, problemas de autorização.
Os 10 riscos de segurança de API, explicados
Aqui está o OWASP API Security Top 10 completo para a edição de 2023, cada um com a falha que descreve e um exemplo concreto de exploração. Os identificadores (API1 a API10) são os rótulos oficiais da OWASP e você os verá citados em relatórios de pentest e na triagem de bug bounty. Aqui está a lista OWASP API Security Top 10 da edição 2023 como referência.
API1:2023 - Broken Object Level Authorization (BOLA)
O servidor verifica que você está autenticado, mas não que o objeto solicitado é seu. Você chama GET /api/orders/1024, vê seu próprio pedido, depois muda o identificador para 1025 e lê o de outra pessoa. Essa é a mesma causa raiz de uma falha IDOR, e é de longe a vulnerabilidade de API mais prevalente e danosa, catalogada como CWE-639. Todo endpoint que recebe um identificador precisa de uma verificação, a cada requisição, de que o usuário atual é dono daquele objeto específico.
API2:2023 - Broken Authentication (autenticação quebrada)
O mecanismo que prova quem você é foi implementado de forma fraca. Casos comuns: endpoints de login sem limitação de taxa que caem para credential stuffing, JWTs assinados com um segredo adivinhável ou que aceitam o algoritmo none, tokens passados na URL onde vazam para os logs, e fluxos de redefinição de senha que não invalidam os tokens antigos. Uma vez que a autenticação quebra, toda verificação de autorização seguinte perde o sentido.
API3:2023 - Broken Object Property Level Authorization
A autorização é verificada no nível do objeto, mas não no nível da propriedade. Isso funde dois riscos antigos. No mass assignment, você adiciona "role": "admin" a uma requisição de atualização de perfil e a API o vincula direto ao banco de dados. Na exposição excessiva de dados, um GET no seu próprio usuário retorna o registro completo, incluindo campos como passwordHash ou isVerified, esperando que o cliente os esconda. Ambos vêm de confiar no formato da requisição ou da resposta em vez de filtrá-lo no servidor.
API4:2023 - Unrestricted Resource Consumption
Cada requisição de API custa CPU, memória, banda ou dinheiro (pense em cotas de SMS e e-mail). Sem limitação de taxa nem teto de tamanho, um atacante envia ?limit=9999999, faz upload de uma carga enorme ou martela um endpoint caro até o serviço cair ou a conta da nuvem explodir. É o risco por trás tanto da negação de serviço quanto dos custos descontrolados com terceiros.
API5:2023 - Broken Function Level Authorization
Onde a BOLA trata de quais dados você pode tocar, isto trata de quais ações você pode executar. Um usuário comum descobre a rota de admin POST /api/admin/users ou troca um GET por um DELETE, e o servidor executa, porque a verificação de papel vive na interface e não no endpoint. Caminhos de admin adivinháveis e métodos HTTP desprotegidos são as portas de entrada usuais.
API6:2023 - Unrestricted Access to Sensitive Business Flows
Um fluxo funciona exatamente como projetado, mas a API nunca considera o que acontece quando ele é automatizado. Scripts compram todos os ingressos de show no instante em que saem, criam contas em massa para farmar um bônus de cadastro, ou raspam um catálogo de produtos inteiro. Não há um único "bug" a corrigir aqui, a solução é detectar e limitar o uso anormal de uma funcionalidade legítima.
API7:2023 - Server Side Request Forgery
Uma API busca um recurso remoto a partir de uma URL fornecida pelo usuário sem validá-la, então você aponta o servidor para alvos internos como http://169.254.169.254 para roubar credenciais de nuvem. A SSRF migrou para a lista de APIs porque recursos de "importar de URL" e webhooks estão em toda parte nas APIs modernas. Nosso guia completo do ataque SSRF cobre os payloads e os contornos de filtro em profundidade.
API8:2023 - Security Misconfiguration (má configuração)
A API funciona, mas o deploy vaza. Stack traces verbosos nas respostas de erro, cabeçalhos de segurança ausentes, CORS permissivo retornando Access-Control-Allow-Origin: * em endpoints autenticados, métodos HTTP desnecessários deixados ativos e componentes não corrigidos ficam todos aqui. Nenhum é um exploit engenhoso, são padrões que ninguém endureceu.
API9:2023 - Improper Inventory Management
Você não pode proteger um endpoint cuja existência esqueceu. Uma equipe lança /api/v3/, corrige, e deixa a antiga /api/v1/ rodando com o bug original. Essas APIs "zumbi" e "sombra", mais hosts de homologação expostos e endpoints de debug não documentados, são um alvo favorito de bug bounty justamente porque ninguém está de olho.
API10:2023 - Unsafe Consumption of APIs
Os desenvolvedores validam a entrada do usuário com cuidado e depois confiam totalmente nos dados de APIs de terceiros. Se o seu serviço puxa de uma API parceira e injeta a resposta em uma consulta ou segue seus redirecionamentos sem checagens, um comprometimento desse parceiro vira um comprometimento seu. Trate as APIs integradas como entrada não confiável, igual a qualquer coisa que um usuário envie.
Como testar uma API contra o Top 10
Como testar uma API para esses riscos? Comece mapeando cada endpoint, depois ataque primeiro a autorização: repita cada requisição como um usuário diferente e com identificadores de objeto adulterados. Bugs de autorização (BOLA e nível de função) são as descobertas de maior valor e as mais fáceis de escapar com scanners automáticos, então merecem atenção manual.
Uma ordem prática de operações:
- Enumere a superfície. Puxe a especificação Swagger ou OpenAPI, passe o cliente web ou mobile pelo Burp, e liste cada rota, método e parâmetro. Anote os que recebem identificadores.
- Teste a autorização no nível do objeto. Capture uma requisição de um dos seus objetos, depois repita-a com o identificador de outro usuário. Se você receber os dados dele, isso é BOLA (API1).
- Teste a autorização no nível da função. Pegue uma ação só de admin capturada de uma conta privilegiada e repita-a com um token de baixo privilégio. Tente também mudar o método HTTP.
- Sonde as propriedades. Adicione campos inesperados como
roleouisAdminàs requisições de escrita (mass assignment) e inspecione as respostas de leitura em busca de campos que a interface esconde (exposição excessiva de dados). - Bata nos limites. Remova limitações de taxa girando tokens, peça páginas superdimensionadas, e observe o abuso de recursos e de fluxo de negócio.
Ao testar aplicações reais, a descoberta que mais rende ainda é a BOLA em uma rota aninhada. As equipes protegem o endpoint óbvio /users/{id}, depois esquecem o sub-recurso /users/{id}/documents/{docId}, onde o segundo identificador nunca é verificado contra o primeiro. Sempre teste o identificador mais profundo do caminho.
Como proteger suas APIs
Defender-se do OWASP API Security Top 10 se resume a um punhado de controles aplicados de forma consistente, não a um produto que você acopla. Estes são os que movem o ponteiro:
- Autorize cada objeto, a cada requisição. Em cada endpoint que recebe um identificador, verifique no servidor que o usuário autenticado é dono daquele registro exato. Esse único hábito fecha a BOLA, o bug de API mais comum.
- Imponha papéis no nível da função no endpoint. Ponha a verificação de papel no handler da rota, nunca no cliente. Negue por padrão e rejeite métodos HTTP inesperados.
- Filtre propriedades na entrada e na saída. Vincule apenas uma lista explícita de campos permitidos nas escritas para deter o mass assignment, e serialize apenas os campos que um chamador deve ver nas leituras.
- Limite a taxa e coloque teto em tudo. Defina cotas de requisição, tamanhos máximos de página e limites de carga para que um único chamador não esgote recursos nem automatize um fluxo sensível.
- Mantenha um inventário de API. Rastreie cada host, versão e endpoint, aposente versões antigas e tire as rotas de homologação e debug da internet pública.
Note que quatro dos cinco mapeiam para autorização e tratamento de entrada. Acerte-os e a maioria da lista se fecha sozinha.
API Security Top 10 versus o OWASP Top 10 original
As duas listas se sobrepõem, mas não são intercambiáveis, e é esse o ponto. O OWASP Top 10 original é escrito para aplicações web completas e lidera com categorias amplas como injeção e má configuração. A lista de API dá zoom nas falhas que dominam as superfícies de ataque exclusivas de API.
- A autorização está em primeiro plano. Três dos cinco primeiros riscos de API são falhas de autorização (BOLA, nível de função, nível de propriedade). Na lista web, eles são agrupados em uma única entrada Broken Access Control.
- A injeção é menor aqui. A injeção clássica também importa para APIs, mas não lidera como no web. Quando aparece, nosso tutorial de injeção SQL cobre as mecânicas que se transferem direto para os parâmetros de API.
- A lógica de negócio ganha seu próprio espaço. O acesso irrestrito a fluxos de negócio sensíveis (API6) não tem equivalente direto na lista web, porque a automação de APIs o torna um problema de primeira classe.
Se você testa aplicações web e APIs, aprenda as duas listas. A lista web enquadra as categorias de risco; a lista de API diz onde realmente gastar seu tempo em um backend JSON moderno.
Considerações legais e éticas
Lembrete essencial: Sempre obtenha autorização escrita explícita antes de testar qualquer API. Trocar identificadores de objeto para ler os registros de outro usuário ou repetir requisições de admin em um sistema que você não possui é acesso não autorizado sob o Computer Fraud and Abuse Act (EUA), o Computer Misuse Act (Reino Unido) e leis equivalentes no mundo todo, mesmo quando a API torna isso trivialmente fácil.
- Teste apenas APIs que você possui, labs de prática dedicados ou alvos dentro do escopo definido de um engajamento autorizado ou de um programa de bug bounty.
- Testes de BOLA expõem dados reais de usuários. Se você confirmar a falha, pare na prova de impacto e nunca baixe, guarde ou compartilhe os registros de terceiros.
- Testes de limitação de taxa e de consumo de recursos podem derrubar um serviço. Coordene-se com o dono e permaneça dentro dos limites acordados.
- Pratique técnicas destrutivas e de lógica de negócio em APIs propositalmente vulneráveis, não em sistemas de produção.
Perguntas frequentes
O que é o OWASP API Security Top 10?
É uma lista padrão de conscientização dos dez riscos de segurança mais críticos específicos de APIs, mantida pelo OWASP API Security Project. A edição atual de 2023 lidera com falhas de autorização como a Broken Object Level Authorization (BOLA) em vez das falhas de injeção que dominam a lista aplicativa web geral.
O que é BOLA e por que é número um?
Broken Object Level Authorization (BOLA) é quando uma API confirma que você está autenticado, mas não verifica se o objeto específico solicitado pertence a você. Mudar um identificador na requisição retorna os dados de outro usuário. Fica em primeiro porque é ao mesmo tempo a falha de API mais comum e a mais danosa, e os scanners automáticos a perdem com frequência.
Como o OWASP API Security Top 10 difere do OWASP Top 10?
O OWASP Top 10 mira aplicações web completas e lidera com categorias amplas como injeção. A lista de API foca nas superfícies de ataque específicas de APIs, onde as falhas de autorização dominam: três dos seus cinco primeiros são bugs de autorização, e ela acrescenta riscos como abuso de fluxo de negócio e gestão de inventário imprópria que a lista web não aponta separadamente.
Como testo minha API para esses riscos?
Mapeie cada endpoint a partir da especificação OpenAPI ou de um proxy, depois repita as requisições como usuários diferentes e com identificadores de objeto adulterados para achar autorização quebrada. Sonde campos escondidos nas respostas, campos inesperados nas requisições, limitações de taxa ausentes e versões antigas de API esquecidas. O teste de autorização é um trabalho manual que os scanners não conseguem automatizar por completo.
Qual é o controle de segurança de API mais importante?
Autorização por objeto a cada requisição. Para cada endpoint que recebe um identificador de objeto, o servidor precisa verificar que o usuário autenticado realmente é dono daquele registro antes de retorná-lo. Esse único controle fecha a BOLA, a vulnerabilidade de API grave mais comum, e nenhuma verificação do lado do cliente o substitui.
Parte da série OWASP Top 10
Artigos relacionados:
- Controle de Acesso Quebrado
- O ataque SSRF explicado
- Tutorial de Injeção SQL
- OWASP API Security Top 10
Seus próximos passos
O OWASP API Security Top 10 faz sentido no instante em que você explora o primeiro item por conta própria: mude um identificador de objeto, veja voltar os dados de outra conta, e a BOLA deixa de ser uma linha em uma lista. Bugs de autorização como esse são invisíveis para uma mentalidade página por página e óbvios quando você pensa em endpoints e identificadores. Comece com o plano gratuito da HackerDNA, sem cartão de crédito, e quebre uma API real no lab API Breaker. Quando quiser o caminho completo, do reconhecimento à autenticação, autorização, mass assignment e GraphQL, o curso API Security Testing percorre cada risco desta lista em labs guiados no navegador. Aprenda a testar APIs como os atacantes fazem, e depois vá construir as verificações por objeto que os detêm.
