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

> Segurança em aplicativos móveis: dados expostos no aparelho, chaves no código, API que confia no app e sessões eternas. Os 8 erros comuns e como evitar.

Fonte: https://pervian.tech/blog/seguranca-em-aplicativos-moveis · Pervian Tech · publicado em 2026-10-01

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:

| Erro comum | O que pode acontecer | Como evitar |
|---|---|---|
| Dado sensível salvo em texto puro no aparelho | Quem pega o celular ou um backup lê os dados | Guardar o mínimo, em área protegida pelo sistema (Keychain no iOS, Keystore no Android) |
| Chave de API ou senha dentro do código do app | Qualquer pessoa extrai a chave e chama a API direto | Nenhum segredo no app; credencial por usuário, emitida pelo servidor |
| API que confia no que o app envia | Usuário altera preço, desconto ou perfil numa requisição | Toda regra e permissão validada no servidor |
| Sessão que nunca expira | Aparelho perdido ou funcionário desligado mantém acesso | Token de vida curta, renovação controlada e revogação real |
| Comunicação sem validação adequada | Tráfego interceptado em rede pública | HTTPS obrigatório, sem exceções de desenvolvimento esquecidas |
| Cache offline sem prazo nem limite | O aparelho acumula meses de dados de clientes | Sincronizar só o necessário e expirar o que não é usado |
| Logs com dado pessoal ou token | Informação vaza por relatórios de erro e ferramentas de suporte | Mascarar dados e nunca registrar credenciais |
| Publicar sem teste de segurança | O erro é descoberto por terceiros, não pela equipe | Checklist e revisão antes de cada versão relevante |

## 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](https://pervian.tech/blog/firebase-ou-back-end-proprio).

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](https://pervian.tech/blog/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](https://pervian.tech/blog/seguranca-de-apis-erros-comuns).

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](https://pervian.tech/blog/app-de-forca-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](https://pervian.tech/blog/notificacoes-push-boas-praticas) 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](https://pervian.tech/blog/app-nativo-hibrido-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](https://pervian.tech/blog/pentest-quando-contratar) 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](https://pervian.tech/servicos/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](https://pervian.tech/solucoes/desenvolvimento-de-aplicativos-para-empresas) que já existem e precisam de revisão.

Cada projeto é sob medida, porque o risco de um [app de vistoria](https://pervian.tech/blog/app-de-vistoria-de-imoveis) é 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](https://pervian.tech/blog/categoria/seguranca-e-lgpd). Se o aplicativo da sua empresa guarda mais do que deveria ou nunca pede login, [conte como ele funciona hoje](https://pervian.tech/#contato).