O que entregamos
Conduzimos testes de segurança orientados a risco em aplicações web, mobile e APIs, sejam públicas ou internas. O escopo é definido em conjunto com o time técnico, cobrindo fluxos críticos de negócio, autenticação, autorização, injeção, exposição de dados e falhas de lógica. Os testes seguem referências reconhecidas (boas práticas da OWASP para riscos em aplicações e o framework PTES para testes de penetração) e entregam artefatos prontos para priorização por risco real e correção.
O problema que resolve
Aplicações em produção com vulnerabilidades não detectadas por scanners automatizados. Times que precisam de visibilidade objetiva sobre risco técnico antes de auditorias ou releases críticos.
CTOs, heads de produto, líderes de engenharia e times de segurança que precisam de uma avaliação independente da postura de segurança das suas aplicações.
Antes de auditorias, após mudanças significativas na aplicação, como requisito de compliance, ou quando o time precisa de uma visão externa sobre a superfície de ataque.
Escopo de atuação
Entregáveis
Como o trabalho acontece, na prática
O que entra no teste
Autenticação e gestão de sessão (política de senhas, MFA, expiração e invalidação de tokens, JWT com algoritmo e assinatura validados), controle de acesso (BOLA/IDOR, ou seja, acessar objetos de outros usuários alterando um identificador; escalada de privilégio vertical e horizontal), validação de entrada (injeção de SQL, de comandos e de templates, XSS, SSRF), lógica de negócio, exposição excessiva de dados em respostas de API e configuração de segurança, como cabeçalhos HTTP e CORS. Em APIs, a referência é o OWASP API Security Top 10; em aplicações web, o OWASP Top 10 e o ASVS; em mobile, o MASVS.
Como a exploração é conduzida
Ferramentas automatizadas ampliam a cobertura, mas o que define o resultado é o teste manual: encadear falhas pequenas, abusar de fluxos de negócio e validar o impacto real. Um exemplo comum é combinar um IDOR de baixo risco com uma enumeração de usuários para chegar a dados de muitos clientes. Também se testam condições de corrida em saldos e cupons, contorno de limites de requisições e mass assignment. Uma vulnerabilidade só entra no relatório com evidência reproduzível (requisição, resposta e passos), e a severidade considera a facilidade de exploração e o impacto para o negócio, podendo usar o CVSS como apoio, não como única nota.
Sinais de que o teste é necessário
Lançamento de uma aplicação ou de uma API pública, mudança relevante em autenticação, autorização ou pagamentos, integração com terceiros, migração de arquitetura, exigência de cliente ou de auditoria, ou ausência de um teste manual recente. O PCI DSS 4.0.1 (requisito 11.4), por exemplo, prevê testes de penetração em ambientes que tratam dados de cartão. Scanners e testes automatizados de rotina encontram problemas conhecidos, mas não substituem a visão de quem tenta explorar o sistema como um atacante, nem avaliam regras de negócio específicas. Um bom resultado inclui o reteste das correções, para confirmar que a falha deixou de existir.
Diferenciais
- Testes manuais por especialistas, não apenas automação genérica
- Relatório com contexto de negócio, não apenas lista de CVEs
- Reteste gratuito por 30 dias para validar as correções
- Repasse técnico direto com o time de engenharia
Metodologia
Definição de escopo e regras de engajamento
Reconhecimento e mapeamento da superfície de ataque
Testes manuais e automatizados
Exploração controlada de vulnerabilidades
Relatório com evidências e recomendações
Reteste gratuito por 30 dias
Destaques
Perguntas frequentes
Pronto para avançar?
Conte sobre seu contexto e desafios. Respondemos com uma proposta clara.