As 10 perguntas a fazer à tua app antes de pedires uma revisão

A tua app está em produção, tem utilizadores e ninguém sénior olhou para ela como um todo. Antes de pagares a alguém para a rever, há perguntas que consegues fazer tu, hoje, sem abrir código.

Não são um teste de segurança. São uma forma de perceberes onde estás e o que dizer a quem for olhar para a app. Estão por ordem: acessos, dados, código e continuidade.

Acessos

1. Quem tem acesso de administrador ao código, à base de dados e ao alojamento, e todos têm autenticação de dois fatores? Inclui quem já saiu. O freelancer que construiu a primeira versão ainda tem a chave? Uma conta de administrador sem 2FA é a porta mais barata de abrir.

2. Onde estão as passwords e as chaves de API, e alguma já foi parar ao repositório, a um email ou a um chat? Uma chave que esteve uma vez no histórico do git continua lá, mesmo depois de apagada do ficheiro. Se esteve, trata-a como comprometida e troca-a.

Dados

3. Se criares duas contas de teste, uma consegue ver os dados da outra? É o teste mais simples e o mais revelador. Em apps com várias empresas ou vários clientes, é onde costuma estar o pior problema.

4. Há alguma chave ou ficheiro no browser, na app móvel ou num bucket público que ignora as regras de acesso aos dados? Em serviços como o Supabase, a chave pública vai para o browser de propósito, e a única coisa entre ela e os teus dados são as regras de acesso. Uma chave de serviço no sítio errado deita isso abaixo.

5. Sabes onde ficam os dados pessoais e quem os pode ver? Se não sabes dizer em duas frases, ainda não tens um mapa dos teus dados, e o RGPD pede-te um.

Código

6. As rotas que mexem em dinheiro, permissões ou dados de outras pessoas verificam quem está a pedir? Não basta estar autenticado. Pergunta-se: este utilizador pode fazer isto a este registo? É assim que um utilizador acaba a promover-se a administrador mudando um campo no pedido.

7. O que acontece quando alguém envia dados que não esperavas? Texto onde devia estar um número, um ficheiro enorme, um campo a mais. A app valida no servidor ou só no formulário?

8. Quando foi a última vez que as dependências foram atualizadas, e alguém olha para os avisos? Correr npm audit (ou o equivalente da tua stack) demora um minuto. Os avisos nem sempre são urgentes, mas convém saber quais são.

Continuidade

9. Se tudo desaparecer hoje, em quanto tempo voltas e quantas horas de dados perdes? Já restauraste um backup, ou só sabes que ele existe? Um backup que nunca foi restaurado é uma esperança, não um backup.

10. Se amanhã descobrires que houve um incidente, quem faz o quê e quem tens de avisar? Com dados pessoais, o RGPD pede, em regra, notificação à CNPD até 72 horas depois de teres conhecimento (salvo se for improvável que haja risco para as pessoas). Ter isto pensado antes poupa-te horas no pior dia.

Como ler as respostas

Uma regra prática, minha e sem ciência por trás: se respondes "não sei" a mais de três, vale a pena pedir olhos de fora. Se respondes "sim" a tudo sem teres verificado, pede também, porque é isso que costuma estar errado.

O que esta lista não é

Não substitui uma revisão do código e da base de dados, nem um teste de intrusão, nem um parecer jurídico sobre RGPD. Serve para saberes onde estás e para chegares a essa conversa com perguntas melhores. Se a tua app foi feita com ferramentas como Lovable, Bolt ou Cursor, vê também o que costumamos ver nas revisões de apps feitas com IA.

---

Se queres que olhemos para estas dez perguntas contigo, em 3 sessões curtas e por ordem de risco, vê como funciona a nossa revisão de segurança.