Segurança de aplicativos mobile: Android, iOS e as falhas mais comuns

Segurança de aplicativos mobile tem uma diferença fundamental em relação à segurança web, e ignorá-la é a raiz da maioria das falhas: no mundo web, o servidor está sob seu controle e apenas o navegador roda no ambiente do usuário. No mundo mobile, o seu aplicativo inteiro roda no dispositivo do usuário, um ambiente que você não controla e que pode ser hostil. O aparelho pode estar com root ou jailbreak, o app pode ser descompilado, o tráfego pode ser interceptado, o armazenamento pode ser inspecionado. Tudo o que você embute no app está, em teoria, nas mãos de quem quiser examiná-lo.

Essa mudança de premissa reorganiza as prioridades. Não basta pensar na comunicação com a API; é preciso pensar no que o app guarda, no que ele expõe quando desmontado e em como ele se comporta em um dispositivo comprometido. Para organizar esse trabalho, existe o OWASP MASVS (Mobile Application Security Verification Standard), o padrão de referência para segurança mobile. Este guia percorre as falhas mais comuns em Android e iOS e como preveni-las.

A premissa: o dispositivo é território hostil

Antes das falhas específicas, o princípio que as conecta: nunca confie no cliente. No mobile, isso é literal. Você deve assumir que um atacante determinado pode:

• Ler o armazenamento do aplicativo, incluindo arquivos, bancos locais e preferências.
• Descompilar o app e ler o código, strings e recursos embutidos.
• Interceptar o tráfego entre o app e o servidor.
• Rodar o app em um dispositivo com root/jailbreak, contornando proteções do sistema.

A consequência prática é dura e libertadora ao mesmo tempo: segredos e lógica sensível não pertencem ao app. Chaves de API críticas, regras de negócio que não podem ser burladas e validações de segurança precisam viver no servidor, onde você tem controle. O app é uma interface confiável para o usuário, mas não confiável para conter segredos.

Armazenamento inseguro de dados

É uma das falhas mais frequentes e mais graves. O aplicativo guarda dados sensíveis (tokens de sessão, dados pessoais, informações de pagamento) em locais inseguros do dispositivo, de onde podem ser extraídos. Os erros clássicos:

• Salvar tokens ou senhas em texto claro em arquivos, em bancos SQLite locais ou nas preferências compartilhadas.
• Deixar dados sensíveis em logs do aplicativo, que podem ser lidos por outros apps ou por ferramentas.
• Guardar informação sensível em cache ou em backups não protegidos.

A defesa é usar os mecanismos seguros que cada plataforma oferece, feitos exatamente para isso:

• No Android, o Keystore para chaves e as EncryptedSharedPreferences para dados sensíveis.
• No iOS, o Keychain, protegido por hardware, para credenciais e segredos.

A regra de ouro do armazenamento: guarde o mínimo possível e, o que precisar guardar, guarde sempre criptografado nos cofres da plataforma. Um token que não está no dispositivo é um token que não vaza dele.

Comunicação insegura e certificate pinning

Todo tráfego entre o app e o servidor deve ser cifrado com TLS, sem exceção. Isso é o básico. O erro comum aqui não é a ausência de TLS, e sim aceitar certificados que não deveriam ser aceitos, abrindo espaço para ataques de intermediário (man in the middle), em que alguém na mesma rede intercepta e lê a comunicação.

Uma camada adicional importante é o certificate pinning. Com ele, o aplicativo não confia em qualquer certificado válido: ele "fixa" (pin) o certificado ou a chave pública esperada do seu servidor e recusa qualquer outro, mesmo que tecnicamente válido. Isso derrota a interceptação feita com certificados fraudulentos instalados no dispositivo. O pinning exige cuidado operacional (a rotação do certificado precisa ser planejada para não quebrar apps antigos), mas eleva significativamente a barreira contra interceptação.

Engenharia reversa e proteção do código

Como o app roda no dispositivo, ele pode ser descompilado e analisado. Um atacante faz isso para entender a lógica, encontrar segredos embutidos, localizar endpoints internos e descobrir como burlar validações. Não dá para impedir a engenharia reversa por completo, mas dá para dificultá-la e reduzir o que ela revela:

• Não embuta segredos no app: chaves de API sensíveis, credenciais e lógica crítica ficam no servidor. Um segredo no binário é um segredo público.
• Ofuscação de código: ferramentas que embaralham nomes e estrutura tornam a leitura do código descompilado muito mais trabalhosa. Não é segurança por si só, é atrito adicional.
• Detecção de root/jailbreak e de adulteração: o app pode detectar se roda em um ambiente comprometido ou se foi modificado, e reagir (por exemplo, limitando funções sensíveis). É uma camada a mais, que um atacante avançado pode contornar, mas que barra os oportunistas.

O princípio permanece: a segurança não pode depender do sigilo do código do app. A ofuscação atrasa o atacante; ela não substitui ter a lógica crítica no servidor.

Permissões e exposição de dados

Aplicativos pedem permissões (câmera, localização, contatos, armazenamento), e cada permissão é uma responsabilidade. Duas falhas comuns:

• Excesso de permissões: pedir mais do que a função exige aumenta a superfície de risco e mina a confiança do usuário. O princípio é o do menor privilégio: solicite apenas o necessário, no momento em que é necessário.
• Exposição de componentes: no Android, componentes exportados sem proteção adequada podem ser acionados por outros apps maliciosos. Componentes que não precisam ser públicos devem permanecer privados.

Cuidar de permissões é também uma questão de privacidade e de conformidade com a LGPD: coletar menos dados é, ao mesmo tempo, menos risco e mais respeito ao usuário.

Panorama das falhas e defesas

Falha comum	Risco	Defesa central
Armazenamento inseguro	Extração de tokens e dados	Keychain / Keystore, guardar o mínimo
Comunicação insegura	Interceptação (MITM)	TLS obrigatório + certificate pinning
Segredos no binário	Vazamento por engenharia reversa	Segredos e lógica crítica no servidor
Engenharia reversa	Burla de validações, mapeamento	Ofuscação, detecção de root/adulteração
Excesso de permissões	Superfície e privacidade	Menor privilégio, pedir sob demanda
Componentes expostos	Abuso por outros apps	Manter privado o que não precisa ser público

Segurança mobile é assumir que o cliente não é confiável

O fio que costura todas essas práticas é a mesma premissa do início: o dispositivo do usuário é território que você não controla, e o app precisa ser projetado para isso. Guarde o mínimo e sempre nos cofres da plataforma, cifre e fixe a comunicação, mantenha segredos e lógica crítica no servidor, dificulte a engenharia reversa e peça só as permissões que usa. Nenhuma dessas medidas isolada torna um app "inquebrável", mas juntas elas movem o app de um alvo fácil para um alvo caro, que é o objetivo realista da segurança. O padrão OWASP MASVS existe justamente para dar a essa checagem um roteiro verificável.

Na ConstructorTI, ajudamos times a elevar a segurança de seus aplicativos Android e iOS: avaliação contra o OWASP MASVS, testes de armazenamento e comunicação, verificação de certificate pinning, análise de engenharia reversa e revisão de permissões e superfície exposta. Se você tem um app em produção lidando com dados de usuários e quer saber o que um atacante veria ao desmontá-lo, converse com o nosso time de CyberSecurity.