Metade das aplicações modernas é uma API. Aplicativos de celular, single-page apps, integrações entre serviços, dispositivos IoT — todos se comunicam através de APIs (Application Programming Interfaces), que expõem funcionalidades e dados de forma programática. E como as APIs têm características próprias que as tornam um alvo distinto das aplicações web tradicionais, elas ganharam seu próprio OWASP Top 10. Este bloco curto cobre a segurança de APIs, começando pelos riscos mais importantes. Pratique com APIs vulneráveis propositais (como o crAPI ou o VAmPI).

Por que APIs merecem tratamento próprio

Primeiro, por que APIs merecem tratamento próprio. Uma aplicação web tradicional serve páginas HTML para humanos; uma API serve dados (tipicamente em JSON) para outros programas. Essa diferença tem consequências de segurança. As APIs frequentemente expõem a lógica de negócio diretamente, com muitos endpoints granulares (um para cada operação). Elas são stateless e dependem fortemente de tokens (JWT, aula Falhas de autenticação, sessões e JWT: quebrando o controle de identidade) para autenticação. Elas são menos visíveis — não há uma interface navegável que revele todos os endpoints, então a superfície de ataque é "invisível" até ser mapeada. E como são consumidas por programas, os desenvolvedores às vezes assumem (erroneamente) que o cliente é confiável — esquecendo que um atacante pode chamar a API diretamente, ignorando o app "oficial". Essas características criam um perfil de risco distinto que o OWASP API Security Top 10 endereça.

BOLA: o risco número um

O risco número um, e o mais emblemático das APIs, é o BOLA (Broken Object Level Authorization) — também conhecido como IDOR (Insecure Direct Object Reference). É uma forma de Broken Access Control (aula OWASP Top 10: o mapa das vulnerabilidades web) especialmente prevalente em APIs, e o conceito é simples e devastador: a API expõe objetos por um identificador (/api/pedidos/123), e não verifica adequadamente se o usuário requisitante tem permissão para acessar aquele objeto específico. Então, se você está autenticado e requisita /api/pedidos/123 (seu pedido), mas troca para /api/pedidos/124, e a API te entrega o pedido de outro usuário — isso é BOLA. A API autenticou você (sabe quem você é), mas falhou na autorização em nível de objeto (verificar se você pode acessar aquele objeto). É trivial de explorar (basta mudar um número) e onipresente, porque impor essa verificação em cada endpoint e cada objeto é trabalhoso e fácil de esquecer. O BOLA é o risco número um das APIs justamente por essa combinação de alto impacto e alta prevalência.

Os demais riscos do API Top 10

Os demais riscos do API Top 10 refletem os desafios específicos das APIs. Broken Authentication — mecanismos de autenticação de API mal implementados (gestão fraca de tokens, JWT vulnerável, ausência de rate limiting em endpoints de login). Broken Object Property Level Authorization — expor ou permitir modificar propriedades de objetos que o usuário não deveria acessar (incluindo o "mass assignment", onde o atacante envia campos extras que a API aceita cegamente — como definir "role": "admin" num cadastro). Unrestricted Resource Consumption — APIs sem limites de taxa ou de recursos, vulneráveis a abuso e negação de serviço. Broken Function Level Authorization — acessar funções administrativas que não deveriam estar disponíveis (chamar um endpoint de admin sendo usuário comum). E outros relacionados a configuração incorreta, inventário inadequado de APIs (endpoints antigos e esquecidos, versões desatualizadas expostas) e consumo inseguro de APIs de terceiros.

O problema da autorização em escala

Um tema que atravessa o API Top 10, e que quero destacar, é o problema da autorização em escala. APIs têm muitos endpoints e muitos objetos, e a autorização precisa ser verificada corretamente em cada combinação — cada endpoint, cada objeto, cada propriedade, cada função. É um problema combinatório: quanto mais granular a API, mais pontos onde a autorização pode falhar. Enquanto a autenticação (provar quem você é) costuma ser centralizada e feita uma vez, a autorização (verificar o que você pode acessar) precisa ser imposta em toda parte, e é aí que as APIs mais falham. O BOLA e seus parentes são todos manifestações desse desafio: a API sabe quem você é, mas esquece de verificar, em algum ponto, se você deveria acessar aquilo.

Autorização rigorosa em cada objeto

Do lado defensivo, a segurança de APIs gira em torno de impor autorização rigorosa e consistente. As contramedidas: verificação de autorização em nível de objeto em cada endpoint (nunca confiar que o identificador na requisição pertence ao usuário — sempre verificar; esta é a defesa central contra BOLA); autenticação robusta (tokens gerenciados corretamente, JWT seguro, MFA); evitar mass assignment (definir explicitamente quais campos podem ser modificados, ignorando os demais — allowlist de propriedades); rate limiting em todos os endpoints; inventário de APIs (saber quais endpoints e versões existem, aposentando os antigos — a "superfície invisível" precisa ser conhecida para ser protegida); e validação de entrada em cada endpoint. A lição central: em APIs, autenticação não basta — a autorização deve ser verificada rigorosamente em cada objeto, propriedade e função, porque a falha nessa verificação granular é o risco dominante.

Fontes e leituras recomendadas

Exercícios

  1. Cite três características das APIs que as tornam um alvo distinto das aplicações web tradicionais.

    ✓ Resposta:

    Servem dados (JSON) a programas em vez de páginas a humanos; expõem lógica de negócio com muitos endpoints granulares; são stateless e dependem de tokens; são menos visíveis (superfície invisível até ser mapeada); e podem ser chamadas diretamente, ignorando o app oficial. (Três quaisquer.)

  2. Explique o BOLA/IDOR: o que a API faz corretamente e o que ela falha em fazer?

    ✓ Resposta:

    No BOLA/IDOR, a API expõe objetos por identificador e não verifica se o usuário tem permissão para acessar aquele objeto específico. Ela faz corretamente a autenticação (sabe quem você é), mas falha na autorização em nível de objeto — permitindo que, ao trocar o identificador (ex.: /pedidos/123 para /124), você acesse o objeto de outro usuário.

  3. O que é "mass assignment", e por que ele é uma falha de autorização em nível de propriedade?

    ✓ Resposta:

    Mass assignment é quando a API aceita cegamente campos extras enviados pelo atacante, permitindo definir propriedades que ele não deveria controlar (ex.: enviar "role": "admin" num cadastro). É uma falha de autorização em nível de propriedade porque o usuário modifica propriedades de um objeto às quais não deveria ter acesso.

  4. Explique o "problema da autorização em escala" e por que ele afeta APIs mais do que aplicações tradicionais.

    ✓ Resposta:

    É o fato de que a autorização precisa ser verificada corretamente em cada endpoint, objeto, propriedade e função — um problema combinatório que cresce com a granularidade da API. Afeta APIs mais do que aplicações tradicionais porque APIs têm muitos endpoints e objetos granulares, multiplicando os pontos onde a verificação de autorização pode ser esquecida.

  5. Qual a defesa central contra BOLA, e por que "autenticação não basta" em APIs?

    ✓ Resposta:

    A defesa central é verificar a autorização em nível de objeto em cada endpoint — nunca confiar que o identificador na requisição pertence ao usuário, sempre checando. "Autenticação não basta" porque provar quem o usuário é (autenticação) não impede que ele acesse objetos/funções de outros; é a autorização, verificada em cada ponto, que controla o que ele pode acessar — e é onde as APIs mais falham.