Segurança
Como saber se o app que você mandou construir é seguro: 10 perguntas pro seu dev ou agência
Equipe iatize · · 8 min de leitura
Procure segurança de aplicativo no Google e você vai achar mil artigos ensinando o consumidor a não baixar app falso. Agora procure como saber se o app que EU mandei construir é seguro. O silêncio é ensurdecedor. Quem paga pelo software é justamente quem não tem a quem perguntar.
Este artigo resolve isso. São 10 perguntas em português de gente normal, que você faz pro seu desenvolvedor, freelancer ou agência. Você não precisa entender a resposta tecnicamente — precisa saber se existe resposta, se ela é específica e se ela vem sem rodeio. É exatamente assim que se avalia qualquer fornecedor de qualquer área.
As 10 perguntas
1. Se dois clientes usarem o sistema, o que impede um de ver os dados do outro?
A mais importante da lista. É o furo mais comum e mais grave em produto feito às pressas. Resposta boa menciona regra de acesso no próprio banco de dados — não apenas escondemos o botão na tela. Se a proteção existe só na interface, qualquer pessoa com curiosidade mínima passa por cima dela.
2. As senhas dos usuários ficam guardadas de que forma?
A única resposta aceitável é que ninguém consegue ler as senhas — nem o próprio desenvolvedor. Se ele disser que consegue ver a senha de um usuário pra ajudar, isso é um problema sério, não um recurso.
3. As chaves de acesso dos serviços que usamos estão onde?
Chaves de pagamento, de IA, de envio de mensagem. Elas precisam estar no servidor, nunca no navegador. Chave exposta no navegador é visível pra qualquer um e vira conta de milhares de reais no seu cartão, cobrada pelo uso que um estranho fez.
4. O que acontece se alguém tentar mil senhas por minuto no login?
Deve existir bloqueio por tentativa. Sem isso, seu login é uma porta destrancada com uma placa dizendo tente à vontade.
5. Se eu apagar dados de um cliente que pediu, some mesmo de tudo?
A LGPD dá ao seu cliente o direito de sumir da sua base. Isso inclui backups e sistemas ligados. Se o fornecedor nunca pensou nisso, você tem uma obrigação legal sem implementação — e ela é sua, não dele.
6. Onde exatamente ficam os dados dos meus clientes?
Você precisa saber em qual serviço, em qual conta e em nome de quem. Aqui mora uma armadilha comum: quando a infraestrutura está na conta do fornecedor, você não é dono dos seus próprios dados. Se a relação azedar, seu negócio fica de refém.
7. Existe backup? De quando? Você já testou restaurar?
A pergunta que separa o profissional do resto é a última. Backup que nunca foi restaurado é uma suposição de backup. Muita gente descobre que o backup estava quebrado no exato dia em que precisou dele.
8. As informações trafegam protegidas? Tem HTTPS em tudo?
Item básico, mas ainda falha. Vale conferir se todas as páginas e todas as chamadas usam conexão segura, não apenas a tela de login.
9. Se um arquivo for enviado pelo usuário, o que é validado?
Se o seu sistema aceita upload — foto, documento, planilha — precisa haver limite de tipo e de tamanho, e o arquivo não pode ser servido de volta sem checagem. Upload sem controle é uma das portas de entrada preferidas de quem ataca.
10. Quem, além de você, tem acesso hoje? E quando alguém sai do projeto?
Muita gente descobre tarde que um freelancer que saiu há dois anos ainda tem acesso de administrador ao sistema. Deve existir uma lista de quem tem acesso e um processo pra remover quando a pessoa sai.
Sinais de alerta nas respostas
- Fica ofendido com a pergunta. Profissional sério gosta de cliente que pergunta — significa que ele vai poder cobrar pelo trabalho bem feito.
- Responde só isso é seguro, pode ficar tranquilo. Isso não é resposta, é um afago.
- Enche de sigla pra te calar. Quem domina explica simples; quem não domina se esconde atrás do jargão.
- Diz que segurança fica pra depois, quando tiver usuário. Metade dessa lista é dez vezes mais cara de fazer depois.
- Não sabe dizer onde os dados estão. Se ele não sabe, ninguém sabe.
- Pede reunião pra explicar por escrito o que caberia em duas linhas.
Quando é cedo demais pra se preocupar (a parte honesta)
Não vamos vender pânico. Existe momento em que boa parte disso é overkill, e insistir só queima dinheiro que você precisa pra vender:
- Protótipo pra mostrar pra sócio ou investidor, sem dado real de ninguém: relaxe. Não tem o que proteger.
- Ferramenta interna usada por três pessoas da sua equipe, sem dado sensível: o básico basta.
- Landing page que só coleta nome e e-mail: você precisa de HTTPS, política de privacidade e uma forma de excluir contato. Só.
- Auditoria externa e certificação: só faz sentido quando o cliente exige ou quando o volume justifica. Antes disso, é vaidade cara.
O que fazer se as respostas foram ruins
- Não entre em pânico e não acuse ninguém. Muita coisa dessa lista é falha de escopo, não de caráter — provavelmente nunca foi contratado.
- Peça por escrito o que existe e o que não existe. Você precisa de um mapa antes de decidir.
- Priorize por dano: acesso indevido a dados de cliente primeiro; o resto depois.
- Garanta o acesso: contas, repositório e infraestrutura no seu nome. Isso é o que te dá liberdade de trocar de fornecedor se precisar.
- Peça uma revisão de fora. Um segundo par de olhos custa pouco perto de um vazamento.
Se você quer uma leitura de fora sobre como seu site ou app está hoje, temos uma página dedicada a isso — e o diagnóstico gratuito também aponta o que priorizar no seu caso específico.
Fazer meu diagnóstico gratuito
Perguntas frequentes
Como saber se um aplicativo é seguro sendo que eu não sou técnico?
Você não precisa avaliar o código — precisa avaliar as respostas. Pergunte por escrito o que impede um usuário de ver os dados de outro, onde ficam as chaves de acesso, como as senhas são guardadas, se existe backup testado e onde os dados estão hospedados. Fornecedor que domina o assunto responde rápido, específico e em linguagem simples. Quem enrola, se esconde em jargão ou pede reunião pra explicar o que cabe em duas linhas.
Meu MVP já precisa se preocupar com segurança?
Depende do que ele guarda. Protótipo sem dado real de ninguém não precisa. Ferramenta interna com três pessoas precisa só do básico. Mas no momento em que o sistema guarda dado pessoal de terceiro — CPF, endereço, telefone, saúde ou financeiro — segurança deixa de ser zelo e vira obrigação legal, independentemente do tamanho do seu negócio.
Como saber se quem desenvolveu meu app fez de forma segura?
As perguntas mais reveladoras são: o que impede um cliente de ver os dados de outro (a resposta precisa citar regra no banco de dados, não só esconder o botão na tela), onde estão as chaves de API (têm que estar no servidor, nunca no navegador) e se o backup já foi testado com uma restauração real. Se ele se ofende com as perguntas ou responde apenas que está tudo seguro, isso já é a resposta.
Os dados dos meus clientes podem ficar na conta do meu fornecedor?
Podem, tecnicamente — mas é um risco de negócio sério. Se a infraestrutura está na conta dele, você não controla seus próprios dados e não consegue trocar de fornecedor sem depender da boa vontade dele. Exija que contas, repositório e infraestrutura estejam no seu nome, com você como proprietário e ele com acesso.
Quem responde legalmente se vazarem os dados dos meus clientes?
A sua empresa. A responsabilidade perante a LGPD e perante o titular dos dados é de quem coleta e trata a informação — não da ferramenta usada nem, na maioria dos casos, do desenvolvedor contratado. Por isso essas perguntas não são preciosismo técnico: são gestão de risco do seu próprio negócio.