Auditoria de segurança de web app construído com IA: o que checar

Uma auditoria de segurança de web app para um app construído com IA é uma revisão estruturada de quem pode ler e alterar quais dados, onde ficam seus segredos, como os pagamentos são confirmados e se você consegue se recuperar de um dia ruim. Para a maioria dos apps feitos com Lovable, Bolt, Base44 ou Supabase, algumas checagens focadas encontram a maior parte do risco, e você não precisa de um projeto de meses para começar.

Sou um engenheiro brasileiro com sete anos de experiência em sistemas em produção, então posso ter um viés para o Brasil, mas o padrão que vejo é consistente: os problemas raramente são exóticos. Eles estão nas regras de dados, em chaves expostas no navegador e na lógica de pagamento. Este guia mostra como fazer essa revisão, o que exigir do resultado e quando fazê-la.

O que uma auditoria de segurança de web app cobre?

Uma auditoria bem feita olha para a aplicação que você construiu, não só para os servidores por baixo dela. Para um app construído com IA, eu agrupo em cinco áreas:

• Autenticação e sessões: cadastro, login, redefinição de senha e se apps privados são realmente privados.
• Autorização: o usuário A consegue ler ou editar os registros do usuário B trocando um ID?
• Segredos e chaves: o que vai para o navegador, o que fica no repositório, o que pode ser rotacionado.
• Pagamentos e lógica de negócio: como um pedido passa a constar como pago e o que acontece em novas tentativas ou duplicidades.
• Resiliência: backups, testes de restauração, logs e desempenho básico sob carga.

O modelo de responsabilidade compartilhada importa aqui. O construtor protege a própria infraestrutura e as contas. Você é responsável por quem pode ler quais dados e pelos dados dos seus usuários. Em julho de 2025, pesquisadores da Wiz descobriram que o Base44, da Wix, permitia que um atacante se cadastrasse em apps que deveriam ser privados usando apenas o ID do app. A falha foi corrigida em um dia. A plataforma corrigiu a parte dela, mas ninguém mais poderia verificar as regras do seu app por você.

Preciso de uma auditoria completa ou de algumas checagens focadas?

No começo, checagens focadas. A maior parte do risco é encontrada por algumas revisões direcionadas, não por uma auditoria completa, e o custo de corrigir cresce depois que chegam usuários reais e pagamentos. Esse é o argumento para fazer a versão menor cedo.

Quando checagens focadas bastam

• Você ainda não lançou, ou tem só alguns usuários de teste.
• Você armazena dados de conta comuns, não registros de saúde ou financeiros.
• Os pagamentos passam pelo Stripe Checkout, sem manipulação própria de cartões.

Quando ir mais fundo

• Você lida com dados pessoais sensíveis ou atua em uma área regulada. Converse com um advogado sobre suas obrigações; este artigo não é aconselhamento jurídico.
• Clientes enterprise pedem um questionário de segurança ou um relatório de terceiros.
• O app tem dados multi-tenant, papéis e painéis administrativos com regras complexas.

Uma auditoria completa também faz sentido depois das checagens focadas, quando os buracos óbvios já estiverem fechados. Pagar por uma revisão profunda de um app com tabelas de dados abertas desperdiça o orçamento em achados que você poderia ter visto em uma tarde.

O que os scanners automatizados deixam passar?

Scanners são úteis e baratos. Eles pegam bibliotecas desatualizadas, headers de segurança ausentes, portas abertas e alguns padrões de injeção. Rode um. Mas eles testam o que conseguem ver de fora e não entendem o que o seu app deveria fazer.

Eles deixam passar a lógica de negócio. Um scanner não vai saber que:

• Um handler de webhook do Stripe aceita qualquer POST sem verificar a assinatura, então qualquer pessoa pode marcar um pedido como pago.
• O mesmo evento chegando duas vezes cria dois pedidos ou concede créditos duas vezes.
• Um usuário pode alterar um preço ou uma quantidade na requisição e o servidor confia nisso.
• Um cupom de desconto pode ser reutilizado sem limite.
• Uma rota de admin está escondida na interface, mas não está protegida no servidor.

É também por isso que pedir ao construtor com IA para corrigir o que ele mesmo gerou não substitui a revisão. As regras de dados, as chaves e os fluxos de pagamento são exatamente o que essas ferramentas costumam errar, e o mesmo modelo que os escreveu pode não perceber os próprios erros. Uma pessoa independente lendo os fluxos, com o scanner como apoio, encontra mais.

Como reviso regras de acesso a dados e chaves?

Apps construídos com Lovable têm mostrado um padrão de regras fracas de row level security (RLS) no Supabase. Comece por aí.

Regras de acesso a dados

1. Liste todas as tabelas. Para cada uma, confirme que o RLS está habilitado.
2. Leia cada policy em linguagem simples. Uma policy que na prática diz “qualquer usuário autenticado pode ler todas as linhas” é um vazamento.
3. Teste com duas contas reais. Faça login como usuário A e tente buscar os registros do usuário B direto pela API, não pela interface.
4. Teste deslogado. Requisições anônimas não devem retornar nada privado.
5. Verifique se os buckets de storage seguem as mesmas regras das tabelas.
6. Verifique se as policies de escrita são tão rígidas quanto as de leitura, incluindo updates e deletes.

Chaves expostas

Algumas chaves foram feitas para ser públicas, como a anon key do Supabase, e só são seguras quando o RLS está correto. Outras nunca podem chegar ao navegador: service role keys, chaves secretas do Stripe, segredos de webhook e chaves de API de terceiros.

• Abra a aba de rede do navegador e veja o JavaScript gerado no build. Procure pelos nomes das suas chaves secretas.
• Pesquise no repositório do GitHub e no histórico dele, não só nos arquivos atuais.
• Mova os segredos para variáveis de ambiente no servidor ou para edge functions.
• Se um segredo já foi exposto alguma vez, rotacione. Apagar do código não desfaz o vazamento.

Como reviso pagamentos e lógica de negócio?

A regra é simples: o navegador nunca decide que alguém pagou. Só uma mensagem verificada do Stripe para o seu servidor decide.

1. Encontre a fonte da verdade. O app libera o acesso quando o usuário chega a uma página de sucesso ou quando um webhook confirma o pagamento? Deve ser o webhook.
2. Verifique assinaturas. O handler precisa checar a assinatura do Stripe usando o segredo do seu webhook e rejeitar todo o resto.
3. Torne os handlers idempotentes. Guarde o ID do evento e ignore repetições, para que novas tentativas não criem pedidos duplicados.
4. Trate os eventos ruins. Pagamentos recusados, reembolsos, disputas e assinaturas canceladas devem alterar o acesso, não ser ignorados.
5. Calcule os preços no servidor. Nunca aceite um valor vindo do cliente.
6. Teste no modo de teste do Stripe. Reenvie eventos, mande-os duas vezes, mande-os fora de ordem.

Além dos pagamentos, percorra as principais jornadas do usuário como um atacante faria: pule etapas, repita etapas, troque IDs, use o link de outra pessoa. Bugs de lógica de negócio moram nessas brechas.

Backups

A quarta checagem é chata e vital. Confirme que os backups automáticos estão ligados, saiba o período de retenção e faça uma restauração em um ambiente separado. Um backup que você nunca restaurou é uma esperança, não um backup.

O que o relatório de auditoria deve me entregar?

Um relatório útil é algo em que você consegue agir na mesma semana. Espere:

• Achados classificados por severidade, com uma explicação simples do que um atacante conseguiria fazer.
• Evidências: a tabela, a rota ou a requisição que mostra o problema, para que seu desenvolvedor consiga reproduzi-lo.
• Uma correção específica para cada item, não só “melhorar a segurança”.
• O que não foi verificado. Limites de escopo honestos importam mais do que uma nota com cara de limpa.
• Uma etapa de reteste depois das correções, para confirmar que funcionam.

Desconfie de relatórios que são basicamente saída de scanner colada em um PDF, ou que prometem que o app está “totalmente seguro”. Nenhuma auditoria pode prometer isso. Ela reduz o risco e mostra onde está o risco que sobrou.

Quando devo agendar a auditoria?

Antes de usuários reais e antes de pagamentos em produção. É o momento mais barato, porque há poucos dados a proteger, nada a migrar e nenhum cliente a notificar se algo der errado.

• Antes do lançamento: faça as quatro checagens.
• Antes de colocar o Stripe em modo live: verifique de novo o fluxo de pagamento de ponta a ponta.
• Depois de mudanças grandes: novos papéis, novas tabelas, uma nova integração, ou a saída do construtor para o GitHub e hospedagem própria.
• Periodicamente: as ferramentas de IA continuam mudando o código, então um novo prompt pode alterar uma regra de dados sem você perceber.

Continuar no construtor às vezes é a decisão certa. Se o app é simples, os dados são de baixo risco e os controles da plataforma atendem, talvez você só precise das checagens focadas, não de uma migração. Migrar para hospedagem própria é possível com código construído no Lovable, mas isso traz responsabilidades que passam a ser suas.

Quer uma segunda opinião?

Se você está prestes a lançar um app construído com IA, mande um email para me@filipeeduardo.dev descrevendo o seu setup, e eu digo com prazer o que eu checaria primeiro.