Checklist de segurança para app feito com IA: 12 itens antes de lançar

Este checklist de segurança para app feito com IA reúne 12 itens para conferir antes de abrir o app a clientes reais: banco de dados, chaves, login, pagamentos, arquivos e dados pessoais. Os quatro primeiros concentram os vazamentos mais comuns e dá para conferir em uma tarde.

Ferramentas como Lovable, Bolt, Cursor e v0 colocaram no ar, em dias, apps que antes levariam meses. Isso é ótimo. O ponto de atenção é que a IA é muito boa em fazer o app funcionar e nem sempre tão boa em fazê-lo seguro.

Não é impressão. No relatório 2025 GenAI Code Security Report, a Veracode testou mais de cem modelos de IA em 80 tarefas de programação e encontrou vulnerabilidades da lista OWASP Top 10 em 45% dos casos (Veracode).

A boa notícia: a maior parte dos problemas se repete e dá para conferir. Use a lista abaixo antes de abrir o app para clientes reais.

Dados e banco

1. Toda tabela com dados de usuário tem RLS ativo

Se o app usa Supabase, cada tabela precisa ter o RLS (Row Level Security) ligado. Sem ele, quem tiver a chave pública do app, que fica no navegador de propósito, pode ler a tabela. O Security Advisor, no painel do Supabase, aponta tabelas sem RLS (documentação). O passo a passo está em RLS no Supabase: como conferir o seu app. No Firebase, o equivalente são as regras de segurança do Firestore e do Storage.

2. Nenhuma policy libera tudo

RLS ligado não basta. Uma policy com using (true) deixa a tabela aberta do mesmo jeito. Confira se cada regra limita o acesso ao dono do dado (por exemplo, auth.uid() = user_id).

3. Um usuário não vê os dados de outro

Crie dois usuários de teste no seu próprio app e confira: o usuário A consegue abrir um pedido, perfil ou arquivo do usuário B trocando o ID na URL? Se sim, há uma falha de autorização. O Supabase permite simular um usuário no painel para checar isso (User Impersonation).

Chaves e segredos

4. Nenhuma chave secreta no navegador

Chaves como a service_role (ou sb_secret_) do Supabase, a da OpenAI e a secret key do Stripe só podem existir no servidor. Abra o DevTools do navegador no seu app e busque por sk-, sk_live, service_role e secret nos arquivos carregados. Veja como achar e corrigir chaves de API expostas no navegador.

5. O .env não está no repositório

Confira se o arquivo .env está no .gitignore e se não foi enviado ao GitHub em algum commit antigo. Se uma chave já vazou, rotacione: gere uma nova e desative a antiga.

Login e permissões

6. Toda rota privada exige login no servidor

Esconder um botão na tela não protege nada. Se a página ou a API de admin responde para quem não está logado, ela está aberta. A checagem de permissão precisa acontecer no servidor ou no banco, não só na interface.

7. O usuário não consegue se promover a admin

Se o papel do usuário (cliente, admin) fica num campo que ele mesmo consegue editar, como o user_metadata do Supabase, alguém pode se dar permissões de administrador. Papéis devem ficar num lugar que só o servidor altera.

Pagamentos e integrações

8. A confirmação de pagamento vem do provedor, não da tela

O app só deve liberar acesso pago depois de confirmar o pagamento direto com o provedor (Stripe, Mercado Pago), via webhook ou consulta no servidor. Uma tela de "pagamento aprovado" que libera o acesso sozinha pode ser forjada.

9. Webhooks conferem a assinatura

Todo provedor sério assina as notificações que envia. O seu endpoint de webhook deve validar essa assinatura e ignorar avisos repetidos, para não liberar o mesmo pedido duas vezes.

Arquivos e infraestrutura

10. Uploads não ficam públicos por engano

Documentos, comprovantes e fotos de clientes não devem estar num bucket público. Confira as regras do storage e limite tipo e tamanho dos arquivos aceitos.

11. Dependências atualizadas e erros discretos

Rode a auditoria do gerenciador de pacotes (por exemplo, npm audit) e atualize bibliotecas com falhas conhecidas. Confira também se as mensagens de erro mostradas ao usuário não revelam detalhes internos, como consultas SQL ou caminhos de arquivos.

Dados pessoais

12. Você sabe quais dados guarda e por quê

A LGPD exige que quem trata dados pessoais adote medidas de segurança para protegê-los de acessos não autorizados (art. 46). E quem responde é a empresa dona do app, não a ferramenta que gerou o código. Na prática: liste quais dados você coleta, apague o que não precisa e tenha uma política de privacidade publicada.

Como usar este checklist de segurança para app

Não precisa resolver tudo num dia. Comece pelos itens 1 a 4, que concentram os vazamentos mais comuns em apps feitos com IA, e avance a partir deles. Ao pedir correções para a ferramenta de IA, descreva a regra de negócio ("cada cliente só vê os próprios pedidos") em vez de "faça funcionar". Essa segunda frase costuma resolver o erro desligando a proteção.

E lembre-se: teste apenas o seu próprio app. Invadir sistema de terceiros sem autorização é crime no Brasil (Lei 12.737/2012).

Quer que alguém confira por você?

Se você prefere chegar ao lançamento com essa lista verificada por quem faz isso todo dia, a Prisma Digital oferece o diagnóstico de segurança para apps feitos com IA. Revisamos o código e a configuração do seu app com autorização por escrito e entregamos um relatório com os riscos em ordem de prioridade e o passo a passo da correção.