Checklist de seguranca para app Android antes de publicar no Google Play

1. Dados sensiveis e papeis

Comece com uma lista simples. Quais dados o app coleta?

• email, telefone, nome e endereco;
• status de pagamento, historico de pedidos ou local de entrega;
• fotos, arquivos ou mensagens;
• dados de saude, bem-estar ou identidade;
• notas de suporte, acoes de administrador ou ganhos de provedores.

Depois defina quem pode ver ou alterar cada dado: usuario, provedor, suporte, admin, entregador, medico, professor, vendedor ou financeiro. Um erro comum e esconder um botao na app, mas permitir que a API entregue dados para a pessoa errada. As verificacoes no servidor importam mais do que esconder telas.

2. Remova segredos do pacote do app

Tudo que esta dentro de um app Android pode ser inspecionado. Nao coloque chaves privadas, tokens de administrador, segredos de pagamento, credenciais de banco de dados ou chaves de assinatura dentro do app.

Boas praticas:

• pagamentos e acoes privilegiadas passam pelo backend;
• tokens duram pouco quando possivel;
• chaves publicas de SDK sao tratadas como publicas;
• chaves expostas sao rotacionadas rapido;
• builds finais nao contem endpoints de teste nem flags de debug.

Esse e um dos controles com melhor retorno antes do lancamento.

3. Minimize permissoes

Usuarios notam permissoes, e o Google Play tambem acompanha permissoes sensiveis. Peça apenas o necessario, no momento em que faz sentido, com uma explicacao simples.

Revise:

• localizacao precisa ou aproximada, em primeiro plano ou em segundo plano;
• camera e acesso a midia;
• contatos e calendario;
• notificacoes;
• microfone e Bluetooth;
• permissoes especiais que exigem justificativa forte.

Se uma funcao do MVP pode funcionar sem permissao sensivel, evite. Permissoes em excesso reduzem confianca e podem complicar a revisao.

4. Proteja armazenamento local

Nao armazene dados sensiveis no aparelho sem necessidade. Se armazenamento local for necessario, use armazenamento seguro, evite tokens em texto simples e defina o que e apagado no logout.

Confira:

• tokens fora de arquivos simples;
• cache privado limitado;
• capturas e logs sem telas privadas;
• logout limpa estado sensivel;
• backups nao incluem dados indevidos.

Em saude, chat privado e pagamentos, essas regras precisam ser discutidas antes do desenvolvimento.

5. Rede e backend

O backend deve validar permissao em cada requisicao. O app Android nao deve ser o unico lugar das regras de negocio.

Revise:

• trafego de API por HTTPS;
• usuario acessa apenas seus dados;
• papeis de provedor e admin checados no servidor;
• limites para acoes de risco;
• uploads validados;
• status de pagamento confirmado no servidor;
• mensagens de erro sem detalhes privados.

Em marketplaces e delivery, preste atencao na propriedade do pedido, visibilidade do endereco e acoes do provedor.

6. Autenticacao e recuperacao

Autenticacao inclui cadastro, login, login social, recuperacao de senha, exclusao de conta, expiracao de sessao e recuperacao via suporte.

Um MVP simples pode usar um provedor confiavel. Apps com mais risco podem exigir regras mais fortes, verificacao de troca de aparelho, segundo fator ou confirmacao extra para acoes sensiveis.

Se houver chat privado, notas medicas, pagamentos ou acesso admin, recuperacao de conta nao deve ficar para depois.

7. SDKs, logs e analytics

SDKs de terceiros podem coletar dados, adicionar permissoes, afetar performance e mudar declaracoes de privacidade. Mantenha apenas o que e necessario.

Antes de publicar:

• remova SDKs nao usados;
• revise requisitos de privacidade;
• evite dados pessoais, tokens ou texto privado em eventos;
• confira crash logs;
• desligue logs detalhados em release.

Analytics deve ajudar o time sem capturar dados privados desnecessarios.

8. Play Integrity quando fizer sentido

A documentacao Android aponta ferramentas como Play Integrity API e Credential Manager. Nem todo MVP precisa da mesma configuracao, mas apps com pagamentos, risco de abuso, conteudo pago ou marketplace devem discutir isso.

Esses sinais nao substituem verificacoes no backend. Eles sao uma camada a mais.

9. Teste a build final

Builds de desenvolvimento podem esconder problemas. Teste a build assinada que sera enviada ao Google Play.

Percorra:

• primeira instalacao e primeiro login;
• recuperacao de senha ou login social;
• permissoes;
• compra, reserva ou pedido;
• logout e exclusao de conta;
• rede lenta ou offline;
• crash reporting e analytics;
• acoes de admin que afetam usuarios Android.

O Google vem adicionando mais alertas para desenvolvedores, mas e melhor corrigir antes do envio.

Custo e escopo

O esforco de seguranca depende dos dados e fluxos. Um MVP de conteudo e diferente de delivery, saude, chat privado ou marketplace com pagamentos.

Na Appfyl, um MVP focado costuma comecar em 15.000-20.000 EUR. Um produto medio fica muitas vezes em 20.000-50.000 EUR. Apps maiores com pagamentos, papeis, painel de administracao, dados sensiveis, monitoramento e testes profundos podem chegar a 50.000-100.000 EUR.

Seguranca e um motivo para estimar por fluxos e riscos, nao apenas por numero de telas. Voce pode descreve-los no brief de estimativa da Appfyl.

Como a Appfyl trabalha

Mantemos a primeira versao pratica. O objetivo nao e comprar todas as ferramentas, mas evitar erros caros depois do lancamento.

Revisamos:

• dados sensiveis e papeis;
• permissoes no backend;
• permissoes do app e armazenamento local;
• status de pagamento, reserva ou pedido;
• analytics e logs;
• comportamento da build final.

Para saude, pagamentos ou comunicacao privada, recomendamos revisao mais profunda antes do lancamento.

Veja como a Appfyl transforma escopo em produtos lançados. Ver cases da Appfyl.

Links uteis

• Android Developers: Design for safety
• Android Developers: security tips
• OWASP MASVS
• Android Developers Blog: vulnerability remediation
• PTKD mobile app security checklist

Perguntas frequentes