Segurança de API: Como Atacantes Exploram seus Endpoints

Resumo:

• APIs são uma parte essencial de apps móveis, microsserviços, integrações e agentes de IA, concentrando a maior parte do tráfego web corporativo. 
• Falhas de lógica de autorização (o endpoint “funciona certo”, mas entrega dado errado) são o problema mais grave e o mais difícil de pegar com WAFs baseados em assinatura.
• Em uma API, o atacante é apenas mais um cliente, livre para manipular IDs e parâmetros. Por isso, as falhas mais perigosas são os erros de autorização.
• 57% das organizações relataram incidentes de API nos últimos dois anos. A maioria enfrentou mais de três incidentes.
• Confiar apenas no front-end, confundir autenticação com autorização, manter versões antigas de API ativas, depender só de WAF e ignorar limites de consumo  são erros comuns em incidentes reais. 

 

Aplicativos móveis, microsserviços, integrações com parceiros, pipelines de dados e agentes de IA: as APIs se tornaram a espinha dorsal de praticamente todo produto digital. 

Estima-se que o tráfego de APIs já represente a maior parte de todo o tráfego web das empresas, e o número de endpoints sob gestão cresce a cada sprint. Esse mesmo crescimento que destrava a receita também amplia, na mesma proporção, a superfície de ataque.

O que são vulnerabilidades em APIs

Uma vulnerabilidade em uma API pode ser qualquer falha de projeto, implementação ou configuração que permita a um agente não autorizado ler, modificar ou abusar de funções e dados expostos por um endpoint. 

A diferença fundamental em relação às vulnerabilidades clássicas de aplicações web está na natureza do alvo. Em uma aplicação tradicional, o servidor renderiza a tela e controla o fluxo, enquanto em uma API, o cliente é quem orquestra as chamadas e um atacante é apenas mais um, com total liberdade para alterar IDs, parâmetros, cabeçalhos e a ordem das requisições. Por isso, ferramentas e WAFs baseados em assinaturas tendem a falhar com APIs. 

As falhas mais graves são os erros de lógica de autorização: o endpoint funciona exatamente como projetado, mas entrega o dado errado para a pessoa errada. Esse é o motivo da categoria de autorização liderar todas as edições do ranking de risco de APIs.

Ponto de atenção: cada endpoint que recebe um identificador (um /users/1234 ou /orders/5567) é um ponto potencial de falha de autorização. A pergunta a fazer em todo code review é se aquele usuário autenticado tem o direito de acessar aquele objeto específico. 

Por que a segurança de APIs virou pauta do board?

Pesquisas mostram que cerca de 57% das organizações (Cybersecurity Insiders, 2024) relataram pelo menos um incidente de segurança envolvendo APIs nos últimos dois anos. Boa parte delas enfrentou três ou mais incidentes. 

O cenário de detecção é igualmente preocupante: as empresas relatam alta capacidade de detectar ataques na camada de AP, mas não conseguem prevenir mais da metade desses ataques. 

Em paralelo, o volume de tráfego malicioso direcionado a APIs continua crescendo, impulsionado por bots, fraude automatizada e, mais recentemente, abusos via aplicações de IA generativa.

Para a diretoria das empresas, o risco se traduz em três vetores principais: vazamento de dados regulados, interrupção de serviço (DDoS de aplicação via abuso de endpoints caros) e fraude de negócio (manipulação de preços, cupons e saques).

OWASP API Security Top 10 (2023)

O OWASP API Security Top 10 é o documento de referência mundial para riscos de APIs, mantido pela OWASP Foundation a partir de dados reais de pentests, programas de bug bounty e pesquisa de segurança. 

A edição de 2023 reorganizou o ranking de 2019 para refletir como os atacantes realmente operam hoje, com mais ênfase em autorização, consumo de recursos e abuso de fluxos de negócio. 

ID	Vulnerabilidade	Mitigação essencial
API1	Broken Object Level Authorization (BOLA)	Validar a posse do objeto no servidor a cada requisição. Nunca confiar no ID enviado pelo cliente.
API2	Broken Authentication	Tokens de curta duração, MFA, rotação de credenciais e proteção contra brute force e credential stuffing.
API3	Broken Object Property Level Authorization	Controlar quais campos podem ser lidos/escritos. Evitar exposição excessiva e mass assignment.
API4	Unrestricted Resource Consumption	Rate limiting, cotas, timeouts e limites de payload para conter abuso e custos (inclusive DoS).
API5	Broken Function Level Authorization	Separar papéis e funções administrativas. Negar por padrão e validar permissão por função.
API6	Unrestricted Access to Sensitive Business Flows	Proteger fluxos sensíveis (compra, cadastro e cupom) contra automação e abuso em escala.
API7	Server Side Request Forgery (SSRF)	Validar e restringir URLs de saída. Bloquear acesso a metadados de nuvem e redes internas.
API8	Security Misconfiguration	Hardening, headers seguros, CORS restrito, desabilitar verbos e mensagens de erro.
API9	Improper Inventory Management	Inventário vivo de APIs e versões. Aposentar endpoints legados e ambientes não produtivos expostos.
API10	Unsafe Consumption of APIs	Tratar respostas de terceiros como não confiáveis. Validar, sanitizar e aplicar timeouts.

 

API1 (2023): Broken Object Level Authorization (BOLA)

Ocorre quando a API aceita um identificador de objeto na requisição, mas não verifica se o usuário autenticado tem permissão sobre aquele objeto específico. O atacante simplesmente troca o ID na URL e acessa os dados de outra pessoa. É simples de explorar, difícil de detectar automaticamente e potencialmente devastador.

Exemplo de exploração:

# Usuário legítimo consulta o próprio pedido

GET /api/v1/orders/1001   Authorization: Bearer <token_do_usuario>

# Atacante apenas incrementa o ID e recebe o pedido de OUTRO cliente

GET /api/v1/orders/1002   Authorization: Bearer <token_do_usuario>

  -> 200 OK  { "cliente": "Maria", "cpf": "***", "valor": 4200.00 }

Como mitigar:

• Imponha a verificação de autorização por objeto no servidor, em toda leitura, atualização e exclusão, sem abrir exceções.
• Prefira identificadores não sequenciais e não adivinháveis (UUID) em vez de IDs incrementais.
• Centralize a lógica de autorização em um middleware/policy, evitando implementá-la em cada handler.
• Inclua casos de BOLA na suíte automatizada de testes de segurança (tente acessar objetos de outro tenant/usuário).

API2 (2023): Broken Authentication

São as falhas no mecanismo que comprovam a identidade de quem chama a API: tokens fracos ou eternos, ausência de MFA, segredos hardcoded, endpoints de login sem proteção contra força bruta e fluxos de recuperação de senha frágeis, resultando no sequestro de contas (account takeover). 

Vale lembrar que uma parcela expressiva dos ataques parte de usuários já autenticados.

Como mitigar:

• Use tokens de curta duração (access tokens) com refresh controlado e revogação efetiva.
• Exija MFA em operações sensíveis e proteja login/refresh com rate limiting e detecção de credential stuffing.
• Nunca embuta chaves de API no código-cliente, apps móveis ou repositórios. Use cofres de segredos e rotação.
• Valide assinatura, emissor, audiência e expiração de cada JWT no servidor. Nunca confie em claims sem verificá-los.

API3 (2023): Broken Object Property Level Authorization

Esta categoria uniu duas falhas clássicas: exposição excessiva de dados e mass assignment. A causa é a mesma: falta de controle sobre quais propriedades de um objeto cada usuário pode ler ou escrever. 

No primeiro caso, a API devolve campos sensíveis que o cliente filtraria na tela (mas o atacante lê direto da resposta). No segundo, o atacante envia campos que não deveria poder definir, como:

# Mass assignment: o cliente injeta um campo privilegiado no corpo da requisição

PATCH /api/v1/users/me

{ "nome": "Joao", "role": "admin", "saldo": 999999 }

  -> se a API faz bind direto do JSON no modelo, o usuário vira admin

Como mitigar:

• Defina explicitamente os campos permitidos de entrada e saída (allow-list / DTOs), nunca serialize o modelo inteiro.
• Evite o bind automático de JSON para entidades de domínio sem filtragem de propriedades.
• Retorne apenas os campos necessários para cada consumidor e contexto.

API4 (2023): Unrestricted Resource Consumption

Toda chamada de API consome CPU, memória, banda, armazenamento e, muitas vezes, serviços pagos de terceiros (SMS, e-mail, inferência de IA). 

Sem limites, um atacante provoca negação de serviço ou estoura o orçamento da empresa com requisições massivas, payloads gigantes ou paginação abusiva. Em ambientes de IA, esse risco se multiplica pelo custo por token.

Como mitigar:

• Aplique rate limiting e cotas por usuário, IP, chave de API e plano comercial.
• Defina limites de tamanho de payload, de itens por página e de profundidade de consultas (especialmente em GraphQL).
• Configure timeouts e circuit breakers. Monitore custo por endpoint e dispare alertas de anomalia.

API5 (2023): Broken Function Level Authorization

Enquanto a BOLA trata do acesso a objetos, esta falha trata do acesso a funções. Acontece quando um usuário comum consegue invocar operações administrativas, por exemplo descobrindo a rota:

# Usuário sem privilégio descobre e chama um endpoint administrativo

DELETE /api/v1/admin/users/77   Authorization: Bearer <token_comum>

  -> 200 OK  (a API não checou se o papel do chamador permite a operação)

Como mitigar:

• Negue por padrão: toda função deve exigir uma verificação explícita de papel/permissão.
• Separe claramente rotas administrativas e de usuário, não dependa de “obscuridade” da URL.
• Modele autorização baseada em papéis (RBAC) ou atributos (ABAC) de forma centralizada e testável.

API6 (2023): Unrestricted Access to Sensitive Business Flows

Muitos ataques não exploram bug algum: a API funciona perfeitamente, mas o fluxo de negócio é abusado em escala por automação. 

Pense em revenda automatizada de ingressos, criação em massa de contas para abusar de cupons, ou scraping de preços. O dano é real mesmo sem nenhuma “falha técnica” tradicional.

Como mitigar:

• Mapeie os fluxos sensíveis do negócio (compra, cadastro, transferência, resgate de promoção) e modele como poderiam ser abusados.
• Combine detecção de bots, device fingerprinting, CAPTCHA adaptativo e limites comportamentais.
• Trate o abuso como problema de produto e segurança em conjunto, não apenas como infraestrutura.

API7 (2023): Server Side Request Forgery (SSRF)

Ocorre quando a API busca um recurso a partir de uma URL fornecida (ou influenciada) pelo usuário, sem validá-la. 

O atacante força o servidor a fazer requisições para destinos internos, incluindo os endpoints de metadados da nuvem, que podem expor credenciais temporárias da infraestrutura. Webhooks e importadores de URL são vetores clássicos.

Como mitigar:

• Valide e restrinja destinos de saída com allow-list, bloqueie faixas internas e endpoints de metadados de nuvem.
• Resolva e fixe o IP de destino, evitando bypass por redirecionamento e rebinding de DNS.
• Isole, em rede, os serviços que fazem chamadas de saída a partir da entrada do usuário.

API8 (2023): Security Misconfiguration

É uma configuração incorreta responsável por uma fatia enorme dos incidentes observados na produção. Inclui CORS permissivo demais, cabeçalhos de segurança ausentes, verbos HTTP desnecessários habilitados, mensagens de erro que vazam stack traces, TLS mal configurado e serviços com credenciais padrão. 

Como mitigar:

• Aplique baselines de hardening automatizados (infraestrutura como código) e revise CORS para permitir apenas origens necessárias.
• Desabilite verbos e endpoints não usados, padronize mensagens de erro sem detalhes internos.
• Force TLS moderno e adicione cabeçalhos de segurança. Verifique a configuração com scanners no pipeline.

API9 (2023): Improper Inventory Management

Endpoints esquecidos, versões antigas ainda no ar (a clássica /v1 que ninguém aposentou enquanto todos olham para a /v3), ambientes de homologação expostos e documentação desatualizada criam APIs “fantasma”, sem monitoramento e sem patches. 

Como mitigar:

• Mantenha um inventário vivo e automatizado de todas as APIs, versões, ambientes e donos.
• Aposente versões legadas com política formal de depreciação e bloqueio efetivo.
• Use descoberta contínua (discovery) para encontrar shadow e zombie APIs antes do atacante.

API10 (2023): Unsafe Consumption of APIs

As empresas tendem a confiar mais em APIs de terceiros do que em entradas de usuário. Se um parceiro for comprometido ou retornar dados maliciosos, sua aplicação pode ser explorada ao processar a resposta sem validação. Em pipelines de IA, isso é especialmente crítico: respostas de serviços externos alimentam decisões e prompts automaticamente.

Como mitigar:

• Trate respostas de terceiros como não confiáveis: valide schema, tipos e tamanho antes de usar.
• Aplique timeouts, limites e tratamento de erro robusto em toda integração de saída.
• Use conexões cifradas e verifique a integridade/origem dos dados recebidos.

Vulnerabilidades emergentes: APIs na era da IA generativa

Agentes de IA frequentemente chamam APIs em nome do usuário e, quando o fazem, costumam pular as verificações de autorização por objeto, recriando BOLA em um novo contexto. 

O prompt injection pode ser usado para induzir um modelo a disparar requisições de saída para serviços internos, transformando SSRF em uma falha orquestrada por linguagem natural. E pipelines que consomem APIs de terceiros sem validar respostas amplificam o risco de consumo inseguro. 

Se a empresa constrói ou expõe APIs com IA, é interessante tratar o OWASP Top 10 for LLM Applications como complemento, e não substituto, do OWASP API Security Top 10. Uma boa tática é aplicar a autorização por objeto também nas chamadas feitas por agentes e não permitir que a saída de um modelo acione requisições internas sem validação.

Como identificar vulnerabilidades em APIs

Detectar falhas de API exige uma abordagem específica, já que scanners genéricos não enxergam erros de lógica de autorização. Uma estratégia madura combina várias técnicas ao longo do ciclo de vida:

• Descoberta de inventário (API discovery): mapear todos os endpoints reais em tráfego, incluindo shadow e zombie APIs, antes de qualquer teste.
• SAST e análise de dependências: identificar padrões inseguros no código e nas bibliotecas vulneráveis ainda na esteira do build.
• DAST e fuzzing de API: exercitar endpoints com entradas inesperadas, partindo do contrato OpenAPI/Swagger quando disponível.
• Pentest manual focado em lógica: testar BOLA, BFLA e abuso de fluxos, casos em que a inteligência humana ainda supera a automação.
• Monitoramento em runtime: observar comportamento anômalo em produção (enumeração de IDs, picos de consumo, padrões de bot).

Analista de segurança: priorize testes de autorização cruzada entre tenants e papéis. Crie dois usuários (A e B) e tente, com o token de A, acessar e modificar objetos de B em cada endpoint. Esse teste simples revela a maioria das BOLAS, a vulnerabilidade que mais aparece em incidentes reais.

Estratégia de defesa: responsabilidades por papel

A segurança de API funciona quando CTO, tech lead e analista de segurança atuam em camadas complementares nas principais frentes:

 

Frente	CTO	Tech Lead	Analista de Segurança
Governança e inventário	Patrocina o inventário de APIs como ativo crítico e exige visibilidade no board.	Mantém catálogo de endpoints, donos e versões. Aplica a política de depreciação.	Roda discovery contínuo e valida que o inventário reflete o tráfego real.
Autenticação e autorização	Define padrão corporativo de identidade (OAuth/OIDC, MFA, gestão de segredos).	Implementa autZ centralizada (RBAC/ABAC) e impõe checagem por objeto.	Testa BOLA/BFLA e fluxos de login. Caça segredos vazados em repositórios.
Resiliência e abuso	Aprova investimento em rate limiting, anti-bot e proteção de fluxos sensíveis.	Configura cotas, timeouts e limites de payload por design.	Monitora abuso, enumeração e anomalias de consumo em runtime.
Ciclo de vida (DevSecOps)	Faz da segurança da API um critério de pronto (Definition of Done).	Integra SAST/DAST e testes de contrato no CI/CD. Bloqueia deploy inseguro.	Conduz pentests recorrentes e valida correções (re-test).

 

Integrando segurança de APIs no ciclo de desenvolvimento

A forma mais eficiente e mais barata de eliminar vulnerabilidades é deslocá-las para a esquerda (shift-left). Um fluxo maduro percorre cinco etapas:

1. Design: threat modeling de cada novo endpoint. Defina requisitos de autorização por objeto e por função antes de codar.
2. Desenvolvimento: padrões seguros por default, revisão de código com foco em autZ, gestão de segredos e validação de entrada/saída.
3. Build/CI: SAST, análise de dependências e testes de contrato OpenAPI rodando automaticamente, falha de segurança quebra o build.
4. Pré-produção: DAST e fuzzing de API contra o ambiente de homologação, gate de deploy condicionado ao resultado.
5. Produção: monitoramento de runtime, detecção de anomalias, rate limiting e retest periódico de correções.

Métricas e KPIs para acompanhar

Para transformar segurança de API em decisão de negócio, acompanhe indicadores objetivos:

• Cobertura de inventário: percentual de endpoints conhecidos e monitorados versus descobertos em tráfego.
• Cobertura de testes de autorização: percentual de endpoints com testes automatizados de BOLA/BFLA.
• MTTR de vulnerabilidades de API: tempo médio entre identificação e correção, segmentado por severidade.
• Densidade de findings: vulnerabilidades por 100 endpoints ao longo do tempo (tendência de melhoria).
• Taxa de detecção: proporção de tentativas de ataque detectadas na camada de API em runtime.

Cinco erros comuns que ainda derrubam empresas

1. Confiar no cliente: Filtrar dados ou esconder botões no front não protege a API.
2. Tratar autenticação como autorização: Saber quem é o usuário não diz o que ele pode acessar. São controles distintos.
3. Esquecer versões antigas no ar: A /v1 depreciada continua sendo um endpoint válido e atacável.
4. Apostar só em WAF: Falhas de lógica de autorização passam despercebidas por filtros baseados em assinatura.
5. Ignorar o consumo: Sem rate limiting e cotas, abuso e custos descontrolados chegam antes do invasor sofisticado.

Como construir um programa contínuo de proteção de APIs

Shift-left: segurança no design

A segurança da API começa no whiteboard. O Threat Modeling em design review elimina classes inteiras de bugs antes do primeiro commit. É possível estruturar essa etapa em cinco tópicos: quem chama, o que pode fazer, qual dado retorna, como rate-limit e como audita.

Testes automatizados + pentest manual

DAST e SAST automatizados rodam em pipeline e capturam regressões, mas só o pentest manual encontra business logic abuse, BOLA complexa que envolve múltiplos endpoints e cadeias de vulnerabilidades. Os dois são complementares.

Métricas que importam

• MTTR (Mean Time to Remediate) segmentado por severidade da vulnerabilidade.
• Percentual de endpoints cobertos por testes automatizados em CI.
• Idade média das vulnerabilidades abertas no backlog de segurança.
• Cobertura de discovery: APIs descobertas vs APIs documentadas oficialmente.
• Número de incidentes de produção atribuíveis a falhas de API por trimestre.

Checklist de Segurança de APIs

Quem trabalha com pentest de API há algum tempo percebe um padrão: as mesmas falhas aparecem em empresas diferentes, ano após ano. O principal motivo é a ausência de uma checagem sistemática antes do código chegar à produção.

Este checklist consolida o que a equipe da Vantico testa em todo pentest de API. A ideia é usar como referência durante code review, antes de subir uma feature crítica para produção, ou como pauta de threat modeling com o seu time. 

São 60 verificações organizadas em 10 categorias. Não há ordem obrigatória, mas a sequência abaixo reflete onde a maioria das APIs falha primeiro.

• Autenticação

Tudo começa por saber quem está chamando. Tokens mal implementados são responsáveis por uma fatia generosa dos achados críticos em pentests, e o mais frustrante é que quase todos têm uma correção barata.

• O algoritmo de assinatura JWT é fixo no servidor. Nunca confie no campo alg do header. Se a configuração permite RS256 e HS256, o atacante usa a confusão para forjar tokens.
• Algoritmo “none” está explicitamente bloqueado. Algumas bibliotecas legadas aceitam por padrão. Teste enviando um token sem assinatura e veja se cai em 401.
• Tokens de acesso têm expiração curta. Entre 15 minutos e 1 hora é o esperado para a maioria dos casos. Tokens válidos por dias ou semanas são chaves de longa duração esperando para vazar.
• Refresh tokens rotacionam a cada uso. O token novo invalida o anterior e o uso duplicado dispara alerta e desautoriza a sessão.
• Existe forma de revogar tokens emitidos, como logout do usuário, desligamento de funcionário e suspeita de comprometimento. Sem revogação, o token vale até expirar naturalmente.
• Segredos de assinatura são longos e rotacionáveis: um mínimo de 256 bits para HS256. Processo definido para rotação periódica e em caso de incidente.
• Endpoint de login tem proteção contra brute force: Lockout temporário por usuário e por IP, com janela exponencial, e CAPTCHA depois de N falhas. Alerta para múltiplas falhas no mesmo IP.
• Fluxo de reset de senha é resistente ao abuso. Token de uso único, expiração de até 1 hora, rate limiting por email e por IP, e nenhuma informação sobre a existência da conta na resposta.

• Autorização (BOLA, BFLA e BOPLA)

A autenticação resolve quem é o usuário e a autorização resolve o que ele pode fazer. A maior fatia dos achados críticos da Vantico está nesta etapa.

• A autorização é centralizada em uma camada única. Middleware, policy, guard ou serviço dedicado. Nunca distribuída como verificações soltas em cada controller.
• Toda rota verifica a propriedade do objeto. Antes de retornar /pedidos/123, confirme que o pedido pertence ao usuário autenticado. Vale para GET, PATCH, DELETE e qualquer outro método.
• Padrão de design é “negar por padrão”. Endpoint novo deve falhar até ser explicitamente liberado para um perfil. O inverso (liberar tudo e bloquear depois) sempre deixa o endpoint esquecido.
• Endpoints administrativos validam o papel do usuário. Não basta exigir autenticação. /admin/* precisa exigir role apropriada no token, validada no servidor.
• Identificadores expostos são UUIDs ou opacos. IDs sequenciais facilitam a enumeração. A UUID não substitui a checagem de autorização, mas eleva o custo do ataque.
• Em ambientes multi-tenant, tenant_id sai do token, mas nunca do payload. O cliente jamais deve poder informar qual tenant está acessando. Esse dado vem da identidade autenticada e nada mais.
• Cross-tenant access é testado em integração contínua. Série de testes que tenta acessar recursos do tenant B com o token do tenant A e exige 403 ou 404. Roda a cada build.
• Endpoints de listagem filtram pelo usuário no banco, não em código de aplicação. WHERE usuario_id = :id no SQL. Filtrar depois de buscar tudo, em Python ou Node, abre brecha de timing e de bypass por erro de paginação.

• Validação de entrada e schema

Validar payload é o que separa uma API robusta de uma API que aceita qualquer coisa que o cliente mandar.

• O schema de entrada é validado no servidor para todo endpoint. JSON Schema, Pydantic, Zod ou class-validator. Recusar 400 quando o payload não bate.
• Mass assignment está bloqueado. Whitelist explícita dos campos aceitos em cada endpoint. Nada de bind automático do JSON inteiro no modelo de banco.
• Tipos são validados rigorosamente. Esperava um inteiro positivo? Rejeite string, negativo, float, array. A quantidade negativa do checkout virou crédito mais de uma vez em pentest.
• Tamanhos máximos estão definidos em todo campo de texto. Sem limite, o atacante envia 50MB no campo “nome” e derruba o serviço.
• Conteúdo enviado em uploads tem tipo e tamanho validados no servidor. Magic bytes, não confiança em extensão ou Content-Type do cliente. Tamanho máximo definido por endpoint.
• Queries SQL e comandos shell usam parâmetros, nunca concatenação. ORM, prepared statements, parameterized queries. Mesma regra para NoSQL: query objects, não strings montadas.

• Rate limiting e proteção contra abuso

A API que aceita 100 mil requisições por minuto sem se importar com quem está mandando é a API onde o atacante mora confortavelmente.

• Rate limiting global está ativo no API gateway. Por IP e por token. Linha de base que cobre toda a superfície.
• Endpoints sensíveis têm limites próprios mais agressivos. Login, reset de senha, OTP, criação de conta, aplicação de cupom, envio de SMS. Cada um com seu próprio teto.
• Endpoints com custo financeiro têm proteção dedicada. Envio de SMS e push, geração de PDF, chamada para LLM, processamento de imagem. Atacante usa para esgotar o orçamento (SMS pumping é o exemplo clássico).
• A paginação tem limite máximo aplicado no servidor. ?limit=999999 deve ser silenciosamente reduzido para o máximo permitido (50, 100, 200). Sem isso, o atacante baixa toda a base em uma requisição.
• Existem alertas para padrões de abuso. Mesmo token tocando muitos IDs sequenciais em janela curta, mesmo IP criando muitas contas, mesmo email aparecendo em muitas tentativas de login.
• Lógica de negócio tem proteção contra repetição abusiva. Cupom de desconto unicidade por conta, bônus de cadastro vinculado ao CPF e ao dispositivo, limite de tentativas em fluxos críticos. Esses bugs nunca aparecem em scanner automatizado.

• Exposição de dados sensíveis

APIs vazam dados que ninguém pediu, em respostas que parecem inocentes. Vale o esforço de revisar o que cada endpoint está realmente devolvendo.

• Respostas devolvem apenas os campos necessários. Nada de retornar o objeto inteiro do banco. Use DTOs, serializers ou response models que listam explicitamente o que sai.
• Dados sensíveis nunca aparecem em URL. Token, CPF, senha, chave de API não vão na query string. Logs de webserver e referers vazam tudo isso para terceiros.
• Senhas e segredos não aparecem em logs. Filtro de logging que sanitiza campos conhecidos (password, token, cvv, secret). Verifique também o que vai para APMs e error trackers.
• Mensagens de erro não vazam a estrutura interna. Stack trace, query SQL bruta, nome de tabela e caminho de arquivo não chegam ao cliente em produção. Em homologação, blindar com auth básica.
• Endpoints de autenticação devolvem mensagens neutras. “Credenciais inválidas” para login e reset. Diferenciar “usuário não existe” de “senha errada” entrega a lista de e-mails válidos para o atacante.

• SSRF e integrações com URLs externas

Todo endpoint que recebe URL é um endpoint que pode ser apontado para a rede interna. Em ambientes cloud, é o atalho preferido para escalada.

• Endpoints que aceitam a URL do usuário usam uma allowlist de hosts. Webhook, importador de imagem, gerador de preview, conector OAuth. Lista de domínios permitidos, não lista de domínios bloqueados.
• Resolução de DNS recusa ranges privados e link-local. 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16, fc00::/7, fe80::/10. Validar após resolução, não antes.
• Redirects são validados (ou desabilitados) na camada de fetch. Resposta com 302 para 169.254.169.254 derrota allowlist ingênua. Forçar revalidação a cada hop.
• Em AWS, IMDSv2 é obrigatório em todas as instâncias e workers. Cobre o pior caso de SSRF interno: roubo de credenciais da role da máquina. Configurável em launch template.
  

• Configuração de servidor e headers HTTP

Detalhes de configuração que escapam em deploy, sendo um achado de fácil identificação e correção. 

• CORS está configurado com origem específica, nunca com curinga em rotas autenticadas. Access-Control-Allow-Origin com Access-Control-Allow-Credentials=true e curinga é configuração inválida que algumas libs aceitam mesmo assim.
• Headers de segurança estão presentes nas respostas. Strict-Transport-Security, X-Content-Type-Options: nosniff, Content-Security-Policy nas rotas que servem HTML.
• TLS está configurado com versões e cifras modernas. TLS 1.2 no mínimo, idealmente 1.3. Sem SSLv3, RC4, MD5. Validável com testssl.sh ou SSL Labs.
• Debug, profiler e ferramentas de desenvolvedor estão desligados na produção. Django debug, Flask debug, Spring actuator sem proteção, debug.log expostos. Nunca confie que o cliente não vai descobrir o caminho.
• Banners e headers de versão de framework estão ocultos. Não impede ataques dedicados, mas elimina ataques oportunistas que filtram alvos por versão vulnerável conhecida.
• Métodos HTTP não usados estão bloqueados por rota. Endpoint GET-only deveria recusar POST, PUT, DELETE com 405. Frameworks deixam métodos abertos por padrão se você não declarar.
  

• Logging, monitoramento e resposta

Sem visibilidade, o incidente acontece e ninguém percebe até o cliente reclamar.

• Eventos de autenticação são logados com contexto. Sucesso, falha, lockout, mudança de senha, mudança de email, criação de token. Sempre com IP, user agent, timestamp e identificador de sessão.
• Falhas de autorização (401, 403) geram log estruturado. Quem tentou, qual recurso, quando. O pico repentino dessas falhas é sinal de pentest, scanner ou ataque.
• Operações sensíveis têm uma trilha de auditoria imutável. Transferência, exclusão, mudança de permissão, alteração de dados cadastrais. Log em destino separado, fora do alcance do app.
• Alertas estão configuradas para padrões de abuso. Picos de 4xx, mesmo token acessando muitos IDs, login bem-sucedido de localização incomum, criação massiva de contas.
• Time de segurança recebe os alertas e tem playbook. Alerta sem dono é alerta ignorado. Defina quem responde, em que prazo, com qual ação inicial.

• Inventário e versionamento

Um endpoint esquecido aparece no relatório de pentest, sendo um dos principais prejuízos em grandes organizações.

• Existe inventário ativo e atualizado de endpoints expostos. Não é um documento estático em Confluence. Coleta automática a partir do código, do API gateway ou de descoberta passiva. Atualização contínua.
• Versões antigas de API têm data de desligamento definida. v1 que continua respondendo seis meses depois do lançamento da v2 tende a ficar para sempre. Defina sunset desde o lançamento da versão seguinte.
• Ambientes de staging, homologação e desenvolvimento não estão indexados publicamente. Robots.txt e meta noindex são paliativos. O correto é estar atrás de autenticação ou em rede restrita.
• Documentação da API (Swagger, OpenAPI, Postman público) não vaza endpoints internos. Quando exposta, deve refletir o que é público. Endpoints administrativos jamais devem aparecer ali.

• Processo de segurança contínua

Cinco itens que separam empresas que tratam a segurança como projeto pontual das que a tratam como ação contínua.

• Pentest de API é executado pelo menos uma vez por ano. Para APIs em fintechs, healthtechs e plataformas com dados sensíveis, recomenda-se um ciclo semestral. Após mudança arquitetural relevante, fora do ciclo.
• Code review tem trilha obrigatória de segurança em mudanças sensíveis. Toda alteração em autenticação, autorização, fluxo financeiro ou tratamento de dado pessoal exige revisor além do par.
• Pipeline de CI inclui análise estática (SAST) e checagem de dependências. Não substitui pentest, mas pega a baixa hanging fruit antes do deploy. Resultado vinculado ao PR.
• Threat modeling acontece no início de uma feature relevante. Antes da primeira linha de código. Mesmo um STRIDE de 30 minutos com o time evita uma boa parte dos achados do pentest depois.
• Existe canal definido para divulgação responsável de vulnerabilidades. Página /security.txt ou /seguranca, com email dedicado e expectativa de resposta. Pesquisadores externos costumam encontrar coisas antes do atacante.

Como interpretar o resultado do seu checklist

Depois de passar o checklist, conte os itens não resolvidos. É possível delimitar em:

• Até 5 itens em aberto: maturidade saudável. Foque em automatizar o que ainda depende de processo manual.
• Entre 6 e 15 itens em aberto: perfil comum em empresas em crescimento rápido. Priorize as categorias 2 (autorização) e 4 (rate limiting), que costumam render os achados mais graves.
• Mais de 15 itens em aberto: sua API está exposta a achados críticos. Não é exagero contratar um pentest e usar o relatório como roadmap dos próximos sprints.

Vale lembrar que o checklist é mínimo. Cumprir os 60 itens não garante uma API segura, mas garante que os bugs mais comuns deixam de ser óbvios. Falhas de lógica de negócio específicas do seu produto continuam sendo o terreno onde apenas um humano olhando com cuidado encontra.

Esse checklist serve para API GraphQL e gRPC?

A maioria dos itens, sim. Autenticação, autorização, validação, rate limiting, logging e processo aplicam-se de forma equivalente. Em GraphQL há cuidados adicionais, como limite de profundidade de query, complexidade de resolver e introspecção em produção. Em gRPC, a camada de transporte muda, mas os princípios continuam.

Quanto tempo leva para passar uma API média por esse checklist?

Para uma API com 50 a 100 endpoints, um engenheiro experiente leva entre 4 e 8 horas de revisão focada. Em equipe, divididos por categoria, costumam fechar em uma sprint.

O checklist substitui um pentest profissional?

Não. O checklist cobre o que aparece com regularidade, mas falhas de lógica de negócio específicas do seu produto exigem alguém olhando o domínio com hostilidade. Pentest e checklist são complementares: o checklist garante a linha de base e o pentest encontra o que é único à sua API.

É realista cumprir os 60 itens em uma startup pequena?

Sim, embora demande priorização. Recomendamos começar pelas categorias 1, 2, 3 e 5 (autenticação, autorização, validação de entrada, exposição de dados), que cobrem a maior parte dos achados críticos. 

Cada API é um ativo crítico

As maiores violações ligadas a APIs surgem do que está sem gestão, sem teste e sem rastreamento: um endpoint esquecido, uma autorização que ninguém checou, uma configuração padrão que ficou para trás. Em contrapartida, como a vasta maioria dos ataques mapeia para o OWASP API Security Top 10, o risco é amplamente previsível e mitigável com disciplina de engenharia.

Perguntas frequentes (FAQ)

Qual é a vulnerabilidade de API mais comum?

A Broken Object Level Authorization (BOLA / API1) lidera todas as edições do OWASP API Security Top 10. É a falha em que a API não verifica se o usuário tem permissão sobre o objeto solicitado, permitindo acessar dados de terceiros apenas trocando um identificador.

OWASP API Top 10 é o mesmo que o OWASP Top 10 tradicional?

Não. O OWASP Top 10 tradicional é uma referência inicial que foca em vulnerabilidades de aplicações web (como XSS e injeção). O OWASP API Security Top 10 é uma lista específica para APIs, centrada em falhas de autorização, abuso de fluxos de negócio e configuração, riscos que scanners genéricos costumam não detectar.

Um WAF é suficiente para proteger minhas APIs?

Não isoladamente. WAFs ajudam contra ataques conhecidos baseados em padrão, mas a maioria das falhas críticas de API é de erros de lógica de autorização, em que a requisição é perfeitamente válida. A defesa eficaz combina autorização correta no código, gestão de inventário, testes contínuos e monitoramento em runtime.

Com que frequência devo testar a segurança das minhas APIs?

Testes automatizados (SAST, DAST, testes de contrato) devem rodar a cada build no CI/CD. Pentests manuais focados em lógica de autorização e abuso de fluxos são recomendados de forma recorrente e sempre que houver mudanças significativas de arquitetura.

Como a IA generativa muda o risco de APIs?

Agentes de IA chamam APIs em nome do usuário e podem pular checagens de autorização, recriando BOLA. Prompt injection pode induzir requisições internas (SSRF), e pipelines que consomem respostas de terceiros sem validar ampliam o consumo inseguro. Combine o OWASP API Top 10 com o OWASP Top 10 for LLM Applications.

Quanto custa um vazamento por falha em API?

Custos variam por setor e volume. Estudos do IBM Cost of a Data Breach apontam média global na casa dos US$ 4,5 milhões por incidente (IBM, 2024). Para empresas brasileiras com dados pessoais expostos, somam-se multas da LG