Segurança mobile: proteger o app, os dados e o usuário no dispositivo

Por que mobile tem riscos próprios

Aplicativos móveis têm uma característica que os diferencia de sistemas web: o código roda em um dispositivo que não é seu. O usuário tem controle físico, e um atacante com acesso ao aparelho pode inspecionar o app, os dados e o tráfego.

Isso muda tudo. Não basta proteger o servidor; o app precisa assumir que o ambiente é hostil. O que está no dispositivo pode ser lido, alterado e copiado.

Segurança mobile é desenhar para esse cenário: reduzir o que fica exposto, proteger o que precisa ficar e nunca confiar no app como se fosse um ambiente seguro.

A superfície de ataque de um app

A superfície de um app móvel inclui quatro áreas: o próprio aplicativo (código e recursos), os dados no dispositivo, a comunicação com serviços e as APIs que ele consome.

Em muitos casos, a API é o ponto mais crítico. O app é um cliente; as regras de negócio e os dados de verdade vivem no servidor. Uma API frágil compromete tudo, independentemente de quão robusto o app pareça.

Mapear essa superfície é o primeiro passo de qualquer avaliação de segurança mobile.

• ✓ O app: código, recursos e configuração.
• ✓ Os dados armazenados no dispositivo.
• ✓ A comunicação de rede.
• ✓ As APIs consumidas pelo app.

OWASP MASVS: o padrão para apps móveis

O OWASP MASVS (Mobile Application Security Verification Standard) organiza os requisitos de segurança para apps móveis em categorias. É a referência prática de o que verificar.

As categorias cobrem armazenamento, criptografia, autenticação, rede, interação com a plataforma, qualidade de código e resiliência contra engenharia reversa.

Usar o MASVS evita avaliação genérica. Ele dá uma estrutura concreta para revisar e testar cada aspecto do app.

• ✓ Armazenamento de dados.
• ✓ Criptografia.
• ✓ Autenticação e sessão.
• ✓ Comunicação de rede.
• ✓ Interação com a plataforma.
• ✓ Qualidade de código e resiliência.

Armazenamento seguro no dispositivo

Dados sensíveis no dispositivo precisam ser protegidos. Guardar tokens, credenciais ou informações pessoais em locais inseguros é uma das falhas mais comuns.

Cada plataforma oferece mecanismos seguros de armazenamento, apoiados em hardware quando disponível. Usar esses mecanismos corretamente é diferente de improvisar um cofre próprio.

A regra prática: se o dado não precisa estar no dispositivo, não o guarde. Menos dado armazenado é menos risco.

• ✓ Usar os mecanismos seguros da plataforma.
• ✓ Evitar guardar o que não é necessário.
• ✓ Não armazenar segredos em texto claro.
• ✓ Cuidar de caches e arquivos temporários.

Comunicação: TLS, pinning e o erro comum

Toda comunicação deve usar TLS. Mas confiar cegamente no TLS padrão, sem verificar a identidade do servidor, deixa o app aberto a interceptação com certificados não confiáveis.

Certificate pinning resolve parte disso ao fixar o certificado esperado, dificultando ataques de homem no meio. O erro comum é aplicá-lo mal, de forma que uma troca legítima de certificado derrube o app.

O equilíbrio é importante: pinning precisa ser feito com cuidado e com plano de rotação, para não criar indisponibilidade quando o certificado mudar.

• ✓ TLS em toda comunicação.
• ✓ Pinning para resistir a interceptação.
• ✓ Plano de rotação de certificados.
• ✓ Cuidado para não derrubar o app.

Autenticação e sessão em mobile

Autenticação em mobile tem particularidades: o dispositivo pode ser compartilhado, perdido ou roubado, e o app fica ativo por longos períodos.

Tokens de sessão precisam de proteção extra, expiração adequada e capacidade de revogação. O armazenamento seguro da seção anterior se conecta diretamente a isso.

Usar os recursos da plataforma — como biometria e armazenamento protegido — melhora a segurança sem prejudicar a experiência.

• ✓ Proteger tokens com armazenamento seguro.
• ✓ Expiração e revogação de sessão.
• ✓ Uso de biometria quando fizer sentido.
• ✓ Cuidado com dispositivos compartilhados.

Engenharia reversa e resiliência

Um app distribuído pode ser baixado e analisado. Não há como impedir totalmente a engenharia reversa, mas dá para dificultá-la e, principalmente, evitar que ela exponha algo crítico.

A resiliência contra análise inclui técnicas de dificultação, detecção de ambiente comprometido e proteção de partes sensíveis. Nada disso substitui não colocar segredo no app.

O princípio é simples: assuma que o app pode ser lido e não deposite nele nada que não possa ser exposto.

• ✓ Dificultar a análise sem depender disso.
• ✓ Detectar dispositivos comprometidos.
• ✓ Proteger trechos sensíveis.
• ✓ Nunca confiar em segredo embarcado.

Segredos e chaves: nunca no app

Colocar chaves de API, senhas ou segredos dentro do app é uma falha clássica. Qualquer segredo embarcado pode ser extraído.

Segredos devem viver no servidor. O app fala com sua API, e a API guarda e usa as credenciais. Chaves que precisam existir no cliente devem ter escopo mínimo e nenhum poder além do necessário.

Essa é uma das regras mais importantes de segurança mobile e, ainda assim, uma das mais violadas.

• ✓ Segredos ficam no servidor.
• ✓ O app usa a própria API como intermediária.
• ✓ Chaves no cliente têm escopo mínimo.
• ✓ Nenhum segredo embarcado no app.

Testes: estático, dinâmico e em dispositivo

Segurança mobile se testa de várias formas. A análise estática examina o código e o pacote em busca de problemas. A análise dinâmica observa o app em execução, testando armazenamento, rede e comportamento.

Testar em dispositivo real é importante: emuladores não reproduzem tudo, e certas falhas só aparecem no ambiente real.

A API consumida pelo app também precisa ser testada, porque é onde os dados de verdade estão. Segurança mobile sem teste de API é avaliação incompleta.

• ✓ Análise estática do pacote e do código.
• ✓ Análise dinâmica em execução.
• ✓ Teste em dispositivo real.
• ✓ Teste da API consumida.

Ciclo de vida e atualizações

Apps móveis têm ciclo de vida próprio: publicação em loja, distribuição gradual, versões antigas em uso e atualizações que nem todos instalam.

Isso cria um desafio: corrigir uma falha não garante que todos os usuários estejam protegidos. Versões antigas continuam circulando e precisam de atenção.

Estratégias como exigir versão mínima, forçar atualização em falhas críticas e remover funcionalidades inseguras ajudam a lidar com esse cenário.

• ✓ Versões antigas continuam em uso.
• ✓ Exigir versão mínima quando necessário.
• ✓ Forçar atualização em falhas críticas.
• ✓ Planejar o ciclo desde o lançamento.

Erros comuns

Os erros mais frequentes são embarcar segredos, armazenar dados sensíveis de forma insegura, confiar só no TLS sem pinning e tratar a segurança do app como suficiente sem avaliar a API.

Todos compartilham a mesma raiz: tratar o dispositivo como ambiente confiável. Em mobile, o dispositivo é do usuário — e pode estar nas mãos de um atacante.

• ✓ Segredos embarcados no app.
• ✓ Armazenamento inseguro de dados.
• ✓ Ausência de pinning.
• ✓ Ignorar a segurança da API.

Checklist de segurança mobile

O checklist abaixo resume o essencial para avaliar e proteger um app móvel.

• ✓ Aplicar as categorias do OWASP MASVS.
• ✓ Usar armazenamento seguro da plataforma.
• ✓ TLS em tudo, com pinning cuidadoso.
• ✓ Proteger tokens e sessão.
• ✓ Nenhum segredo embarcado no app.
• ✓ Testar estática, dinâmica e em dispositivo real.
• ✓ Avaliar a API consumida pelo app.
• ✓ Planejar ciclo de vida e atualizações.

Como a SECVOLT ajuda

Avaliamos a segurança de apps móveis e das APIs que eles consomem, usando o OWASP MASVS como referência. O trabalho cobre o app, o armazenamento, a rede e o servidor.

Começamos por um diagnóstico curto: o que o app expõe hoje, quais falhas são mais relevantes e o que deve ser priorizado. Sem relatório genérico, com foco no que reduz risco de verdade e no que pode ser corrigido primeiro, de forma prática e mensurável.

Perguntas frequentes