Ambientes SaaS falham de maneiras características. Raramente quebram no perímetro ou por ausência total de controles; eles quebram porque a lógica de autorização é incompleta, o isolamento de tenants é inconsistente e as APIs que sustentam essas plataformas confiam em estados nos quais não deveriam. Em 119 testes de intrusão realizados para clientes de Tecnologia, Software e SaaS em 2025, 755 vulnerabilidades concentraram-se em controle de acesso, exposição de dados sensíveis e lógica de negócios.
Dois padrões tornam o setor de SaaS distinto. O primeiro diz respeito à segurança de APIs: quase todas as descobertas em SaaS eram acessíveis pela rede e não exigiam interação do usuário para serem exploradas, refletindo o quanto a superfície de ataque do SaaS moderno reside em APIs JSON, e não na interface renderizada. O segundo diz respeito aos limites de confiança: o SaaS apresentou a maior taxa de mudança de escopo CVSS de qualquer setor, uma consequência de arquiteturas de microsserviços e premissas de confiança compartilhada, onde a exploração em um serviço rotineiramente cruza domínios de autorização para outro.
Os dados por trás deste artigo vêm do nosso Relatório Anual de Testes de Intrusão de 2025, uma análise de 3.294 descobertas em 660 projetos e 145 organizações. As seções a seguir destilam as vulnerabilidades de SaaS mais comuns desse conjunto de dados: o que está no escopo durante um teste de intrusão em SaaS, o perfil de severidade e a densidade das descobertas, os CWEs que mais se repetem e muito mais.
O que as avaliações de segurança em SaaS geralmente cobrem
O escopo de um teste de intrusão em SaaS é moldado pela arquitetura subjacente: uma aplicação web multi-tenant sobre uma camada de API, sustentada por um backend de microsserviços ou orientado a serviços, integrada a serviços de terceiros e implantada em infraestrutura de nuvem. Testes de segurança em aplicações web dominaram as avaliações de aplicações SaaS em 2025, representando 62,4% de todos os projetos no setor.
Essa distribuição é mais sutil do que parece. Embora os testes dedicados de segurança de APIs representassem apenas 3,4% dos projetos de SaaS, a maioria dos testes de intrusão em aplicações web inclui a camada de API subjacente no escopo por padrão — o frontend raramente é separável do backend baseado em JSON que o alimenta. Os projetos de SaaS também mostraram a maior parcela de avaliações mistas/especializadas de qualquer setor, com 19,7%, refletindo a frequência com que esses escopos se estendem para revisão de código-fonte, auditorias de configuração de nuvem, testes específicos de GraphQL ou avaliações de recursos integrados a LLMs.
Dentro desse escopo, vários sistemas atraem consistentemente a atenção dos testes: portais de clientes, consoles de administração e operação, APIs REST e GraphQL públicas, APIs internas de serviço para serviço, provedores de identidade e integrações SSO, além das camadas de autorização e sessão que os conectam. A autorização em nível de objeto — se um usuário no tenant X pode acessar um recurso pertencente ao tenant Z — geralmente produz o maior número de descobertas de qualquer área, pois a aplicação correta é necessária em cada endpoint, e não apenas em um perímetro único.
Três fatos arquiteturais explicam por que os testes de intrusão em SaaS revelam as descobertas que revelam. O principal limite de confiança sob teste é entre tenants, não entre a internet e a aplicação; o isolamento de dados de tenants é o que a multi-tenancy foi criada para garantir, e é onde ela mais falha. A lógica de negócios é distribuída entre serviços, o que significa que as decisões de autorização são tomadas em vários lugares usando premissas sutilmente diferentes. O ritmo de lançamento supera a maioria dos ciclos de revisão de segurança, deixando endpoints recém-adicionados, sinalizadores de recursos (feature flags) e integrações de terceiros como uma fonte recorrente de nova exposição.
Severidade e volume de descobertas em testes de intrusão em SaaS
Os projetos de SaaS produziram mais descobertas por projeto do que a população geral de testes de intrusão de 2025: 6,34 vulnerabilidades por avaliação em média, contra uma média intersetorial de 4,99 descobertas por projeto. Em 119 compromissos de SaaS, isso totalizou 755 vulnerabilidades em SaaS, uma densidade maior que reflete tanto a amplitude da superfície de ataque nas arquiteturas SaaS modernas quanto a forma como os escopos de teste rotineiramente se estendem pelas camadas web, API, de identidade e de nuvem em um único compromisso.
O perfil de severidade situa-se mais próximo da média. Descobertas de nível Alto e Crítico juntas representaram 14,3% dos resultados de pentest em SaaS, um índice menor que nos setores de Saúde e Farmacêutico, Petróleo, Gás e Energia, e Seguros, mas materialmente maior que no E-commerce, Varejo, Finanças e Fintech. As vulnerabilidades do setor de SaaS situam-se no meio da distribuição de severidade: não são inclinadas a descobertas individuais catastróficas como nos setores regulamentados ou com sistemas legados, nem tão claramente ponderadas para Baixa e Média como nos setores transacionais com programas maduros de segurança de aplicações.
A combinação de maior volume e severidade de médio alcance reflete algo específico sobre a maturidade da segurança em SaaS. Vulnerabilidades técnicas básicas, como falta de autenticação, interfaces de administração expostas ou transportes sem criptografia, estão amplamente ausentes nos relatórios de pentest de SaaS. O que resta é uma longa cauda de casos extremos de autorização, problemas de exposição de informações, falhas de lógica de negócios e fraquezas de configuração que, individualmente, caem na severidade Média, mas que coletivamente definem os riscos residuais de segurança de SaaS em ambientes maduros.
Interpretar os 14,3% como um dado tranquilizador seria um erro. As classificações de severidade são calibradas com base em dimensões de impacto genéricas do CVSS, que sub-representam dois modos de falha específicos para SaaS: violações de limites de locatário (tenant), onde um IDOR de severidade Média pode expor dados de outro cliente, e caminhos de exploração encadeados, onde vulnerabilidades críticas emergem da combinação de duas ou três fraquezas de segurança que, de outra forma, seriam irrelevantes. As descobertas de segurança em SaaS neste conjunto de dados reforçam um tema recorrente dos resultados mais amplos de 2025 — as vulnerabilidades do setor de SaaS com maior impacto no mundo real raramente são as mais tecnicamente dramáticas.
As descobertas de pentest em SaaS mais comuns
APIs inseguras são uma vulnerabilidade comum em aplicações SaaS, onde problemas como autenticação inadequada e validação de entrada insuficiente podem levar ao acesso não autorizado a dados e a violações significativas de dados. Os CWEs abaixo descrevem como essas falhas aparecem no conjunto de dados de 2025.
CWE-200 — Exposição de Informações Sensíveis. O CWE mais comum em SaaS raramente assume a forma de um vazamento de dados clássico. Ele surge como respostas de API detalhadas retornando campos não renderizados, payloads JWT carregando metadados internos, cabeçalhos de depuração em produção ou endpoints administrativos retornando dados de clientes junto com os objetos solicitados. Essas descobertas raramente quebram um sistema por conta própria, mas permitem que um invasor acesse dados sensíveis por meio de ataques de autorização posteriores — o tecido conjuntivo por trás da maioria dos cenários de acesso não autorizado a dados que os pentests revelam.
CWE-284 — Controle de Acesso Inadequado. O Controle de Acesso Quebrado é o risco mais comum em aplicações web modernas, aparecendo em quase 100% das aplicações testadas, e as descobertas de SaaS de 2025 situam-se firmemente dentro desse padrão. A categoria abrange problemas de controle de acesso, desde violações de limites de locatário até falhas de privilégio horizontal e escalonamento de privilégios, onde controles de acesso baseados em funções são aplicados na interface do usuário, mas não na API. Em sistemas multilocatários, controles de acesso fracos desse tipo são a maneira mais comum de obter acesso não autorizado a dados de clientes, escalar privilégios ou extrair dados internos sem comprometer uma credencial.
CWE-79 — Cross-Site Scripting (XSS). O XSS está entre os três principais riscos em SaaS, mas não nos resultados de pentest de saúde, energia ou seguros. Dois fatores explicam isso: a alta densidade de rich text fornecido pelo usuário em produtos SaaS modernos e a velocidade da evolução do frontend, que supera a sanitização de entrada e saída. Códigos gerados por IA podem ser vulneráveis a cross-site scripting (XSS) em 86% dos casos, destacando um ponto cego significativo na cibersegurança que provavelmente está acelerando a tendência. O XSS armazenado em visualizações de administrador ou operador é particularmente perigoso — um único payload de locatário pode atingir a sessão de um engenheiro de suporte e servir de pivô para sistemas internos.
O restante das principais vulnerabilidades em SaaS revela uma longa cauda de fraquezas operacionais. Falhas de limitação de taxa (CWE-799) expõem vulnerabilidades de lógica de negócios que permitem tentativas de força bruta e enumeração de contas. O upload de arquivos sem restrições (CWE-434) está ligado a conteúdo gerado pelo usuário e fluxos de trabalho de integração, e mensagens de erro detalhadas (CWE-209) somam-se ao cenário de exposição de informações.
A Configuração Incorreta de Segurança tornou-se o segundo risco mais comum em aplicações web modernas, envolvendo a configuração inadequada de definições de segurança, como deixar senhas padrão ativas ou manter buckets de armazenamento em nuvem abertos ao público. Em pentests de SaaS, isso surge principalmente como falhas em mecanismos de proteção (CWE-693) — controles que existem, mas que podem ser contornados por meio de caminhos de solicitação inesperados.
Juntas, essas descobertas descrevem um perfil onde lacunas críticas expostas externamente são raras. O que resta é o acúmulo de controles de acesso inadequados, fraquezas na lógica de negócios e vazamento de informações dentro de fluxos de trabalho autenticados — uma superfície de risco que coloca silenciosamente dados críticos ao alcance de usuários internos motivados ou contas comprometidas.
Principais vetores de ataque em testes de intrusão de SaaS
O setor de SaaS apresentou a maior concentração de vulnerabilidades exploráveis via rede entre todas as indústrias avaliadas: quase todas as descobertas são acessíveis remotamente, a maioria não requer interação do usuário e grande parte pode ser acionada com privilégios baixos ou nulos. O SaaS também registrou a maior taxa de mudança de escopo CVSS de qualquer setor, um indicador de arquiteturas de microsserviços onde a exploração em um serviço atravessa domínios de autorização para outro.
A composição muda assim que os atacantes estão dentro. Testes de intrusão baseados em SOC 2, realizados predominantemente em plataformas SaaS, mostram que cerca de 38% das descobertas envolvem um usuário autenticado abusando de permissões. Esta categoria engloba BOLA, IDOR, problemas de limites entre tenants e escalonamento de privilégios no topo da lista CWE de SaaS. O padrão reflete ameaças internas em sua forma, mesmo quando o agente é externo à organização.
Vazamento de informações e vetores de reconhecimento representam cerca de 25% dos padrões de ataque relevantes para SaaS — mensagens de erro detalhadas, cabeçalhos de depuração, discrepâncias observáveis em respostas e conexões de API excessivamente informativas que permitem a um atacante mapear a aplicação antes de explorá-la. Abuso de sessão e token adiciona cerca de 14%, manifestando-se como identificadores de sessão previsíveis, rotação fraca de tokens ou sessões que permanecem ativas após o logout — exatamente as condições de fluxo de trabalho que uma revisão de segurança rigorosa deveria detectar, mas que rotineiramente deixa passar.
Categorias menores são instrutivas. Fraquezas criptográficas e de mecanismos de proteção representam cerca de 13% — controles que existem, mas estão configurados incorretamente. Acesso externo não autenticado representa apenas cerca de 7%, uma inversão notável em relação aos padrões antigos de testes de intrusão. Exploração encadeada representa apenas cerca de 3% em contagem, mas produz os resultados de maior impacto, frequentemente transformando um incidente de segurança rotineiro em tomada de conta ou comprometimento de tenant.
O perfil do vetor de ataque difere notavelmente da população geral de testes de intrusão. Acesso não autenticado e ataques de força bruta contra serviços expostos externamente são descobertas comuns em muitos setores, mas aparecem com pouca frequência em testes de intrusão de SaaS, onde controles de perímetro, limitação de taxa e MFA foram amplamente adotados. O risco migrou para dentro, para as camadas de autorização, sessão e integração. As vulnerabilidades mais comuns em SaaS não se tratam mais de passar pela porta da frente — tratam-se do que usuários autenticados e serviços conectados podem fazer uma vez lá dentro.
O que estas descobertas significam
O perfil de ataque em SaaS não é acidental. A multilocação, a decomposição em microsserviços e o lançamento contínuo criam exatamente as condições descritas pelos dados de 2025: a maior parte da exploração requer autenticação; os limites de confiança residem no código em vez da infraestrutura; e os modos de falha acumulam-se entre serviços em vez de se concentrarem em um único perímetro.
O ponto cego interpretativo mais consistente nas descobertas de segurança SaaS é como as vulnerabilidades se combinam. O CVSS pontua cada descoberta isoladamente em relação a dimensões de impacto genéricas, mas a exploração em SaaS raramente acontece de forma isolada. Um IDOR de gravidade média mais um vazamento de informações de gravidade média mais um acesso legítimo de uma conta de inquilino de baixo privilégio não somam três médias de impacto operacional — isso resulta em tomada de conta. As classificações de gravidade ignoram que as lacunas de segurança que mais importam são aquelas que se conectam.
A velocidade de lançamento é a razão estrutural pela qual existe a longa cauda de descobertas em SaaS. A maioria das organizações SaaS entrega mais rápido do que seus ciclos de revisão de segurança conseguem acompanhar, deixando endpoints recém-adicionados, sinalizadores de recursos e pontos de integração como uma fonte constante de nova exposição. A segurança de integração é um ponto cego particular — serviços de terceiros e webhooks acumulam-se entre revisões agendadas, e descobertas CWE-693 e CWE-799 aparecem rotineiramente em códigos que se desviaram de sua linha de base.
No geral, o conjunto de dados descreve uma disciplina que está mudando da defesa no perímetro para a defesa dentro da aplicação. As equipes de segurança SaaS que internalizam essa mudança tratam as descobertas como portfólios em vez de listas de verificação, monitoram possíveis lacunas de segurança à medida que surgem entre lançamentos e medem a postura de segurança SaaS pela consistência com que a autorização é aplicada, em vez de contagens de CVEs remediados. Os riscos de segurança SaaS mais comuns recompensam esse tipo de atenção.
Onde os programas de segurança SaaS devem focar
O teste de autorização deve abranger os limites de inquilinos e serviços, não apenas funções de usuário dentro de um único inquilino. O gerenciamento de acesso é geralmente bem coberto no perímetro; as superfícies subespecificadas são a borda entre inquilinos e as interfaces entre serviços, onde as decisões de autorização são rotineiramente presumidas em vez de aplicadas. Incluir um segundo inquilino no escopo, além de testes explícitos de autorização entre serviços, revela problemas que avaliações de inquilino único perdem sistematicamente.
As cargas úteis de resposta da API justificam auditoria, não apenas verificação funcional. O CWE-200 em SaaS raramente se manifesta como falta de controle de acesso; ele se manifesta como endpoints retornando mais campos do que o frontend renderiza, cargas úteis JWT carregando metadados internos e endpoints de administração cujas respostas incluem objetos adjacentes além do recurso solicitado. Listar cada campo que cada endpoint retorna, e então perguntar se cada um é necessário, detecta uma parcela significativa desses problemas antes que cheguem a um teste de intrusão.
A limitação de taxa precisa se estender além dos endpoints de autenticação. O controle de login agora é amplamente implantado; redefinição de senha, registro, consulta de conta, pesquisa e operações em massa frequentemente não são. Descobertas CWE-799 em SaaS aparecem precisamente nesses endpoints — pontos de enumeração, exaustão de recursos ou abuso de lógica de negócios que não parecem força bruta à primeira vista, mas permitem tomada de conta, raspagem ou negação de serviço quando encadeados.
As superfícies de integração e webhook merecem inventário periódico e redução de confiança. Serviços de nuvem de terceiros acumulam-se com o tempo, escopos OAuth desviam-se para além do caso de uso original exigido, e retornos de chamada de webhook não são auditados entre lançamentos. A pergunta útil não é "esta integração é segura?", mas "o que um invasor alcançaria se esta integração fosse comprometida amanhã?" — a resposta na maioria dos aplicativos SaaS é mais ampla do que o esperado.
O ciclo de vida de sessão e token é um ponto cego frequente em fluxos de trabalho SaaS de longa duração. Problemas comuns com identidade e autenticação incluem sequestro de sessão, preenchimento de credenciais e falha ao desprovisionar contas de ex-funcionários. Os casos mais difíceis envolvem mudanças de estado pós-login: sessões ativas que persistem após um usuário ser excluído de um inquilino, rebaixamentos de função que não invalidam direitos armazenados em cache, tokens de atualização não rotacionados no uso ou tokens OAuth cujos escopos se ampliam silenciosamente. Testar o ciclo de vida sob condições de fluxo de trabalho expõe modos de falha que as classificações de gravidade por CWE subestimam.
Conclusão
As descobertas de 2025 reformulam o que a segurança SaaS realmente exige. Autenticação, controles de perímetro e criptografia básica estão amplamente resolvidos; o que agora define a segurança SaaS é tornar a autorização correta e consistente entre endpoints, serviços e inquilinos.
O teste de intrusão continua essencial para provedores SaaS, e avaliações de segurança regulares cronometradas para corresponder à cadência de lançamento superam consistentemente os pontos de verificação anuais. Scanners encontram controles ausentes; testadores de intrusão encontram controles que existem, mas falham sob condições reais de fluxo de trabalho — exatamente onde as violações de dados modernas no setor tendem a começar, e onde a resposta a incidentes é mais difícil após o fato.
Os incidentes mais prejudiciais não são aqueles que rompem a porta da frente; são aqueles que exploram silenciosamente o que já está dentro.
Perguntas frequentes
Com que frequência uma empresa SaaS deve realizar um teste de intrusão?
A maioria dos programas SaaS se beneficia de avaliações de segurança regulares sincronizados com a cadência de lançamento em vez de pontos de verificação anuais. O SOC 2 e a ISO 27001 exigem auditorias de segurança regulares, no mínimo anuais, mas cada novo recurso, integração ou endpoint administrativo introduz uma nova superfície de ataque — e as descobertas se acumulam mais rápido do que as revisões anuais conseguem detectar. Testes trimestrais ou por lançamento para componentes de alta mudança, combinados com compromissos anuais mais amplos, são um padrão comum.
Quais são os riscos emergentes de IA para a segurança de SaaS?
O código gerado por IA introduz falhas de tratamento de entrada em escala, acelerando o padrão de XSS já visível nos dados de pentest de SaaS. O uso não autorizado de IA, conhecido como "Shadow AI", pode levar ao upload de dados confidenciais para plataformas não verificadas quando os funcionários colam informações de clientes ou internas em ferramentas de IA de consumo. Abordar vulnerabilidades de SaaS desse tipo exige incluir explicitamente as superfícies relacionadas à IA na próxima avaliação.
Como as descobertas de pentest em SaaS são normalmente priorizadas para remediação?
As classificações de gravidade são o ponto de partida, mas as descobertas em SaaS geralmente precisam de uma nova priorização com base no potencial de encadeamento. Um IDOR de gravidade média pode ser mais importante do que uma descoberta de alta gravidade se ele cruzar um limite de tenant ou se combinar com vazamento de informações para permitir a tomada de conta. Fazer a triagem por combinação é o que separa a remediação eficaz de SaaS de um exercício de contagem de CVEs.
