# O mapa da segurança mobile: OWASP MASVS, MASWE e MASTG

> O que muda quando o alvo do pentest é um app, como o OWASP MAS se organiza entre padrão, fraquezas e testes, e o caminho desta série.

- Autor: Marcelo Silva
- Publicado em: 2026-10-06
- Tema: Segurança
- Série: Segurança Mobile, parte 1 de 2 (https://marcelxsilva.dev/series/seguranca-mobile/)
- URL: https://marcelxsilva.dev/artigos/o-mapa-da-seguranca-mobile/

Quem desenvolve app mobile costuma pensar em segurança do lado do servidor: autenticação, rate limit, validação de entrada. O app é visto como uma "casca" que conversa com a API. O problema é que essa casca roda num aparelho que não é seu, na mão de alguém que pode abrir, modificar e observar tudo o que ela faz.

Rodar uma ferramenta de análise e receber um relatório, como no artigo [O seu app React Native está seguro?](https://marcelxsilva.dev/artigos/o-seu-app-react-native-esta-seguro/), é só a superfície da **segurança mobile**. Por baixo existe uma área inteira, com padrão de verificação, catálogo de fraquezas e método de teste próprios.

Este artigo é um mapa dessa área: o que muda quando o alvo é um app, como o material de referência da OWASP se organiza e quais são os modos de teste.

## O que muda quando o alvo é um app

Num teste de aplicação web, o código que importa está no servidor e você só vê o que ele devolve. No mobile é o contrário: **o código inteiro do cliente está na mão do atacante**.

Isso muda o modelo de ameaça:

- O APK pode ser baixado, descompactado e decompilado. Tudo o que foi embarcado nele (chaves de API, URLs internas, lógica de validação, flags de feature) pode ser lido.
- O aparelho pode estar com root, rodando num emulador ou com um framework de instrumentação injetado no processo do app. Nesse cenário o atacante muda o comportamento de qualquer função em tempo de execução.
- O tráfego pode ser interceptado colocando um proxy no meio, mesmo com HTTPS, se o app confiar no certificado errado.
- Os dados que o app grava no aparelho (banco local, preferências, cache, logs) podem ser lidos por quem tem acesso físico, por outro app com uma brecha ou por um backup.
- O app conversa com outros apps e com o sistema através de componentes expostos, deep links e WebViews. Cada uma dessas portas é uma superfície de ataque.

Então a pergunta deixa de ser só "minha API está protegida?" e passa a ser também "o que alguém consegue fazer com o meu app quando ele está num aparelho que essa pessoa controla?".

### Pentest só com autorização

Antes de qualquer coisa: testar um app que não é seu, sem autorização por escrito, é crime em boa parte dos países, inclusive no Brasil. Para treinar existem apps vulneráveis de propósito, como os [MAS Crackmes](https://mas.owasp.org/crackmes/) da OWASP.

## O OWASP MAS

A principal referência da área é o [OWASP Mobile Application Security](https://mas.owasp.org/), o projeto da OWASP dedicado a apps mobile. Ele não é um documento só, é um conjunto de peças que se encaixam:

| Peça | O que é | Pergunta que responde |
|---|---|---|
| **MASVS** | Padrão de verificação | O que um app seguro precisa garantir? |
| **MASWE** | Catálogo de fraquezas | Quais são as formas concretas de falhar nisso? |
| **MASTG** | Guia de testes | Como eu verifico, na prática, se o app falha? |
| **MAS Checklist** | Lista para auditoria | Como eu acompanho o que já foi testado? |

O caminho entre elas é sempre o mesmo: um **controle** do MASVS se desdobra em várias **fraquezas** do MASWE, e cada fraqueza tem um ou mais **testes** no MASTG que dizem como encontrá-la.

### MASVS: o que garantir

O [MASVS](https://mas.owasp.org/MASVS/) divide a segurança de um app em oito grupos de controles:

| Grupo | Do que trata |
|---|---|
| `MASVS-STORAGE` | Dados sensíveis guardados no aparelho |
| `MASVS-CRYPTO` | Uso correto de criptografia e gestão de chaves |
| `MASVS-AUTH` | Autenticação e autorização, incluindo biometria |
| `MASVS-NETWORK` | Comunicação segura, TLS e pinning de certificado |
| `MASVS-PLATFORM` | Interação com o sistema e outros apps: IPC, WebViews, UI |
| `MASVS-CODE` | Qualidade de código, dependências e validação de entrada |
| `MASVS-RESILIENCE` | Resistência a engenharia reversa e adulteração |
| `MASVS-PRIVACY` | Coleta mínima de dados, transparência e controle do usuário |

Cada grupo tem fraquezas, ferramentas e técnicas próprias.

### Perfis: nem todo app precisa de tudo

Um app de lista de compras e um app de banco não precisam do mesmo nível de proteção. Por isso a OWASP define **perfis** que dizem quais testes se aplicam:

- **L1**: o básico que todo app deveria cumprir.
- **L2**: defesa em profundidade, para apps que lidam com dados sensíveis (saúde, finanças, documentos).
- **R**: resiliência contra engenharia reversa e adulteração, para quando o próprio app é o ativo a proteger (jogos, DRM, apps que não podem ser clonados).
- **P**: privacidade, para avaliar como o app coleta e usa dados pessoais.

Um app bancário, por exemplo, geralmente é testado em L2 + R. Isso é importante porque evita o erro de tratar como vulnerabilidade algo que nem fazia parte do escopo, como reclamar da falta de detecção de root num app que não precisa disso.

### MASTG: como testar

O [MASTG](https://mas.owasp.org/MASTG/) é a parte mais prática. Ele é organizado em tipos de conteúdo, cada um com um identificador próprio:

| Conteúdo | Para que serve |
|---|---|
| **Knowledge** | Como a plataforma funciona naquele ponto (armazenamento, rede, IPC) |
| **Tests** | O procedimento para verificar uma fraqueza específica |
| **Techniques** | Passo a passo reutilizável: instalar um app, extrair o APK, interceptar tráfego |
| **Tools** | Ferramentas usadas nos testes, por plataforma |
| **Demos** | Exemplos executáveis de um teste, com código e saída esperada |
| **Best practices** | Como corrigir o que foi encontrado |
| **Apps** | Apps vulneráveis de propósito, para treinar |

A página de [ferramentas](https://mas.owasp.org/MASTG/tools/) separa tudo em genéricas, Android, iOS e rede. Algumas das mais citadas:

| Categoria | Ferramentas | Uso |
|---|---|---|
| Android | `adb`, `jadx`, `apktool`, `apksigner` | Falar com o aparelho, decompilar, desmontar e reassinar o APK |
| Genéricas | Frida, objection, Ghidra, radare2 | Instrumentar o app em execução e analisar código nativo |
| Rede | Burp Suite, mitmproxy, Wireshark | Interceptar e modificar o tráfego |
| Análise automatizada | MobSF | Um primeiro raio-x do APK, estático e dinâmico |

## Estático, dinâmico e o tamanho da caixa

Os testes de app se dividem em dois grandes modos:

- **Análise estática**: olhar o app sem executar. Ler o `AndroidManifest.xml`, decompilar o bytecode, procurar segredos embarcados, ver quais componentes estão exportados. No caso de React Native, olhar o bundle JavaScript.
- **Análise dinâmica**: observar e manipular o app rodando. Interceptar tráfego, inspecionar o que ele grava em disco, chamar componentes expostos, usar Frida para trocar o retorno de uma função.

Uma não substitui a outra. A estática mostra o que **pode** acontecer; a dinâmica confirma o que **acontece** de fato. Na prática as duas se alternam: uma função suspeita encontrada na estática é confirmada, ou descartada, na dinâmica.

Também muda o quanto o testador sabe do alvo:

- **Caixa preta**: só o app publicado, como um atacante teria.
- **Caixa cinza**: o app mais alguma ajuda, como um build sem ofuscação ou credenciais de teste.
- **Caixa branca**: acesso ao código-fonte.

A caixa preta mostra o que um atacante enxerga; a caixa branca mostra por que aquilo acontece e onde está a origem no código.

## Android e React Native

O MASTG cobre Android e iOS. O Android costuma ser a porta de entrada por três motivos:

- **Acesso**: dá para fazer quase tudo num emulador gratuito, com root, sem precisar de aparelho físico.
- **Abertura**: o sistema é open source. Quando surgir uma dúvida sobre como algo funciona por dentro, dá para ler o código do próprio Android.
- **Material**: a maior parte do conteúdo de pentest mobile, incluindo o HackTricks, é mais extensa para Android.

Apps React Native acrescentam uma camada a esse cenário. O código JavaScript vai dentro do APK como um bundle, normalmente compilado para o bytecode do Hermes, e conversa com o lado nativo através de módulos expostos pela ponte entre JS e Kotlin/Java. Isso muda onde ficam os segredos embarcados, como a lógica é decompilada e quais fraquezas aparecem só nesse tipo de app.

## Além da OWASP

O [guia de pentest Android do HackTricks](https://hacktricks.wiki/mobile-pentesting/android-app-pentesting/index.html) é outra referência muito usada. Ele é menos formal que o MASTG e mais próximo de um caderno de campo: técnicas, comandos e truques organizados por tema, útil como checklist para conferir o que um teste cobriu e o que ficou de fora.