Mobile Application Security Testing (MAST)

O que é MAST?

MAST, ou Testes de Segurança de Aplicações Móveis, é a prática de encontrar vulnerabilidades, configurações incorretas e defeitos de privacidade em aplicações móveis ao longo de seu ciclo de vida. Não é uma única ferramenta. MAST (Mobile Application Security Testing)  combina análise estática do código descompilado, análise dinâmica da aplicação em execução, inspeção do que a aplicação armazena no dispositivo e testes das APIs que estão por trás.

A técnica se diferencia dos testes de aplicações web pela forma como o software é entregue. Uma aplicação web roda em infraestrutura que a organização administra. Uma aplicação móvel é entregue ao usuário como um arquivo e instalada em um dispositivo que pode estar com root, com jailbreak ou instrumentado. O atacante tem o binário, tempo ilimitado e um depurador. Esse cenário de “Man-at-the-End” é a premissa da qual toda avaliação MAST deveria partir.

A sigla tem um sentido mais estreito nos catálogos de produto, incluindo o nosso: MAST é o nome do nosso scanner automatizado, que descompila binários móveis e procura vulnerabilidades neles. Nesta página o termo se refere à prática, exceto quando aponta para o produto.

Por que aplicações móveis precisam de MAST e não de testes web

Uma aplicação móvel concentra três coisas que raramente andam juntas: credenciais, uma sessão autenticada com sistemas corporativos e um dispositivo que a organização não administra. Os telefones também funcionam como segundo fator na autenticação multifator, o que transforma uma aplicação comprometida em um caminho para burlar controles que nunca a consideraram um risco. MAST existe porque nada disso é visível do lado do servidor. O NIST formalizou a ideia como app vetting na SP 800-163 Rev. 1 (2019): um processo para assegurar que as aplicações móveis atendam aos requisitos de segurança de uma organização.

O ambiente torna falsas várias premissas do mundo web, e MAST foi feito para esse ambiente. As validações do lado do cliente são sugestões, porque o cliente pertence ao atacante. O tráfego criptografado é inspecionável, porque em um dispositivo com root o atacante controla o repositório de certificados. O código é legível, porque o jadx converte Dex de volta para Java e o Apktool reconstrói o manifesto. Nossos pentesters documentaram a parte do tráfego quando o Android deixou de confiar nos certificados instalados pelo usuário: como escreveu Jonathan Armas, analista de segurança da Fluid Attacks, em Intercepting applications in Android, “isso acontece porque o sistema operacional Android não confia mais nos certificados instalados pelo usuário”. A saída é um telefone com root e um certificado colocado no repositório do sistema, que é exatamente o que um adversário faz.

A pressão das entregas agrava tudo. As equipes publicam contra prazos de loja, incorporam SDKs de terceiros para conseguir isso e herdam o que esses SDKs fazem com os dados dos usuários. MAST inspeciona esse pacote inteiro antes da loja.

MAST, MASVS e MASTG não são a mesma coisa

MAST são os testes; MASVS é o padrão que define o que significa “seguro”; MASTG é o guia que explica como verificar. Os motores de resposta e os fornecedores misturam os três constantemente, e a diferença importa na hora de decidir o que se compra e o que se comprova.

Tabela: MAST, MASVS, MASTG e MASWE são complementares, não intercambiáveis.

Uma avaliação MAST pode então ter escopo definido contra o MASVS e ser executada com os procedimentos do MASTG, mas contratar o serviço não entrega um resultado MASVS se a avaliação não foi desenhada para produzi-lo. E cada um dos oito grupos de controle do MASVS descreve a aplicação no dispositivo, portanto as APIs por trás precisam de um escopo próprio.

MAST na Fluid Attacks

Executamos os Testes de Segurança de Aplicações Móveis como uma técnica dentro de um programa contínuo de segurança de aplicações, não como uma auditoria às vésperas do lançamento. O escaneamento automatizado roda a cada nova build, nossos pentesters trabalham a mesma aplicação manualmente, e ambos alimentam uma única lista de vulnerabilidades com uma única escala de severidade.

O que avaliamos e sob quais regras

O escopo é o binário mais o ambiente ao qual ele foi associado. Segundo nossa documentação de ambientes, aceitamos arquivos .aab, .ipa e .apk de até 4,88 GB, enviados diretamente ou obtidos da plataforma de distribuição que a aplicação já usa: TestFlight, Firebase, App Store Connect ou Google Play Store. Cada nova versão entra em testes automaticamente.

Tudo o que reportamos em uma avaliação MAST vem de uma build que você nos entregou, contra um escopo que você registrou. Os advisories que publicamos sobre software de terceiros seguem divulgação coordenada.

Duas builds: com e sem controles RASP

Este é o requisito que quase ninguém espera: para MAST pedimos duas versões da aplicação, uma com controles RASP e outra sem eles. Os controles em questão são detecção de root, detecção de emuladores e certificate pinning.

A autoproteção em tempo de execução muda o que um teste consegue ver, não o que um atacante consegue fazer. Uma build endurecida diz se as defesas aguentam. Uma build sem endurecimento diz o que está atrás delas: o token em texto puro em SharedPreferences, o componente exportado, a API que nunca verifica a propriedade do objeto. Um atacante que vence a detecção de root com o Frida chega a essa segunda camada, então um relatório que cobre só a primeira está descrevendo a fechadura e não o cômodo.

Como é uma avaliação MAST na prática

Tabela: cada camada de uma avaliação MAST, sua evidência e as ferramentas que nossos pentesters usam.

A parte automatizada roda como contêiner Docker. Nosso scanner MAST, fluidattacks/mast, descompila arquivos APK e procura vulnerabilidades neles; ocupa 553 MiB de instalação e 877 MiB de disco, segundo nossa documentação de scanners.

O que a automação encontra e o que lhe escapa

Medimos isso em nós mesmos. No benchmark da Fluid Attacks com 36 ferramentas de AppSec de terceiros contra uma aplicação com 1.201 vulnerabilidades semeadas, um pentester alcançou 89,6 % de recall com 100 % de precisão, enquanto a ferramenta automatizada de melhor desempenho —nosso próprio scanner— chegou a 22,7 % de recall, equivalente a 8,8 % da exposição ao risco total da aplicação medida em CVSSF.

O padrão se repete em produção. No nosso relatório State of Attacks 2026, sobre 1.119.396 vulnerabilidades reportadas durante 2025, 87 % das vulnerabilidades de severidade crítica foram identificadas por revisão manual, embora as ferramentas automatizadas tenham respondido por 88,4 % do total em quantidade. Os scanners encontram volume. As pessoas encontram as que importam.

Um scanner pode sinalizar um arquivo legível por qualquer um; não consegue raciocinar se o token que está dentro ainda autoriza uma transferência. Por isso nosso trabalho em móveis combina o scanner com pentesting de aplicações móveis, entregue como Pentesting as a Service (PTaaS) e, quando o binário resiste, como Reverse Engineering.

Onde um escaneamento limpo deixa de ser prova

Um escaneamento que não devolve nada não é uma aplicação segura, e preferimos dizer isso. Nosso próprio recall automatizado de 22,7 % é o teto que se pode creditar a qualquer scanner sozinho, e as três aplicações que nosso time quebrou em 2026 estavam publicadas no Google Play.

Vale nomear dois limites. As builds multiplataforma derrotam o fluxo padrão: uma release do Flutter compila Dart antecipadamente em um snapshot, então descompilar o APK para Java com o jadx não devolve quase nada da lógica de negócio, e o trabalho migra para o reFlutter e uma build reempacotada. E uma aplicação pode cumprir todos os controles do lado do cliente enquanto sua API entrega a qualquer usuário autenticado os registros de outro, porque esse defeito não está no binário.

A pergunta útil diante de um fornecedor não é quantas vulnerabilidades o scanner reportou. É o que a avaliação MAST fez depois que o scanner parou.

O que uma avaliação MAST precisa cobrir

Uma avaliação MAST completa deveria alcançar os oito grupos de controle do MASVS, porque cada um falha de forma independente. Nosso catálogo de fraquezas mapeia 39 requisitos de segurança para o OWASP MASVS v2.0, e os grupos abaixo seguem esse mapeamento.

Os 39 requisitos da Fluid Attacks mapeados para OWASP MASVS v2.0 em nosso banco de dados público.

Armazenamento e criptografia

O que a aplicação deixa no dispositivo e como ela protege isso. A análise estática cobre bancos de dados, preferências, caches, logs e backups, além da gestão de chaves e da escolha de algoritmos. Nossa fraqueza 020, informação confidencial não criptografada, enuncia o controle de forma direta: “em dispositivos móveis, use o armazenamento seguro da plataforma (iOS Keychain, Android Keystore) em vez do armazenamento local ou compartilhado”. Codificar não é criptografar, e um Base64 em um arquivo de preferências conta como texto puro.

Autenticação e comunicação em rede

Se as verificações de identidade acontecem onde não podem ser puladas, e se o tráfego sobrevive a um atacante no caminho. Este grupo cobre verificação biométrica, gestão de sessão, vinculação de múltiplos fatores, versões de TLS e consistência de certificados. O certificate pinning entra aqui, e também o teste que importa mais em MAST: o que a aplicação faz depois que o pinning é burlado.

Interação com a plataforma: IPC, WebViews e deep links

A superfície de ataque do Android que os scanners sub-reportam, e a que produziu dois dos nossos três advisories de 2026. As atividades exportadas, os broadcast receivers e os content providers expõem o interior de uma aplicação a qualquer outra do dispositivo. Nossa fraqueza 075, acesso não autorizado a arquivos - APK Content Provider, prescreve android:exported=false e android:grantUriPermissions=false, com uma permissão personalizada de nível Signature quando o compartilhamento é realmente necessário. Os WebViews com interfaces JavaScript habilitadas e os deep links que aceitam parâmetros não confiáveis entram na mesma categoria.

Resiliência, qualidade de código e privacidade

Resistência à manipulação, tratamento de entradas e o que a aplicação faz com dados pessoais. A fraqueza 046, ofuscação segura ausente - APK, cobre a primeira: sem ofuscação no deploy, “é possível obter o código-fonte da aplicação”. A privacidade cobre consentimento, finalidade da coleta e revogação. Os frameworks das lojas se apoiam no mesmo padrão: o MASA, da App Defense Alliance, valida que as aplicações tenham os controles de segurança definidos no MASVS, e nossa própria CLI foi aceita para validar requisitos de tier 2 do framework CASA, dentro de seus procedimentos de escaneamento estático.

O OWASP Mobile Top 10 continua útil para comunicar risco aos desenvolvedores, mas é uma lista de categorias de risco, não um plano de testes. O MASVS é contra o que MAST verifica.

O que o MAST encontrou: três vulnerabilidades móveis que reportamos em 2026

Tabela: três vulnerabilidades do Android divulgadas pelo nosso Offensive Team em setembro de 2026, com a atividade MAST que revelou cada uma.

Nosso advisory para CVE-2026-84283: um cofre protegido por PIN que guardava seus arquivos sem criptografia.

Lidas em conjunto, elas descrevem três passos MAST diferentes. A primeira veio de revisar o sistema de arquivos depois de usar a funcionalidade, não de ler código. A segunda veio do manifesto: o OpenFileProvider estava exportado sem exigir permissões e convertia o caminho de um URI fornecido por quem chamava em um caminho do sistema de arquivos, de modo que qualquer aplicação local podia fazê-lo ler, sobrescrever ou apagar arquivos em seu nome. A terceira veio de seguir uma entrada não confiável até um shell, onde um nome de arquivo SQLite com $(...) executava comandos quando a vítima tocava nele.

Nenhuma das três exigiu um dia zero no Android. Cada uma exigiu um passo MAST que alguém precisa de fato executar.

Onde a superfície de ataque móvel não termina

Uma aplicação móvel é um cliente, e seu backend faz parte da mesma superfície de ataque, então MAST não pode parar no binário. Tire a aplicação e a API continua lá, alcançável com curl, com a lógica de autorização que tiver.

A segurança de APIs móveis é onde vivem a autorização quebrada em nível de objeto, as requisições repetíveis e os tokens com permissões excessivas; nenhum aparece em um binário descompilado. Por isso nosso escopo MAST inclui os ambientes de API associados à aplicação, testados com Testes de Segurança de Aplicações Dinâmicas e manualmente.

O inverso também vale: uma API endurecida não desculpa um achado MAST como tokens de sessão guardados em texto puro, porque o dispositivo pode ser perdido, emprestado ou infectado.

Executar MAST de forma contínua

Novas builds saem toda semana, então uma avaliação anual reporta sobre uma aplicação que já não existe. Três coisas tornam o MAST contínuo.

• Escanear cada build: nosso scanner MAST roda como contêiner Docker, então se encaixa em qualquer provedor de CI/CD que suporte imagens Docker.

• Conectar a plataforma de distribuição: com TestFlight, Firebase, App Store Connect ou Google Play Store conectados, cada nova versão entra no escopo automaticamente.

• Manter as pessoas em um calendário, não em um evento: o pentesting que acompanha o ritmo das entregas encontra as falhas de lógica que a build anterior não tinha.

Combine MAST com o resto do programa — SAST, AI SAST, SCA sobre os SDKs que a aplicação empacota e um fluxo DevSecOps que quebra a build diante de violações de política. Nossos planos separam o nível automatizado daquele que inclui pentesters, cujas credenciais em móveis incluem eMAPT, GMOB e CMPen-iOS/Android, entre outras certificações.

Conclusões

MAST trata uma aplicação móvel como o que ela é: software que você compilou, assinou e então entregou a alguém cujo dispositivo você não controla. Executar MAST como se deve significa descompilar o binário, observar a aplicação em execução, alcançar os oito grupos de controle do MASVS e seguir o cliente até as APIs que estão por trás.

Nossas próprias medições dizem que a automação sozinha não chega lá. Nosso scanner MAST alcançou 22,7 % de recall em um benchmark com vulnerabilidades semeadas no qual um pentester alcançou 89,6 %, e 87 % das vulnerabilidades de severidade crítica nos nossos dados de clientes de 2025 vieram de revisão manual. Os três CVEs de Android que nosso time divulgou em 2026 estavam em aplicações já publicadas no Google Play. O escaneamento automatizado é o piso de um programa MAST, e tomá-lo como teto é como acabam sendo publicados cofres sem criptografia.

Perguntas frequentes

MAST é a mesma coisa que OWASP MASVS?

Não. MAST é a atividade de testes; OWASP MASVS é o padrão que define os controles de segurança que uma aplicação móvel deveria cumprir, e OWASP MASTG é o guia que descreve como verificá-los. Uma avaliação pode ter escopo definido contra o MASVS e ser executada com os procedimentos do MASTG, mas um relatório de escaneamento não é uma verificação MASVS.

É possível executar MAST sem o código-fonte?

Sim. Os Testes de Segurança de Aplicações Móveis normalmente partem do binário compilado, porque é o que o atacante tem. A descompilação de APK com ferramentas como jadx e Apktool recupera código e configuração, a instrumentação em execução com Frida e Objection mostra o comportamento, e um proxy expõe a camada de rede. O código-fonte torna a análise estática mais precisa, mas não é um pré-requisito.

O que um pentester encontra em uma aplicação móvel que um scanner não encontra?

Lógica de negócio e tudo o que depende de estado. No benchmark da Fluid Attacks com 36 ferramentas de AppSec de terceiros contra uma aplicação com 1.201 vulnerabilidades semeadas, um pentester alcançou 89,6 % de recall com 100 % de precisão, enquanto a melhor ferramenta automatizada chegou a 22,7 % de recall, equivalente a 8,8 % da exposição ao risco total. Nos nossos dados de clientes de 2025, 87 % das vulnerabilidades de severidade crítica vieram de revisão manual.

Como se testa uma aplicação feita com Flutter ou React Native?

De forma diferente de uma nativa. Uma release do Flutter compila Dart antecipadamente em um snapshot, então a descompilação padrão de APK para Java não devolve quase nada da lógica de negócio. A análise dinâmica migra para ferramentas feitas para esses ambientes, como o reFlutter, que reempacota a aplicação com um motor corrigido para que o tráfego e as chamadas internas fiquem observáveis. As checagens de armazenamento, plataforma e API são as mesmas de qualquer outra aplicação.

A Fluid Attacks oferece MAST e como ele é entregue?

Sim. Nosso scanner MAST roda como um contêiner Docker que descompila binários móveis e procura vulnerabilidades neles, sobre arquivos .aab, .ipa e .apk enviados diretamente ou obtidos da plataforma de distribuição da aplicação. No plano Advanced, pentesters certificados avaliam a mesma aplicação manualmente, e pedimos duas builds —uma com controles RASP como detecção de root, detecção de emuladores e certificate pinning, e outra sem eles— para que o relatório cubra tanto as defesas quanto o que está por trás delas.

Teste a aplicação que você publicou, não a que você revisou

Nossos scanners e pentesters executam MAST sobre seus binários móveis e as APIs por trás deles a cada entrega, para que as vulnerabilidades da sua próxima build sejam encontradas antes dos seus usuários. Teste gratuito · Fale conosco.