Depois de centenas de horas fazendo testes de invasão em empresas brasileiras de diferentes portes e setores, alguns padrões ficam impossíveis de ignorar. As mesmas categorias de vulnerabilidades aparecem com uma frequência preocupante, e muitas delas poderiam ser evitadas com práticas de desenvolvimento e operação que já são conhecidas há anos.
Este artigo reúne as falhas que mais encontramos em projetos reais de pentest. O objetivo não é criar uma checklist genérica, mas mostrar onde atacantes de verdade encontram caminhos nas organizações brasileiras.
1. Broken Access Control
De longe, a vulnerabilidade mais comum e mais impactante que encontramos. Falhas de controle de acesso permitem que um usuário acesse dados ou funcionalidades que não deveria, e os resultados podem ser devastadores.
Na prática, isso aparece como APIs que retornam dados de qualquer usuário quando você troca o ID na requisição (o famoso IDOR), painéis administrativos acessíveis sem autenticação por URL direta, endpoints que verificam se o usuário está logado mas não verificam se ele tem permissão, e usuários comuns que conseguem executar ações de administrador manipulando parâmetros.
Esse tipo de falha é tão comum porque controle de acesso é difícil de automatizar. Diferente de SQL injection ou XSS, não existe WAF que resolva. Cada regra de negócio precisa de validação explícita no backend. E quando o time de desenvolvimento está com prazo apertado para entregar features, essas validações ficam para "depois". E "depois" vira "nunca".
O caminho para resolver passa por implementar validação de autorização em cada endpoint do backend (não apenas no frontend), adotar o princípio de menor privilégio, criar testes automatizados para regras de acesso e realizar code review focado em fluxos de autorização.
2. Credenciais fracas e senhas padrão
Parece coisa básica, mas continua sendo uma das formas mais fáceis de conseguir acesso inicial. Em quase todo pentest de infraestrutura, achamos pelo menos um serviço com credenciais padrão ou senhas triviais.
O cenário típico é encontrar painéis de administração com admin/admin ou admin/123456, bancos de dados com senha root vazia, servidores com SSH acessível e senha fraca, contas de serviço que nunca tiveram a senha trocada desde a implantação, e contas de teste que alguém esqueceu de remover antes de ir para produção.
A solução não é complicada: política de senhas com complexidade mínima, rotação obrigatória de credenciais de serviço, varredura periódica em busca de padrões, MFA em todos os acessos administrativos e remoção de contas de teste antes do deploy.
3. SQL Injection
Uma vulnerabilidade que existe há mais de 25 anos e que ainda aparece com frequência preocupante, especialmente em sistemas legados e aplicações feitas por equipes sem treinamento em segurança.
Os casos mais comuns são campos de busca e filtros que jogam o input do usuário direto na query SQL, APIs que aceitam parâmetros sem sanitização, e sistemas legados em PHP ou ASP clássico sem qualquer proteção.
Pra dar uma dimensão do impacto: em um único teste, conseguimos extrair toda a base de dados de clientes (incluindo dados pessoais sensíveis) através de um campo de busca em uma área logada. O ataque levou menos de 30 minutos desde a identificação até a extração completa.
A correção é usar queries parametrizadas ou prepared statements em 100% dos casos, implementar ORM quando possível, validar e sanitizar todo input do usuário e usar WAF como camada adicional, nunca como proteção única.
4. Configurações incorretas de segurança
Servidores, clouds e aplicações que saem com configuração padrão e nunca são ajustados para produção. É uma classe ampla que inclui dezenas de cenários diferentes.
O que encontramos na prática inclui headers HTTP de segurança ausentes (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security), diretórios de listagem habilitados em servidores web, páginas de debug e stack trace expostas em produção, buckets S3 públicos com dados sensíveis, portas de administração expostas para a internet e configurações de CORS permissivas demais.
Resolver isso passa por criar baselines de configuração segura para cada tecnologia usada, automatizar verificações com ferramentas como ScoutSuite para cloud ou Lynis para Linux, e incluir hardening no pipeline de deploy.
5. Cross-Site Scripting (XSS)
XSS continua firme entre as vulnerabilidades mais encontradas em aplicações web, mesmo com frameworks modernos oferecendo proteções nativas. O problema é que basta um único ponto de input mal tratado para abrir um vetor de ataque.
Os cenários mais comuns são XSS Stored em campos de perfil e comentários, XSS Reflected em parâmetros de URL que voltam na página sem encoding, XSS em e-mails transacionais e DOM-based XSS em SPAs que manipulam parâmetros no frontend.
Num caso real, um XSS stored numa aplicação SaaS permitiu capturar cookies de sessão de administradores, escalando um acesso de usuário comum para admin completo. Sem precisar de nenhuma outra vulnerabilidade.
A defesa envolve encoding de output em todos os pontos de renderização, Content-Security-Policy restritiva, uso de frameworks que escapam por padrão (React, Angular, Vue) e flags HttpOnly e Secure nos cookies de sessão.
6. Exposição de dados sensíveis em APIs
APIs são a espinha dorsal das aplicações modernas e também onde encontramos as exposições de dados mais graves. O problema geralmente não é falta de autenticação, mas retorno excessivo de dados.
O que vemos com frequência: endpoints que devolvem o objeto inteiro do banco quando o frontend só precisa de 2 ou 3 campos, dados sensíveis como CPF e informações bancárias incluídos em respostas que deveriam ser públicas, logs contendo tokens de sessão e senhas, e endpoints internos acessíveis de fora por falta de segmentação.
A solução é implementar DTOs que retornem apenas os campos necessários, classificar dados por sensibilidade e auditar cada endpoint comparando o que é retornado versus o que o frontend realmente usa.
7. Falta de rate limiting e proteção contra brute force
A ausência de controles contra tentativas repetidas é uma falha que encontramos em quase toda aplicação, e que abre a porta para ataques de força bruta e credential stuffing com uma facilidade assustadora.
O cenário típico: telas de login sem limite de tentativas, endpoints de recuperação de senha sem rate limit, APIs de autenticação que aceitam milhares de requisições por minuto e formulários que informam se o e-mail existe ou não (facilitando enumeração de usuários).
Num pentest recente, conseguimos comprometer 47 contas de usuário em 3 horas usando credential stuffing contra um endpoint de login sem rate limit. Simplesmente testamos credenciais que já tinham vazado de outros serviços.
As proteções necessárias são rate limiting por IP e por conta, lockout temporário após tentativas falhas, CAPTCHA após tentativas consecutivas e mensagens de erro genéricas como "credenciais inválidas" em vez de "senha incorreta" ou "usuário não encontrado".
8. Componentes com vulnerabilidades conhecidas
Bibliotecas, frameworks e dependências desatualizadas com CVEs públicos são alvos fáceis. O exploit já está pronto, documentado e muitas vezes automatizado.
O que encontramos são versões antigas de jQuery, Apache Struts, Log4j e Spring com vulnerabilidades críticas publicadas há meses ou até anos. Também encontramos sistemas operacionais sem patches, containers Docker com imagens base desatualizadas e CMS como WordPress com plugins vulneráveis.
A solução passa por SCA (Software Composition Analysis) no pipeline de CI/CD, alertas automáticos para CVEs nas dependências, processo de patching com SLA definido por severidade e inventário atualizado de todas as tecnologias em uso.
9. Server-Side Request Forgery (SSRF)
SSRF ganhou muita relevância nos últimos anos, especialmente em ambientes cloud. Essa vulnerabilidade permite que o atacante faça requisições a partir do servidor, acessando recursos internos que não deveriam ser acessíveis de fora.
Os casos mais comuns envolvem funcionalidades de "importar URL" ou "pré-visualizar link" que permitem acessar endereços internos, endpoints que aceitam URLs como parâmetro e fazem requisições do lado do servidor, e o clássico acesso ao metadata service da cloud (169.254.169.254) para roubar credenciais de IAM.
Num caso real, através de um SSRF numa funcionalidade de importação de imagem, conseguimos acessar o endpoint de metadata da AWS e extrair credenciais temporárias com permissões de administrador. A partir dessas credenciais, foi possível acessar buckets S3 privados, bancos RDS e vários outros serviços do ambiente.
As defesas incluem validar e restringir URLs aceitas como input usando whitelist de domínios, bloquear requisições para ranges internos (10.x, 172.16.x, 169.254.x), segmentar a rede para limitar o alcance de um SSRF e usar IMDSv2 na AWS.
10. Falhas em gerenciamento de sessão
Problemas na forma como a aplicação cria, valida e encerra sessões abrem brechas para sequestro de contas e escalação de privilégios.
Os problemas que mais encontramos são tokens de sessão previsíveis ou sequenciais, sessões que não expiram após inatividade prolongada, tokens que não são invalidados após logout ou troca de senha, e transmissão de tokens em URLs que ficam visíveis em logs e histórico do navegador.
As correções envolvem usar geradores criptográficos seguros para tokens, definir tempo de expiração adequado, invalidar a sessão no servidor após logout e troca de senha, usar as flags Secure, HttpOnly e SameSite nos cookies e fazer rotação do token após autenticação.
O padrão por trás de tudo
Se você olhar essa lista com atenção, vai perceber que a maioria dessas falhas não é nada sofisticada. São problemas conhecidos, documentados, com soluções estabelecidas. O que as torna tão prevalentes não é complexidade técnica. São quatro coisas muito mais mundanas.
Pressão por entrega, com times priorizando velocidade de feature sobre segurança. Falta de treinamento, com desenvolvedores que nunca tiveram formação em desenvolvimento seguro. Ausência de testes, com código indo pra produção sem revisão de segurança. E dívida técnica acumulada em sistemas legados que ninguém quer tocar.
Um pentest periódico é a forma mais eficaz de identificar esses padrões na sua organização e tratá-los antes que virem incidentes.
