Aplicativos mobile estão no centro da vida digital e, por isso, viraram alvo preferencial de ataques. Segurança não é só “criptografar e pronto”: envolve decisões de arquitetura, privacidade por padrão, controles de runtime e uma pipeline de build que não deixa brecha.

1) Vulnerabilidades comuns (visão prática)

• Armazenamento inseguro: tokens/senhas em SharedPreferences/NSUserDefaults ou BD local sem hardware-backed keys.
• Tráfego inseguro: HTTP/cleartext, validação de hostname ausente, pinning inexistente ou mal implementado.
• APIs expostas: endpoints sem autorização por recurso, sem rate limiting e sem proteção contra replay.
• Logs verbosos: credenciais e PII em logs/debug builds indo para ferramentas externas.
• Frameworks desatualizados: dependências com CVEs não corrigidos.
• Ambiente comprometido: root/jailbreak, emuladores e hooking (Frida/Xposed) sem detecção.

2) Modelos de app e implicações de segurança

Não é só “nativo vs híbrido”. Existem perfis com superfícies de ataque diferentes:

• Nativo (Android/iOS): Android (Kotlin/Java) e iOS (Swift/Objective-C).
  Prós: acesso direto a Secure Enclave/Keychain e Android Keystore, melhor controle de rede e criptografia.
  Cuidados: manifest/entitlements, ATS/Network Security Config, políticas de permissões, desativar debuggable no release.
• Híbrido (WebView-centric): Cordova/Ionic/Capacitor.
  Prós: velocidade de entrega.
  Riscos: JavaScript bridge, bypass de navegação segura, exposição de APIs via addJavascriptInterface, políticas CSP fracas.
• Cross-platform (camada nativa + bridge): React Native (JS/TS), Flutter (Dart), .NET MAUI/Xamarin (C#), Kotlin Multiplatform Mobile (KMM), NativeScript.
  Prós: produtividade, compartilhamento de lógica.
  Riscos: superfície do bridge nativo, plugins de terceiros, diferenças de suporte a pinning/crypto/secure storage entre plataformas.
• PWA (Progressive Web App): roda no browser, empacotável em lojas.
  Prós: atualização rápida.
  Riscos: sem acesso a enclaves de hardware e limitações para segredos; depende totalmente de TLS/HTTP e políticas do navegador.
• Games/Engines: Unity/Unreal (C# / C++).
  Riscos: obfuscação/anti-tamper específicos, proteção de assets e integridade do cliente contra trapaças.

3) Privacidade & regulações

Não colete dados que não sejam essenciais ao propósito do app — princípio de minimização. Exemplos que geralmente não devem ser coletados por padrão:

• Números de telefone do usuário e de contatos, listas de apps instalados, IMEI/serial/IDs persistentes.
• Localização precisa se apenas a aproximada resolve; áudio/vídeo em background sem clara necessidade.
• Dados biométricos fora das APIs oficiais do SO; qualquer PII sem base legal e sem consentimento granular.

Android — mudanças relevantes de privacidade:

• Photo Picker: acesso a fotos/vídeos selecionados, sem permissão ampla da galeria.
• Permissão de notificações em tempo de execução (POST_NOTIFICATIONS).
• Localização aproximada por padrão; limites a identificadores e package visibility.
• Restrições de clipboard e serviços em segundo plano em versões recentes.

iOS — privacidade reforçada:

• App Tracking Transparency (ATT) limitando acesso ao IDFA e rastreamento entre apps.
• Privacy “nutrition labels” e requisitos de transparência na App Store.
• Permissões runtime mais granulares (ex.: fotos parciais, localização “While Using”).

Tradução prática: declare só o necessário, explique claramente o uso, ofereça opt-in/opt-out e registre consentimentos.

4) Assinatura de requests e comunicação segura

Além de TLS, use assinatura de requisições para mitigar replay e adulteração:

• Canonização do request (método, caminho, headers críticos, body hash).
• Nonce + timestamp curto (ex.: 5 min) para invalidar replays.
• Assinatura HMAC com chave de sessão efêmera obtida do servidor após autenticação (evitar chaves estáticas no app).
• Token bind: associe a sessão ao dispositivo/contexto quando possível.
• Certificate pinning: fixe SPKI ou CA com plano de rotação; trate failures com fallback controlado.

Importante: segredos de assinatura não vivem no binário. Proteja-os derivando chaves de curto prazo + atestação do app/dispositivo.

5) Verificação de integridade (cliente e dispositivo)

• Android: use Play Integrity API para atestar se a ação vem do seu app legítimo, instalado via Play, rodando em dispositivo certificado. Valide o verdict no servidor.
• iOS: use App Attest (DeviceCheck) para provar a legitimidade da instância do app e reduzir fraude/abuso. Verificação também no servidor.
• Checks adicionais: root/jailbreak, debug/emulador, hooking, integridade do pacote e do certificado de assinatura, política de tamper-evidence.

6) Proteções em runtime

• Anti-debug/hooking: detectar ptrace, Frida, Xposed; atrasar ou encerrar operações sensíveis.
• Anti-tamper: verificação de integridade do binário e dos recursos; validação do certificado do app.
• Ofuscação: R8/ProGuard no Android; ofuscação/renomeação em iOS; criptografia de strings sensíveis.
• Runtime hardening: apagar chaves da memória, evitar strings de segredos, sanitizar exceções.
• Nota: RASP aumenta custo do ataque, não elimina engenharia reversa. Combine com atestação + políticas servidor.

7) Pipeline de segurança (CI/CD)

• SAST: análise estática por linguagem (Detekt/Ktlint p/ Kotlin; SwiftLint/SwiftFormat p/ Swift).
• SCA/SBOM: inventário de dependências (Gradle/CocoaPods/SwiftPM) + alerta de CVEs; gere SBOM (CycloneDX).
• Secret scanning: bloquear chaves/segredos (GitLeaks/TruffleHog) no repositório e nos artefatos.
• Políticas de build: checar android:debuggable=false, minifyEnabled=true, ATS/NSAppTransportSecurity e Network Security Config.
• Teste dinâmico: suíte automatizada em emuladores/dispositivos; casos de TLS/Pinning/timeout.
• Gate de conformidade: checklist com OWASP MASVS (controles por domínio) antes de liberar versões.
• Assinatura e distribuição: code signing controlado, chaves guardadas em HSM/CI seguro; validação automática de entitlements/permissions.

8) SDKs e bibliotecas de terceiros

• Permissões mínimas: recuse SDKs que exigem acesso amplo sem justificativa.
• Atualização rápida: plano de “hotfix window” quando sair CVE de SDK crítico.
• Isolamento: encapsule SDKs sensíveis atrás de facades; centralize políticas (telemetria, coleta de dados).
• Observabilidade: métricas e logs por SDK para desligar remoto em caso de incidente.

9) Logs, telemetria e PII

• Sem PII em logs (tokens, CPF, e-mail, números de cartão).
• Redação de campos sensíveis antes de enviar para observabilidade.
• Retention mínima e segregação de dados por finalidade.
• Mascaramento no cliente (ex.: esconder números em tela; bloquear screenshots em telas sensíveis).

10) Hardening por plataforma

Android

• Keystore com chaves hardware-backed; setUserAuthenticationRequired para operações críticas.
• Network Security Config: cleartextTrafficPermitted=false e pins configurados com rotação.
• Restringir intents, deep links e exported=true só quando necessário.
• Play Integrity no fluxo de login/ações de alto risco (verificação no servidor).

iOS

• Keychain protegido por Secure Enclave; acessos condicionados a biometria quando aplicável.
• ATS ativo (TLS forte); exceções documentadas e mínimas.
• App Attest para validar instância do app; DeviceCheck para sinais de risco.
• Bloquear captura de tela em telas críticas e limpar conteúdo em background.

11) Checklist de release

• Sem segredos no repositório/artefatos; SBOM gerado e auditado.
• Pinning testado + estratégia de rotação.
• Assinatura de requests ativada nas rotas sensíveis (com nonce/timestamp).
• Atestação (Play Integrity/App Attest) validada no backend.
• Permissões/entitlements revisados; ATT/consentimentos ok; políticas de privacidade atualizadas.
• Gate MASVS aprovado; builds release não-debug; ofuscação ativa.

12) Conclusão

Segurança mobile de verdade conecta decisões de arquitetura, privacidade por padrão, comunicação assinada, verificação de integridade e uma pipeline que não deixa passar dependência vulnerável nem permissão indevida. Com esse baseline, você reduz superfície de ataque, dificulta fraude e protege seus usuários sem matar a experiência.