Pentest em aplicação web para SaaS
Pentest para SaaS e software B2B
Atualizado em 2 de novembro de 2026. Próxima revisão prevista para fevereiro de 2027.
Por Julio Cesar Madeira Soares, especialista em segurança da informação, especialista em segurança cibernética e perito em computação forense.
O pior bug de um SaaS é o cliente A enxergar os dados do cliente B. Testamos o isolamento entre clientes, as permissões, o login corporativo e a API com contas em empresas diferentes, e entregamos um relatório que o seu cliente grande consegue ler.
Base em Governador Valadares/MG · Atendimento remoto em todo o Brasil
Pentest para SaaS verifica, antes de mais nada, se os clientes estão de fato separados uns dos outros. Criamos empresas de teste diferentes e tentamos atravessar de uma para a outra, por tela, API, arquivo, exportação e integração. Depois testamos permissões, login corporativo e o restante da aplicação.
O SaaS costuma ser operador de dados dos clientes (LGPD, art. 5º, VII), e operador também responde: pelos danos quando descumpre a lei ou as instruções lícitas do controlador (art. 42, §1º, I) e quando deixa de adotar as medidas de segurança do art. 46 (art. 44, parágrafo único).
O que não prometemos. Pentest não é certificação e não substitui SOC 2 nem ISO 27001. E o relatório fala da versão testada. Em produto com entrega contínua, ele envelhece mais rápido, e isso precisa ser dito a quem vai lê-lo.
O que muda
Por que um SaaS pede um teste diferente
Boa parte do pentest é igual ao de qualquer aplicação. O que muda é o tamanho do estrago e quem cobra o resultado.
O risco muda de escala. Numa empresa comum, a falha expõe os dados dela. Num SaaS, uma falha de isolamento pode expor os dados de todos os clientes, e cada um deles é um controlador com o próprio dever de avaliar e comunicar o incidente.
O cliente grande pergunta. Questionário de segurança e due diligence costumam pedir evidência de teste recente, e o contrato pode exigi-lo. O SOC 2 não exige pentest de forma explícita, mas o teste ajuda a sustentar critérios como o CC4.1. A ISO/IEC 27001:2022 pede teste de segurança no desenvolvimento e na aceitação (controle 8.29), sem usar a palavra pentest.
Cliente regulado leva a exigência para você. Os controles de uma instituição autorizada pelo Banco Central precisam abranger os sistemas de terceiros que ela usa. Quem vende para esse público costuma ouvir a pergunta. E, se você é prestador multiempresa no escopo do PCI DSS, o requisito 11.4.7 pede apoio ao teste externo dos seus clientes.
O que é só seu e o que não é. O teste acontece em empresas de teste criadas para isso, sem tocar em dado de cliente real. A nuvem por baixo do produto segue as regras do provedor.
Multiempresa
Como testamos o isolamento entre clientes
O filtro por cliente costuma funcionar na tela principal. A falha aparece nos caminhos em que alguém esqueceu dele.
| Onde olhar | Como a falha aparece | Como testamos |
|---|---|---|
| Identificador do cliente na requisição | A aplicação confia no identificador da empresa enviado pelo navegador. | Logados na empresa A, trocamos o identificador pelo da empresa B em cada rota relevante. |
| Busca, filtros e relatórios | A consulta de agregação ou o autocompletar não filtra por cliente. | Plantamos marcadores na empresa B e procuramos por eles a partir da empresa A. |
| Arquivos e links assinados | O anexo fica acessível por link previsível ou que não expira. | Testamos o link sem sessão, em outra empresa e depois de o usuário perder o acesso. |
| Tarefas em segundo plano | Exportação, e-mail ou webhook sai com dado de outro cliente. | Disparamos as tarefas em paralelo nas duas empresas e conferimos o que cada uma recebe. |
| Cache | Uma resposta guardada para uma empresa é entregue a outra. | Comparamos respostas entre empresas nas mesmas rotas e parâmetros. |
| Acesso de suporte | A função de entrar como cliente fica aberta demais ou não deixa registro. | Com autorização, testamos quem consegue usá-la, sobre quais empresas e o que fica no log. |
O que testamos
O que mais testamos em um SaaS
Além do isolamento, estes são os pontos em que um produto B2B costuma ter mais a perder.
Papéis e permissões
Perfil personalizado que ganha mais do que deveria, função de administrador chamada direto na API e campo que o usuário não vê, mas consegue alterar.OWASP API3 e API5:2023 · A01:2025
Login corporativo
SSO por SAML ou OIDC, validação de assinatura e de destino, vínculo entre empresa e domínio de e-mail e provisionamento por SCIM.WSTG-ATHN · OWASP A07:2025
Ciclo de vida do usuário
Convite reaproveitado, usuário removido que mantém sessão ou token, troca de empresa e conta criada em domínio que não é do cliente.WSTG-IDNT · WSTG-SESS
API, tokens e webhooks
Escopo de token, chave que vale em mais de um ambiente, limite de consumo e webhook configurável que permite alcançar a rede interna (SSRF).OWASP API4 e API7:2023 · A01:2025
Importação e exportação
Planilha que injeta fórmula em quem abre, importação que executa algo no servidor e exportação que traz mais colunas do que a tela mostra.WSTG-INPV · WSTG-BUSL
Integrações e marketplace
Aplicativo de terceiro com permissão ampla demais, OAuth mal validado e segredo de integração visível para perfis que não deveriam vê-lo.OWASP API10:2023 · A03:2025
Como preparar
O que preparar para um pentest de SaaS
Um pouco de preparo troca tempo de cadastro por tempo de teste.
Pelo menos duas
Duas empresas no mesmo plano, com dados fictícios e todos os módulos ligados. Se há plano superior com função extra, uma terceira ajuda a testar o que vaza entre planos.
Todos os papéis
Administrador, gestor, usuário comum e convidado em cada empresa, mais a documentação da API. Se houver SSO, um provedor de identidade de teste.
O que foi testado
Registramos versão e período do teste. Mudanças grandes durante o trabalho são combinadas, para o relatório dizer com clareza a que ele se refere.
A versão executiva é a que costuma ir para cliente e due diligence, sob acordo de confidencialidade e com as evidências mascaradas. O método, as modalidades e os limites do que o relatório prova estão em Pentest em aplicação web. Se você também precisa de encarregado, veja DPO como serviço.
Responsável técnico
Quem conduz o teste
Julio Cesar Madeira Soares
Pentester e perito em computação forense
Atuo desde 2015 em teste de intrusão, pesquisa de vulnerabilidades e programas de bug bounty, e sou membro do Synack Red Team desde 2018. Tenho a certificação CompTIA PenTest+ e fiz o treinamento SEC542 do SANS, de teste de intrusão em aplicações web, sem prestar a certificação GIAC correspondente.
Em bug bounty, o alvo costuma ser produto de software em produção, e a falha só conta se for provada. É o mesmo critério que levo para o relatório.
Ver certificações e reconhecimento públicoNossa base é Governador Valadares/MG, e o atendimento é remoto em todo o Brasil. Outros setores: Pentest para fintech, Pentest para e-commerce e Pentest para saúde.
Dúvidas frequentes
Perguntas sobre pentest para SaaS
O que é teste de isolamento entre clientes?
É tentar, logado em uma empresa, alcançar os dados ou as funções de outra empresa no mesmo produto, por todos os caminhos: tela, API, busca, arquivo, exportação, webhook e cache. É a parte mais importante do pentest em um SaaS multiempresa, porque esse é o tipo de falha que atinge todos os clientes de uma vez.
SOC 2 ou ISO 27001 exigem pentest?
Não de forma explícita. O SOC 2 não traz controle específico de pentest, embora o teste ajude a sustentar critérios como o CC4.1 e possa ser exigido em contrato. A ISO/IEC 27001:2022 pede teste de segurança no desenvolvimento e na aceitação (controle 8.29). Na prática, auditor e cliente costumam perguntar. Vale alinhar antes o que eles esperam ver.
Com deploy todo dia, o relatório não fica velho logo?
Fica, em parte. Ele fala da versão testada. Por isso registramos versão e período, e faz sentido repetir o teste nas partes que mudaram muito, como autenticação, permissões e novos módulos. O pentest não substitui teste de segurança no ciclo de desenvolvimento: um pega o que o outro deixa passar.
Posso mostrar o relatório para os meus clientes?
Sim, e a versão executiva existe para isso. Ela diz o que foi testado, quando e o resultado por categoria, sem o passo a passo de exploração. O ideal é enviar sob acordo de confidencialidade e, de preferência, depois do reteste das falhas graves.
Vocês precisam do código-fonte?
Não é obrigatório. O teste com contas de cada perfil já cobre o principal. Com acesso ao código, o trabalho fica mais rápido em pontos como consultas sem filtro por cliente, e é mais fácil achar o que o teste de fora não alcança. A escolha depende do prazo e do que o seu cliente espera ver.
Meu SaaS é operador. Quem comunica um incidente?
A comunicação à ANPD e aos titulares cabe ao controlador, em três dias úteis quando o incidente é relevante (Resolução CD/ANPD nº 15/2024, arts. 6º e 9º). Como operador, você precisa avisar os clientes a tempo de eles cumprirem esse prazo, e o contrato deveria dizer como. Se uma falha de isolamento for explorada, serão vários controladores ao mesmo tempo.
Um cliente seu consegue ver os dados de outro?
Conte o que o produto faz, como os clientes ficam separados e quem está pedindo o teste. Eu digo com franqueza que escopo faz sentido e o que esse relatório vai conseguir responder.
Falar sobre o produto