Pentest Web e de API: guia técnico completo

Web e APIs são hoje a maior superfície de ataque de qualquer empresa digital. Toda funcionalidade nova é uma rota nova; toda integração externa é uma porta nova. Este guia explica como conduzimos pentest web e de API com profundidade técnica, e o que esperar como cliente.

Pentest Web: o que é testado

Um pentest web vai além de rodar um scanner. Ele cobre:

• Autenticação: brute force, falhas em recuperação de senha, MFA bypass, session fixation, cookies inseguros
• Autorização: IDOR, escalada vertical/horizontal de privilégios, bypass de role
• Injeções: SQLi, NoSQLi, command injection, LDAP injection, SSTI
• XSS: reflected, stored, DOM-based — e suas variações em frameworks SPA
• SSRF: server-side request forgery, metadata leakage em ambientes cloud
• Desserialização insegura em endpoints que aceitam dados estruturados
• Falhas em uploads de arquivo (path traversal, RCE via extensão, abuso de armazenamento)
• CSRF e falhas em proteção contra cross-site
• Lógica de negócio: bypass de fluxos, race conditions, abuso de cupons, manipulação de preço

Referências obrigatórias

OWASP Top 10 é o ponto de partida — não a meta. Um pentest sério usa também o OWASP ASVS (Application Security Verification Standard) como checklist de profundidade, e o OWASP Testing Guide como manual de execução.

Pentest de API: por que é diferente

APIs não têm interface visual para guiar o testador, são consumidas por código (mobile, frontend, parceiros), aceitam estruturas de dados complexas e frequentemente expõem mais funcionalidade do que o frontend usa. Resultado: a superfície real é maior que a aparente.

OWASP API Top 10

O OWASP API Security Top 10 categoriza as principais falhas. Os mais frequentes na prática:

• API1 — BOLA (Broken Object Level Authorization): trocar um ID de objeto na URL e acessar dado de outro usuário. Disparado por todo pentest minimamente competente.
• API2 — Broken Authentication: tokens previsíveis, JWT sem assinatura validada, refresh tokens infinitos.
• API3 — Broken Object Property Level Authorization: mass assignment (alterar campos que não deveriam ser editáveis pelo usuário, ex.: isAdmin: true).
• API4 — Unrestricted Resource Consumption: ausência de rate limiting, paginação abusiva, ataques de negação de serviço de baixo custo.
• API5 — BFLA (Broken Function Level Authorization): acessar endpoints administrativos com token de usuário comum.
• API6 — Unrestricted Access to Sensitive Business Flows: abuso de fluxos de negócio (criação massiva de contas, scraping de preços, fraude em cashback).
• API8 — Security Misconfiguration: CORS aberto, headers ausentes, error verbosity em produção.
• API9 — Improper Inventory Management: versões antigas (v1, v2-beta) ainda no ar, sem patches.
• API10 — Unsafe Consumption of APIs: sua API confiar em APIs externas sem validar resposta.

Fases práticas

1. Reconhecimento

Coletar todos os endpoints. Para web: crawling autenticado, análise de JavaScript bundles, sourcemap, wayback machine, GitHub leaks. Para API: pegar a documentação OpenAPI/Swagger se houver, capturar tráfego do app mobile, inspecionar o frontend.

2. Mapeamento de fluxos

Entender quais são os fluxos de negócio. Cadastro, login, recuperação, transação financeira, integração com terceiros. Cada fluxo tem premissas que podem ser quebradas.

3. Análise de autorização

Crie pelo menos duas contas de teste. Para cada endpoint que retorna ou modifica dado: teste se conta A consegue acessar dado de conta B trocando IDs. Teste se usuário comum consegue chamar endpoints administrativos.

4. Testes de injeção

Para cada parâmetro de entrada, testar payloads de SQLi, XSS, command injection, SSRF. Em APIs JSON, testar manipulação de tipos (string vira array, string vira objeto), comentários, encodings duplos.

5. Testes de lógica de negócio

Aqui mora o ouro. Pular etapas de um fluxo de checkout, repetir uma chamada de cashback, manipular valor em campo escondido, criar conta com email já existente, escalar privilégios via convite. Scanners não pegam isso.

6. Pós-exploração e impacto

Cada vulnerabilidade ganha um CVSS, um risco de negócio e uma prova de impacto. Sem impacto demonstrado, fica difícil priorizar.

7. Relatório e retest

Entrega-se relatório executivo (para liderança), relatório técnico (para devs e segurança) com cada finding, evidências e remediação. Após correção, retest valida o fix.

Ferramentas comuns

Burp Suite Professional, OWASP ZAP, Postman/Insomnia para API, ffuf para fuzzing, sqlmap para SQLi, nuclei para checks automatizados, Caido (alternativa moderna ao Burp), JWT_Tool para tokens, e muito trabalho manual em proxies. Ferramentas são acelerador — não substituem cérebro.

Conclusão

Pentest web e de API exigem método, profundidade técnica e validação manual. O resultado de qualidade não é uma lista de findings genéricos do scanner — é um mapa do que está realmente quebrado, com priorização real e plano de correção viável.