Testes de segurança, conhecidos como Security Testing, avaliam vulnerabilidades em aplicações e serviços frente a diferentes tipos de ataques, como ataques de negação de serviço ou injeção de código (Wikipedia, 2026-07-24). Escolher o tipo certo depende do estágio do desenvolvimento, do orçamento e do perfil de risco do sistema. Abaixo, os 9 tipos mais relevantes, do mais abrangente ao mais específico.
1. Teste de Penetração (Pentest)
O pentest simula um ataque real contra a aplicação, explorando falhas de configuração, autenticação ou lógica de negócio. Diferente de uma varredura automatizada, ele depende da criatividade do testador para encontrar brechas que scanners não detectam. Um pentest bem feito segue metodologias como OWASP Testing Guide e pode ser de caixa preta, cinza ou branca. O resultado é um relatório com vulnerabilidades classificadas por gravidade, incluindo passos para reprodução e remediação.
2. Varredura de Vulnerabilidades (Vulnerability Scanning)
Ferramentas automatizadas como Nessus, OpenVAS ou Qualys escaneiam a aplicação em busca de vulnerabilidades conhecidas, versões desatualizadas de bibliotecas, portas abertas ou configurações fracas. É rápido e barato, mas gera falsos positivos. Ideal para monitoramento contínuo em ambientes de produção, mas não substitui o pentest para falhas lógicas complexas.
3. SAST (Static Application Security Testing)
O SAST analisa o código-fonte sem executá-lo, identificando padrões inseguros como injeção de SQL, buffer overflow ou uso de funções perigosas. Ferramentas como SonarQube, Checkmarx e Fortify integram-se ao pipeline de CI/CD. A vantagem é detectar falhas cedo no desenvolvimento, antes da compilação. A desvantagem: não encontra vulnerabilidades de ambiente ou configuração.
4. DAST (Dynamic Application Security Testing)
O DAST testa a aplicação em execução, simulando requisições HTTP maliciosas. Ferramentas como OWASP ZAP, Burp Suite e Acunetix enviam payloads para endpoints e analisam respostas. Diferente do SAST, ele enxerga o sistema como um invasor externo, útil para encontrar falhas de autenticação, exposição de dados e erros de lógica. Porém, só cobre caminhos acessíveis via interface.
5. IAST (Interactive Application Security Testing)
O IAST combina elementos de SAST e DAST: agentes instalados no servidor monitoram a execução em tempo real, correlacionando tráfego com código-fonte. Ferramentas como Contrast Security e Hdiv Detection identificam vulnerabilidades com baixa taxa de falsos positivos. Ideal para ambientes de staging, mas exige instrumentação da aplicação e pode impactar performance.
6. RASP (Runtime Application Self-Protection)
O RASP não é exatamente um teste, mas uma camada de proteção que monitora requisições em produção e bloqueia ataques em tempo real. Integrado ao runtime da aplicação, ele analisa chamadas de sistema e tráfego HTTP para detectar padrões maliciosos. Útil como defesa adicional, mas não substitui testes preventivos, ele reage, não previne.
7. Teste de Caixa Branca (White-Box Testing)
O testador tem acesso completo ao código-fonte, diagramas de arquitetura e credenciais. Isso permite testar caminhos raramente usados, funções internas e lógicas de negócio profundas. É o tipo mais completo para avaliar segurança, mas consome mais tempo e exige conhecimento técnico alto. Recomendado para sistemas críticos como aplicações financeiras ou de saúde.
8. Teste de Caixa Preta (Black-Box Testing)
Sem acesso ao código ou à arquitetura, o testador age como um invasor real, usando apenas a interface pública da aplicação. Ferramentas de DAST e técnicas de engenharia social são comuns. É o mais realista para simular ataques externos, mas pode deixar falhas internas sem cobertura. Útil para testes de aceitação de segurança antes do lançamento.
9. Teste de Segurança de API
APIs são alvos frequentes de ataques como injeção, quebra de autenticação e exposição de dados. Testes específicos validam endpoints REST, GraphQL ou SOAP contra ameaças como OWASP API Security Top 10. Ferramentas como Postman, Insomnia e Burp Suite automatizam requisições maliciosas. Essencial para microsserviços e aplicações que expõem APIs públicas.
Como escolher o tipo certo?
Nenhum teste cobre tudo. Para um pipeline DevSecOps, comece com SAST no commit, DAST no build e pentest antes do release. Em produção, mantenha varredura contínua de vulnerabilidades e considere RASP para proteção extra. Para APIs, inclua testes específicos no ciclo. O orçamento e o nível de criticidade do sistema definem a combinação ideal.
Perguntas Frequentes (FAQ)
Qual a diferença entre SAST e DAST?
SAST analisa o código-fonte estático, antes da execução. DAST testa a aplicação em execução, simulando ataques externos. SAST encontra falhas cedo no desenvolvimento; DAST detecta problemas de configuração e ambiente.
Pentest é obrigatório por lei?
Depende do setor. Normas como PCI DSS exigem pentest periódico para sistemas que processam cartões de crédito. Regulamentações como LGPD não especificam pentest, mas exigem medidas de segurança adequadas.
Qual ferramenta de teste de segurança é gratuita?
OWASP ZAP é uma ferramenta gratuita e open source para DAST. Para SAST, SonarQube tem versão comunitária. Nessus oferece edição gratuita limitada para varredura de vulnerabilidades.
Teste de segurança atrapalha a performance da aplicação?
Testes automatizados como SAST e DAST rodam em ambientes isolados (CI/CD) e não afetam produção. Já o RASP, por monitorar runtime, pode ter impacto mínimo, mas é projetado para ser leve.
Quantas vezes devo realizar testes de segurança?
O ideal é integrar testes no pipeline de CI/CD (SAST a cada commit, DAST a cada build) e realizar pentest completo a cada 6 meses ou após grandes mudanças. Varreduras de vulnerabilidades devem ser semanais.
Teste de segurança de API cobre GraphQL?
Sim. Ferramentas como Burp Suite e OWASP ZAP suportam GraphQL. Testes específicos incluem injeção em queries, análise de autorização por campo e proteção contra ataques de profundidade de consulta.