Segurança de aplicativo, para quem já tem usuário no ar, é a lista curta de coisas que precisam estar certas antes de o app crescer: quem acessa o quê, como o login funciona, onde ficam as chaves, quais bibliotecas entram no código, o que fica registrado, se existe backup que volta e se os dados pessoais estão tratados como a LGPD pede. A resposta rápida é esta: se algum desses sete pontos está em aberto, crescer multiplica o problema junto com a base de usuários.
Este texto é para quem construiu o produto rápido, muitas vezes com ferramentas de IA, e agora tem gente pagando ou dado de terceiro guardado no banco. O que segue é o roteiro que a gente usa para olhar um app nessa fase.
Por que o risco cresce junto com o app
No protótipo, uma falha de acesso expõe dado de teste. Com mil usuários, expõe mil cadastros reais, com nome, e-mail, telefone e às vezes documento. O código pode ser exatamente o mesmo. O que mudou foi o tamanho do estrago.
Existe também um efeito de atenção. App pequeno passa despercebido. App que aparece em anúncio, ganha imprensa ou entra em processo de venda passa a ser olhado por mais gente, e parte dessa gente procura exatamente o que ficou aberto.
Por isso a hora certa de revisar é antes do empurrão de crescimento. Depois dele, cada correção precisa ser feita com o sistema cheio de gente usando.
A referência: o OWASP Top 10
A OWASP Foundation, organização sem fins lucrativos dedicada a segurança de software, mantém o OWASP Top 10, a lista das categorias de risco mais comuns em aplicações web. A edição de 2025 traz, em primeiro lugar, o controle de acesso quebrado. Logo depois vêm configuração de segurança errada e falhas na cadeia de fornecimento de software, que é o nome técnico para o risco das bibliotecas e pacotes que o seu código importa.
A lista serve como mapa mínimo. Ela não substitui olhar o seu app em particular, mas ajuda a não esquecer as categorias onde a maior parte dos incidentes acontece. Os sete pontos abaixo seguem essa lógica, traduzida para o que costuma aparecer num produto recém-lançado.
Os sete pontos para checar antes de escalar
1. Autorização: quem pode ver e mexer em quê
É o ponto que mais falha, e o mais fácil de testar. Entre com um usuário comum, abra um pedido, uma fatura ou um perfil e troque o número que aparece na URL ou na requisição. Se o sistema mostrar o registro de outra pessoa, o controle de acesso está quebrado.
Em apps que usam Supabase, a proteção costuma depender da Row Level Security ativa e com política escrita em cada tabela. No Firebase, das regras de segurança do Firestore e do Storage. Tabela sem política ou regra liberada para qualquer leitura deixa o banco aberto para quem descobrir o endereço, mesmo que a tela do app pareça fechada.
2. Autenticação: como a pessoa prova quem é
Aqui entram senha, login social, recuperação de conta e sessão. Perguntas que valem a checagem: existe limite de tentativas de login? O link de recuperação de senha expira? A sessão cai depois de um tempo sem uso? Usuário com papel de administrador tem segundo fator de autenticação?
Sempre que possível, use um provedor de autenticação conhecido em vez de uma rotina escrita do zero. Menos código próprio nessa área significa menos lugar para errar.
3. Segredos: onde ficam as chaves
Chave de API, senha de banco e token de serviço precisam morar no servidor. O erro clássico em app construído rápido é a chave ir parar no código que roda no navegador. Em projetos com Next.js, toda variável com prefixo NEXT_PUBLIC_ é enviada ao navegador. Em projetos com Vite, o mesmo vale para o prefixo VITE_.
Qualquer pessoa consegue abrir as ferramentas de desenvolvedor e ler o que chegou ali. Se a chave de serviço do banco ou do provedor de pagamento estiver nesse pacote, ela é pública. Vale também procurar chaves no histórico do repositório, porque apagar o arquivo não apaga o commit antigo. Chave que já vazou precisa ser trocada, e esconder não basta.
4. Dependências: o que o seu código importa
Um app moderno carrega centenas de pacotes de terceiros. Cada um pode ter vulnerabilidade conhecida ou, no pior caso, ter sido adulterado. Ferramentas como npm audit e o Dependabot do GitHub listam pacotes com falha publicada e sugerem a versão corrigida.
Ferramenta de IA às vezes sugere pacote com nome parecido com um pacote real, ou uma biblioteca abandonada há anos. Antes de aceitar, confira se o pacote existe, se tem manutenção recente e se é o que você pensa que é.
5. Logs e alerta: o que fica registrado
Se alguém entrar onde não devia, você fica sabendo? Login com falha em sequência, acesso administrativo, alteração de permissão e exportação de dados precisam deixar rastro, com data, usuário e origem. E alguém precisa receber um aviso quando algo fora do normal acontece.
O cuidado oposto também conta: log não pode guardar senha, token ou dado pessoal completo. Log vazado com esse conteúdo vira um segundo incidente.
6. Backup: o dado volta se precisar?
Backup que nunca foi restaurado é uma aposta. Confira com que frequência ele roda, onde fica guardado, por quanto tempo e, principalmente, se alguém já fez o teste de restaurar para um ambiente separado e medir quanto tempo levou.
Guarde ao menos uma cópia fora da conta principal. Se a conta for comprometida, o backup que mora nela vai junto.
7. LGPD: o dado pessoal está tratado como a lei pede
A Lei Geral de Proteção de Dados (Lei 13.709/2018) vale para qualquer empresa que trate dado pessoal, sem piso de porte. O artigo 46 pede medidas de segurança técnicas e administrativas para proteger esses dados. A Resolução CD/ANPD nº 15/2024 regulamenta a comunicação de incidente de segurança que possa causar risco ou dano relevante aos titulares, com prazo de três dias úteis para avisar a ANPD e as pessoas afetadas.
Na prática: saiba quais dados pessoais o app coleta e por quê, colete só o necessário, tenha política de privacidade que descreva o que acontece de verdade e deixe escrito, antes de precisar, quem decide e quem comunica se um incidente acontecer.
Onde apps feitos com IA costumam escorregar
Ferramentas como Lovable, Bolt, Cursor, Claude Code e Replit entregam um produto funcionando em tempo recorde. Elas fazem o que o pedido descreve, e o pedido raramente descreve regra de acesso, rotação de chave ou teste de restauração. O resultado é um padrão bem reconhecível, que a gente detalha no texto sobre levar um app feito com IA para produção.
| Ponto | Como costuma aparecer | Como checar |
|---|---|---|
| Autorização | Tabela sem política de acesso, filtro só na tela | Trocar o ID na requisição com outro usuário |
| Autenticação | Sem limite de tentativas, sessão que nunca expira | Errar a senha várias vezes e ver o que acontece |
| Segredos | Chave de serviço em variável pública | Procurar chaves no código enviado ao navegador |
| Dependências | Pacote desatualizado ou inexistente sugerido | Rodar npm audit e revisar a lista de pacotes |
| Logs | Nenhum registro de acesso administrativo | Perguntar quem seria avisado de um acesso estranho |
| Backup | Backup automático nunca restaurado | Restaurar em ambiente separado e cronometrar |
| LGPD | Coleta de dado sem finalidade clara | Listar cada campo pessoal e o motivo de existir |
Checklist rápido antes de escalar
Se só der tempo de fazer uma rodada, estas perguntas pegam a maior parte dos problemas:
- Um usuário consegue ver ou alterar dado de outro trocando um identificador?
- Todas as tabelas do banco têm regra de acesso escrita e ativa?
- Alguma chave secreta aparece no código que vai para o navegador ou no histórico do repositório?
- Existe limite de tentativas no login e segundo fator para administradores?
- As dependências passaram por npm audit ou ferramenta equivalente no último mês?
- Acesso administrativo e exportação de dados ficam registrados, e alguém recebe alerta?
- O backup foi restaurado com sucesso pelo menos uma vez?
- Existe um documento curto dizendo o que fazer, e em quanto tempo, se houver vazamento?
Resposta "não sei" conta como "não". Quase sempre ela aponta para o ponto que ninguém olhou.
Erros comuns na hora de corrigir
Corrigir só a tela. Esconder o botão para o usuário comum não protege nada se a API continua aceitando a chamada. A regra precisa estar no servidor ou no banco.
Trocar a chave e esquecer o histórico. Se a chave antiga continua válida no provedor, ela continua sendo um risco, mesmo fora do código atual.
Tratar segurança como tarefa única. Cada funcionalidade nova pode abrir uma porta. A revisão precisa voltar a cada mudança grande, com um checklist que o time consiga repetir sozinho.
Pedir para a mesma ferramenta revisar o que ela escreveu. Ajuda a achar erro de sintaxe e esquecimento óbvio. Para regra de negócio e desenho de acesso, o que funciona é alguém de fora lendo o código com método e testando o fluxo como um usuário mal-intencionado testaria.
O que muda quando o app passa na revisão
Um app revisado cresce com menos surpresa. O custo de infraestrutura fica previsível, a conversa com investidor ou comprador fica mais fácil quando alguém abre o repositório e o risco de ter que parar tudo para apagar incêndio cai muito.
Se a correção for feita por um time de fora, vale o mesmo cuidado de qualquer contratação técnica, e o nosso guia sobre como escolher uma software house ajuda a separar quem entende o problema de quem só executa o pedido. O que importa no fim é ter cada um dos sete pontos com uma resposta clara e documentada, que continue valendo quando o time mudar.
