Segurança de APIs (REST e GraphQL): guia técnico de proteção, OWASP API Top 10 e pentest

Por que APIs são o principal vetor de ataque hoje

As APIs deixaram de ser detalhe de integração para virar a superfície de ataque dominante das aplicações modernas. Em fintechs, apps móveis, crypto e e-commerces, praticamente toda a lógica de negócio — pagamentos, saldos, KYC, ordens, transferências — trafega por endpoints REST ou GraphQL consumidos por front-ends SPA, apps nativos e parceiros B2B. Cada endpoint exposto é uma porta direta para os dados e operações mais sensíveis, sem o intermediário de uma renderização server-side que historicamente filtrava acessos.

O deslocamento do risco para a camada de API tem três causas estruturais. Primeiro, a explosão do número de endpoints: microsserviços e BFFs (Backend for Frontend) multiplicam APIs internas e externas mais rápido do que as equipes conseguem inventariar. Segundo, a natureza programática do consumo: um atacante não precisa de browser nem de engenharia social — basta um cliente HTTP, um token e a capacidade de iterar parâmetros (IDs, filtros, paginação) em alta velocidade. Terceiro, falhas de autorização que ferramentas genéricas não detectam: um WAF baseado em assinaturas não sabe que o usuário A não deveria acessar a conta do usuário B, porque a requisição é sintaticamente perfeita.

Em fintechs o impacto é financeiro e regulatório imediato. Uma falha de BOLA (autorização quebrada em nível de objeto) que permita trocar account_id na URL e ler o extrato de outro cliente é, simultaneamente, vazamento de dado pessoal sob a LGPD, descumprimento de requisitos do Open Finance e risco de fraude direta. APIs também concentram automação de fraude: credential stuffing, abuso de cupons, scraping de preços e criação massiva de contas falsas ocorrem quase sempre via API, não pela interface web. Tratar segurança de API como um problema separado da segurança de aplicação — com inventário, autorização e testes próprios — deixou de ser opcional.

OWASP API Security Top 10 2023: as falhas que dominam o risco

O OWASP API Security Top 10 2023 é o framework de referência para classificar riscos de API. Diferente do Top 10 web tradicional, ele foi reescrito para refletir falhas específicas de APIs, com destaque para autorização. A lista completa: API1 Broken Object Level Authorization (BOLA), API2 Broken Authentication, API3 Broken Object Property Level Authorization (BOPLA), API4 Unrestricted Resource Consumption, API5 Broken Function Level Authorization, API6 Unrestricted Access to Sensitive Business Flows, API7 Server Side Request Forgery (SSRF), API8 Security Misconfiguration, API9 Improper Inventory Management e API10 Unsafe Consumption of APIs.

BOLA (API1) é a falha número um desde 2019 e segue no topo. Ocorre quando a API valida que o usuário está autenticado, mas não verifica se aquele usuário específico tem direito ao objeto requisitado. Exemplo: GET /api/v2/accounts/1042/statement retorna o extrato sem checar se o token pertence ao dono da conta 1042 — trocar o ID por 1043 vaza dados alheios. É a base do IDOR (Insecure Direct Object Reference). A defesa não é ocultar o ID, e sim impor uma checagem de propriedade no servidor a cada acesso a cada objeto.

API2 (Broken Authentication) cobre tokens previsíveis, JWT mal validados, ausência de expiração, recuperação de senha frágil e endpoints de login sem proteção contra força bruta. API3 (BOPLA) fundiu os antigos Excessive Data Exposure e Mass Assignment: a API retorna campos sensíveis que o cliente não deveria ver (CPF, hash de senha, flags internas) ou aceita campos que o cliente não deveria escrever (is_admin, balance) por aceitar o objeto inteiro sem allow-list de propriedades.

API4 (Unrestricted Resource Consumption) trata da ausência de limites — sem rate limiting, sem teto de tamanho de payload, sem paginação obrigatória — levando a negação de serviço e custos descontrolados (especialmente grave em GraphQL com queries aninhadas profundas). API5 (Broken Function Level Authorization) é o acesso a funções administrativas por usuários comuns, como chamar DELETE /api/admin/users sem papel de admin. API6 cobre abuso de fluxos legítimos (compra de ingressos, criação de contas) em escala automatizada. API7 (SSRF) ocorre quando a API busca uma URL fornecida pelo cliente sem validação, permitindo alcançar serviços internos e metadados de nuvem. API8, API9 e API10 cobrem configuração insegura, inventário deficiente (shadow/zombie APIs) e consumo inseguro de APIs de terceiros.

Autenticação e autorização: OAuth2, OIDC, JWT, mTLS e escopos

Autenticação e autorização são problemas distintos e ambos precisam ser resolvidos no servidor. Autenticação responde quem é o chamador; autorização responde o que ele pode fazer e sobre quais objetos. Em APIs, o padrão é OAuth 2.0 (com OpenID Connect para identidade) emitindo tokens de acesso de curta duração. Use o Authorization Code Flow com PKCE para apps móveis e SPAs, e Client Credentials para comunicação serviço-a-serviço. Evite o Implicit Flow e o Resource Owner Password Credentials, ambos depreciados pelas práticas atuais do OAuth.

JWT é seguro quando validado corretamente, e inseguro por padrão se não for. As regras mínimas: rejeite o algoritmo none; fixe o algoritmo esperado no servidor em vez de confiar no header alg (impede o ataque de confusão RS256→HS256); valide assinatura, emissor (iss), audiência (aud) e expiração (exp) em toda requisição; mantenha tokens de acesso curtos (5 a 15 minutos) e use refresh tokens rotacionados com possibilidade de revogação. JWT é stateless e não é trivialmente revogável — para sessões sensíveis, mantenha uma denylist de tokens revogados ou prefira tokens de referência (opacos) resolvidos contra um servidor de introspecção.

mTLS (TLS mútuo) eleva a garantia de identidade no tráfego serviço-a-serviço e em integrações reguladas: ambos os lados apresentam certificado, e a conexão só é estabelecida entre partes comprovadamente autorizadas. É o padrão para Open Finance no Brasil e para malhas internas de microsserviços (service mesh), onde complementa o OAuth com identidade criptográfica de carga de trabalho. Escopos OAuth (scopes) restringem o que um token pode fazer de forma grossa (payments:read vs payments:write); são necessários mas não suficientes.

A peça que mais falha é a autorização objeto a objeto. Escopo concede a capacidade de ler pagamentos; ele não verifica se este pagamento pertence a este usuário. Toda operação sobre um objeto identificável precisa de uma checagem de propriedade ou de política no servidor, derivada da identidade do token e nunca de um parâmetro controlado pelo cliente. Centralize essa decisão numa camada de autorização (por exemplo, um motor de políticas como OPA/Rego ou um middleware de ABAC/ReBAC) para evitar checagens dispersas e inconsistentes que originam o BOLA.

Rate limiting e proteção contra abuso

Rate limiting controla a frequência de chamadas e é a defesa direta contra API4 (consumo irrestrito de recursos) e contra automação de fraude. Limites genéricos por IP são facilmente contornados com rotação de IPs e proxies residenciais; a abordagem robusta aplica limites em múltiplas dimensões — por consumidor (client_id ou usuário autenticado), por endpoint e por tipo de operação — usando algoritmos como token bucket ou sliding window. Endpoints de alto custo ou alto risco (login, OTP, criação de conta, busca, exportação) devem ter limites mais estritos do que leituras triviais.

Além do limite numérico, configure tetos de recurso por requisição: tamanho máximo de payload, profundidade e complexidade máxima de query (crítico em GraphQL, onde uma única query aninhada pode forçar milhares de resoluções e derrubar o backend), número máximo de itens por página e timeout de execução. Em GraphQL, aplique análise de custo de query, limites de profundidade e desabilite a introspecção em produção para reduzir a superfície de reconhecimento.

Para abuso de fluxos de negócio (API6), rate limiting puro não basta: é preciso detectar intenção. Proteja login e operações sensíveis com defesas contra credential stuffing — bloqueio progressivo, CAPTCHA adaptativo, device fingerprinting e detecção de comportamento anômalo (muitas contas distintas de um mesmo dispositivo, padrões não humanos de timing). Sempre responda com 429 Too Many Requests e cabeçalhos Retry-After e de quota (RateLimit-*), e registre os eventos de limite excedido como sinal para o SOC, pois eles frequentemente antecedem campanhas de ataque maiores.

API gateway, WAAP e descoberta de shadow e zombie APIs

O API gateway é o ponto único de entrada onde se centraliza autenticação, terminação TLS, roteamento, rate limiting e logging. Concentrar essas funções no gateway reduz inconsistência entre serviços e cria um ponto de observação para todo o tráfego. Sobre ele, um WAAP (Web Application and API Protection) — a evolução do WAF clássico — adiciona proteção específica de API: validação de conformidade com o schema OpenAPI/GraphQL, detecção de anomalias por consumidor, bloqueio de bots, mitigação de DDoS na camada de aplicação e correlação de sinais para identificar abuso de lógica de negócio que assinaturas estáticas não pegam.

Nenhuma dessas defesas alcança um endpoint que a equipe não sabe que existe. Shadow APIs são endpoints não documentados ou não governados — expostos por um deploy esquecido, um ambiente de teste em produção ou um microsserviço que ninguém mapeou. Zombie APIs são versões antigas (v1, v2-beta) que permaneceram online após serem substituídas, frequentemente sem os patches e controles das versões atuais. Ambas correspondem a API9 (Improper Inventory Management) e são alvo preferencial porque escapam do gateway e do WAAP.

A descoberta precisa ser contínua, não um inventário pontual. Combine análise de tráfego real (descoberta passiva a partir de logs de gateway, mirror de rede ou agentes) com varredura ativa de hosts e ranges, geração automática de especificação OpenAPI a partir do tráfego observado e reconciliação contra o inventário oficial para flagrar divergências. Cada API descoberta deve ter dono, classificação de dados, versão e data de descontinuação registrados. Sem inventário vivo, métricas de cobertura de segurança de API são fictícias.

Testar segurança de API: pentest de API na prática

Scanners automáticos e DAST genéricos encontram problemas de configuração e injeções clássicas, mas são estruturalmente cegos às principais falhas de API. BOLA, BOPLA e Broken Function Level Authorization são falhas de lógica de autorização: a requisição é válida, o status é 200, e só um testador que entende o modelo de negócio sabe que o usuário A não deveria ter acessado o objeto do usuário B. Por isso o pentest de API é majoritariamente manual e orientado a contexto, complementado por automação.

Um pentest de API conduzido pela Decripte segue um método alinhado ao OWASP API Top 10 2023. Começa pela descoberta e inventário (incluindo shadow e zombie APIs) e pela coleta da especificação OpenAPI/GraphQL e do fluxo de autenticação. Em seguida, testa autorização com múltiplas contas e papéis em paralelo: para cada objeto acessível pelo usuário A, tenta-se acessá-lo com o token do usuário B (BOLA), manipula-se propriedades sensíveis em escritas (BOPLA/mass assignment) e tenta-se invocar funções administrativas com papéis comuns (BFLA).

O escopo cobre ainda autenticação (validação de JWT, expiração, força bruta, fluxos de OAuth e recuperação de senha), consumo de recursos (ausência de rate limiting, queries GraphQL custosas), SSRF em campos que aceitam URLs, abuso de fluxos de negócio e configuração (CORS permissivo, verbos HTTP indevidos, mensagens de erro vazando stack traces, headers de segurança ausentes). Cada achado é entregue com prova de conceito reproduzível, classificação de severidade e correção concreta.

Segurança de API é um ciclo, não um evento. Integre testes de autorização e validação de contrato no CI/CD, faça pentest manual a cada mudança relevante de superfície e mantenha monitoramento contínuo no SOC. A Decripte faz pentest de API para fintechs e apps, atua na implementação dos controles e mantém SOC 24x7 com SLA de contenção de incidente crítico em até 1 hora — porque encontrar a falha e conter sua exploração são partes do mesmo problema.

Passo a passo

1. Inventarie e descubra todas as APIs: gere a especificação OpenAPI/GraphQL, mapeie endpoints por análise de tráfego e varredura ativa, e elimine shadow e zombie APIs com inventário vivo (dono, dados, versão, descontinuação).
2. Implemente autenticação forte: OAuth2/OIDC com Authorization Code + PKCE para apps e SPAs, Client Credentials e mTLS entre serviços, e tokens de acesso curtos com refresh rotacionado e revogável.
3. Imponha autorização objeto a objeto no servidor: valide propriedade de cada objeto a partir da identidade do token (contra BOLA/IDOR), aplique allow-list de propriedades em escritas (contra mass assignment) e cheque papéis em funções administrativas.
4. Valide entrada e contrato: rejeite payloads fora do schema OpenAPI/GraphQL, limite tamanho de payload, profundidade e custo de query, e nunca exponha campos sensíveis em respostas.
5. Aplique rate limiting e proteção contra abuso: limites por consumidor e por endpoint, defesas contra credential stuffing em login/OTP, e respostas 429 com Retry-After registradas como sinal para o SOC.
6. Proteja a borda com API gateway e WAAP: centralize TLS, auth e logging no gateway, adicione validação de schema, detecção de anomalias por consumidor, mitigação de bots e DDoS de aplicação.
7. Teste continuamente: pentest de API manual alinhado ao OWASP API Top 10 2023 com múltiplas contas e papéis, testes de autorização e contrato no CI/CD, e monitoramento 24x7 com plano de resposta a incidentes.

Perguntas frequentes