Segurança em aplicativos móveis: 8 erros e como evitar

O vendedor externo esquece o celular no táxi. O aparelho não tem senha de bloqueio, o aplicativo da empresa abre direto, sem pedir login, e mostra a carteira de clientes com CNPJ, telefone, histórico de compras e condições comerciais. Ninguém consegue derrubar o acesso porque o app nunca pediu para o usuário entrar de novo desde a instalação.

Em outra empresa, um ex-prestador baixa o instalador do aplicativo publicado na loja, abre o pacote com uma ferramenta gratuita e encontra, em texto puro, a chave que dá acesso total à API do sistema de gestão. Com ela, consulta pedidos de todos os clientes sem passar pela tela de login.

Os dois cenários são ilustrativos e nenhum exige atacante sofisticado: nascem de decisões de conveniência que ficaram. Segurança em aplicativos móveis, para uma empresa, se resume a duas perguntas: o que fica guardado no aparelho e o que o servidor aceita sem conferir. A seguir, os erros mais frequentes em apps corporativos, por que cada um acontece e o controle de engenharia que o previne.

Os erros comuns, em resumo

Para quem precisa da resposta rápida, esta é a lista que usamos como ponto de partida em revisões de apps corporativos:

Por que o app não pode ser a única barreira

O ponto de partida é aceitar uma ideia que contraria a intuição: o aplicativo instalado no celular do usuário está fora do seu controle. O pacote publicado na loja pode ser baixado, descompactado e inspecionado. O tráfego entre o app e o servidor pode ser observado pelo próprio dono do aparelho. Um celular com root ou jailbreak permite alterar o comportamento do app enquanto ele roda.

Isso não significa que o app seja inseguro por natureza. Significa que o app é um cliente, e cliente não é barreira. Esconder um botão, desabilitar um campo ou validar um desconto máximo só na tela são decisões de experiência, não de segurança. A barreira real está no servidor, que precisa tratar cada requisição como se viesse de alguém tentando burlar a regra. Isso pesa na escolha entre Firebase ou back-end próprio para o app.

Na prática, a segurança de um app corporativo se divide em duas frentes:

• O que fica no aparelho: dados, credenciais, cache e logs. Aqui o objetivo é reduzir o estrago quando o celular é perdido, roubado ou inspecionado.
• O que fica no servidor: autenticação, autorização e regras de negócio. Aqui está a proteção de verdade.

Dados sensíveis guardados no aparelho

O erro mais frequente é salvar no armazenamento comum do app, sem proteção, informação que não deveria estar lá: token de acesso, senha "para não pedir de novo", dados de clientes, fotos de documentos, assinaturas.

O armazenamento comum é prático para o desenvolvedor e por isso é o primeiro que se usa. O problema é que ele pode ser lido em aparelhos comprometidos, pode entrar em backups e, dependendo da configuração, fica acessível a ferramentas de diagnóstico.

O que fazer:

1. Guarde o mínimo. A primeira pergunta não é "como proteger", e sim "precisa estar no aparelho?". Senha do usuário nunca precisa.
2. Credenciais vão para a área segura do sistema. iOS e Android oferecem armazenamento protegido por hardware ou pelo sistema operacional (Keychain e Keystore). Token de sessão fica ali, não num arquivo de configuração.
3. Dados de negócio sensíveis ficam criptografados, com a chave guardada na área segura, não ao lado do banco local.
4. Fotos e documentos capturados pelo app ficam na área privada do aplicativo, não na galeria do aparelho, e são apagados depois de enviados quando não há motivo para mantê-los.
5. Revise o que entra em backup e o que aparece na pré-visualização de apps recentes, que pode mostrar a última tela aberta.

Dado pessoal no aparelho também é tratamento de dados sob a LGPD (Lei 13.709/2018). Guardar menos é, ao mesmo tempo, mais seguro e mais fácil de justificar, como explicamos em LGPD no desenvolvimento de sistemas.

Chaves e segredos dentro do app

Chave de API, senha de banco, token de serviço de mapas com permissão ampla, credencial de envio de e-mail: tudo isso aparece com frequência embutido no código de aplicativos. A lógica costuma ser "o código é compilado, ninguém vai ler". Lê. Ferramentas gratuitas abrem o pacote em minutos, e ofuscação só aumenta um pouco o trabalho.

A regra é simples: o app não guarda nenhum segredo que dê acesso além do que o próprio usuário logado já tem.

• Credencial por usuário. O app autentica a pessoa e recebe do servidor um token com o escopo dela. Não existe "chave mestra do aplicativo".
• Serviços de terceiros passam pelo seu servidor quando a credencial dá poder amplo (envio de SMS, consulta de crédito, emissão de documentos). O app pede ao seu backend, que valida e chama o serviço.
• Chaves públicas por natureza (como as de alguns serviços de mapas ou de notificação) são restritas ao identificador do app e ao uso específico, no painel do próprio serviço.
• Rotação planejada. Se uma chave vazou numa versão antiga, você precisa conseguir trocá-la sem esperar todos os usuários atualizarem o app.

Comunicação segura com a API

O app conversa com a API o tempo todo, e é na API que mora a maior parte dos problemas. O caso clássico: o app de pedidos calcula o desconto, monta a requisição com o preço final e o servidor grava o que recebeu. Basta alterar a requisição para vender pelo preço que quiser.

O servidor precisa:

• Recalcular preço, desconto, comissão e impostos, usando a requisição apenas como intenção ("quero estes itens"), nunca como verdade.
• Verificar permissão a cada chamada, por usuário e por objeto. O representante só lê os clientes da carteira dele, mesmo que troque o código do cliente na requisição.
• Limitar volume de chamadas por usuário e por aparelho, para conter abuso e extração em massa.
• Devolver só o que a tela usa, em vez do registro inteiro com campos internos.

Esses pontos são os mesmos de qualquer API, e estão detalhados em segurança de APIs: os erros mais comuns em produção.

Do lado do transporte, o básico é HTTPS em todas as chamadas, sem exceção. O erro típico é a liberação de tráfego sem criptografia ou a aceitação de qualquer certificado, configuradas para facilitar o teste em homologação e que vão para produção por esquecimento. Para apps que lidam com dados especialmente sensíveis, vale avaliar a fixação de certificado (certificate pinning), que faz o app aceitar só o certificado esperado do seu servidor. Ela aumenta a proteção, mas exige um plano de troca de certificado; sem isso, a renovação pode deixar o app sem conexão.

Sessões, biometria e aparelho perdido

"O usuário reclamou de ter que fazer login" é a origem de muitas sessões que nunca expiram. A preocupação com a experiência é legítima, mas a resposta não é eliminar a expiração. É combinar sessão curta com renovação conveniente.

O desenho que costuma funcionar:

• Token de acesso de vida curta, renovado em segundo plano por um token de renovação guardado na área segura.
• Biometria para destravar, não para substituir a autenticação. A digital ou o rosto liberam o uso do token já guardado no aparelho; quem decide se a sessão ainda vale é o servidor.
• Revogação real. Ao desligar um funcionário ou receber o aviso de aparelho perdido, o gestor derruba as sessões daquele usuário ou daquele aparelho, e a próxima chamada é recusada.
• Lista de aparelhos conectados, para o próprio usuário ou o administrador ver de onde há acesso ativo.
• Reautenticação em ações críticas, como aprovar pagamento, alterar dados bancários ou exportar uma lista de clientes.

Se a empresa usa gestão de dispositivos móveis (MDM) nos aparelhos corporativos, ela ajuda a exigir bloqueio de tela e a apagar dados remotamente. Mas o app não deve depender disso: muitos usuários instalam o aplicativo no celular pessoal.

Apps offline e dados em cache

Aplicativo de campo precisa funcionar sem sinal: o técnico na zona rural, o vendedor no subsolo do cliente, o motorista na estrada. Para isso, parte dos dados fica no aparelho, e esse é o ponto em que segurança e operação mais se cruzam.

Os cuidados:

• Sincronize por escopo. O representante baixa a carteira dele, não a base inteira de clientes. O técnico baixa as ordens de serviço da semana, não o histórico de anos.
• Expire o que não é usado. Pedidos já enviados e documentos já sincronizados saem do aparelho depois de um prazo definido pela operação.
• Criptografe o banco local quando ele contém dado pessoal ou comercial sensível.
• Defina o que acontece com dados não enviados quando a sessão é revogada. Apagar tudo pode perder pedidos legítimos; manter tudo deixa dado exposto. A regra precisa ser decidida com a operação, não descoberta no incidente.
• Valide no servidor tudo o que chega da sincronização, inclusive preços e estoques que estavam desatualizados no aparelho.

O desenho de sincronização e conflitos de um app que trabalha sem conexão está em app de força de vendas offline.

Logs, notificações e outros vazamentos discretos

Alguns vazamentos não estão no banco nem na API:

• Logs e relatórios de erro que registram a requisição inteira, com token, CPF e dados do cliente, e enviam tudo para uma ferramenta de monitoramento acessada por muita gente.
• Notificações push com conteúdo sensível, que aparecem na tela bloqueada. "Novo pedido do cliente X no valor combinado" é informação comercial exposta para quem estiver ao lado. Prefira "Você tem um novo pedido para aprovar".
• Bibliotecas de terceiros de análise de uso e de anúncios que coletam mais do que o necessário. Cada biblioteca incluída no app é código que roda com as mesmas permissões dele.

A escolha da tecnologia muda pouco o essencial

App nativo e híbrido acessam o Keychain e o Keystore normalmente. O PWA, que roda no navegador, também usa HTTPS e autenticação segura, mas tem opções mais limitadas de armazenamento protegido no aparelho, o que pesa quando o app precisa guardar dados sensíveis para trabalhar offline. A escolha parte da operação, como mostra a comparação entre app nativo, híbrido ou PWA. Os erros desta lista aparecem nas três abordagens, porque são de desenho, não de tecnologia.

Testes de segurança antes de publicar

Segurança de app não é uma auditoria única antes do lançamento. É um checklist que roda a cada versão relevante. Como referência, existe o padrão OWASP MASVS, que organiza requisitos de segurança para aplicativos móveis; ele é um bom roteiro para conversar com fornecedores.

Um checklist prático para usar antes de publicar:

1. Inspecione o pacote final. Procure chaves, senhas, URLs de homologação e comentários que não deveriam estar lá.
2. Liste o que o app grava no aparelho e confirme que nada sensível está em texto puro.
3. Intercepte o tráfego em ambiente de teste e tente alterar preço, desconto, perfil e identificadores de outros clientes. O servidor precisa recusar.
4. Teste a revogação: desative o usuário no painel e confirme que o app perde acesso na próxima chamada.
5. Teste o aparelho perdido: sessão expirada, biometria, o que fica visível com o app em segundo plano.
6. Revise permissões solicitadas (câmera, localização, contatos) e remova as que não são usadas.
7. Verifique as bibliotecas do app quanto a versões com vulnerabilidades conhecidas.
8. Confira logs e relatórios de erro gerados durante os testes, procurando dado pessoal e token.
9. Garanta que a configuração de produção não carrega exceções de desenvolvimento, como aceitar qualquer certificado.

Para apps que lidam com dados financeiros, de saúde ou grandes volumes de dados pessoais, vale complementar com um teste de intrusão feito por especialista independente.

Perguntas frequentes

Ofuscar o código do aplicativo protege as chaves de API?

Não. A ofuscação só aumenta um pouco o trabalho de quem abre o pacote do aplicativo, e ferramentas gratuitas extraem chaves em minutos. A regra segura é o app não guardar nenhum segredo que dê acesso além do que o usuário logado já tem, usando credencial por usuário emitida pelo servidor.

Login por biometria é seguro em aplicativo corporativo?

Sim, quando a biometria serve para destravar e não para substituir a autenticação. A digital ou o reconhecimento facial liberam o uso do token já guardado na área segura do aparelho, mas quem decide se a sessão ainda vale é o servidor, que pode revogá-la quando o funcionário é desligado ou o celular se perde.

O que fazer quando um funcionário perde o celular com o app da empresa?

O gestor deve revogar as sessões daquele usuário ou daquele aparelho no painel do sistema, para que a próxima chamada do aplicativo seja recusada. A revogação só funciona se o app usar tokens de vida curta com revogação real. Em aparelhos corporativos, a gestão de dispositivos móveis (MDM) também ajuda a apagar dados remotamente.

PWA é menos seguro que aplicativo nativo?

Não necessariamente. O PWA usa HTTPS e autenticação segura como o app nativo e o híbrido, mas tem opções mais limitadas de armazenamento protegido no aparelho, o que pesa quando o aplicativo precisa guardar dados sensíveis para trabalhar offline. Os erros de segurança mais comuns aparecem nas três abordagens, porque são erros de desenho.

O que é o OWASP MASVS?

O OWASP MASVS é um padrão que organiza requisitos de segurança para aplicativos móveis, como armazenamento de dados, autenticação, comunicação de rede e resistência a engenharia reversa. Para uma empresa, o MASVS serve de roteiro para conversar com fornecedores e montar o checklist de segurança que roda antes de cada versão relevante do aplicativo.

Como a Pervian Tech trabalha apps seguros

Na Pervian Tech, segurança entra no desenvolvimento mobile desde o desenho, não como etapa final. Começamos mapeando quais dados o app realmente precisa ter no aparelho, quem acessa o quê e como a operação funciona sem sinal. A partir daí, definimos autenticação, sessão e revogação junto com a API, de forma que a regra de negócio fique no servidor e o app seja apenas a porta de entrada. O mesmo cuidado vale para aplicativos para empresas que já existem e precisam de revisão.

Cada projeto é sob medida, porque o risco de um app de vistoria é diferente do de um app de aprovação financeira. O investimento é sob consulta, depois de um diagnóstico inicial gratuito. Outros textos sobre o tema estão em segurança e LGPD. Se o aplicativo da sua empresa guarda mais do que deveria ou nunca pede login, conte como ele funciona hoje.