Checklist de Segurança para Apps Criados com IA
Um checklist de produção para founders e builders usando Cursor, Lovable, Replit, Bolt, v0, Claude Code e ferramentas parecidas.
nota runtime
Pense em uma clínica antes de atender pacientes: a recepção pode estar bonita, mas prontuários, remédios e áreas internas precisam ter acesso restrito a quem realmente pode mexer neles.
Checklist rápido
- 01Mantenha secrets de produção fora de qualquer coisa que o navegador do visitante consiga baixar.
- 02Confirme que o login protege páginas privadas, não só os links do menu.
- 03Teste se um usuário consegue abrir dados privados de outro usuário.
- 04Restrinja o acesso a uploads, buckets de storage e arquivos gerados.
- 05Valide assinatura de webhooks de Stripe, Supabase, Resend e serviços parecidos.
- 06Escaneie bundles e source maps em busca de chaves, tokens, URLs internas e logs de debug.
- 07Monitore as tecnologias que seu app usa, porque novas falhas públicas podem ser descobertas depois do lançamento.
- 08Tenha plano de rollback antes de mexer em auth, pagamentos ou acesso a dados.
Por que um app que funciona ainda pode estar inseguro
Ferramentas de programação com IA fazem o app parecer pronto muito rápido. O formulário envia, o dashboard abre, o checkout aparece, e fica fácil achar que o produto já pode receber pessoas reais.
Segurança é a parte que o usuário não vê. É como definir quem pode acessar prontuários, remédios, salas internas e arquivos privados atrás da recepção. Este checklist ajuda uma pessoa não técnica a fazer as perguntas certas antes de colocar usuários, pagamentos, dados de clientes, prontuários ou informações internas no sistema.
Secrets são chaves mestras, não configurações comuns
Um secret é uma chave que permite o sistema falar com banco, pagamento, email ou storage. Se essa chave aparece no navegador, é como deixar uma chave mestra em cima do balcão.
Os nomes técnicos são environment variables, browser bundles, source maps, service-role keys, API tokens e client-side config. Você não precisa dominar esses termos, mas alguém precisa provar que chaves privilegiadas não estão visíveis para visitantes.
- ▸Mova chaves privilegiadas para variáveis de ambiente server-only.
- ▸Rotacione qualquer chave que já foi commitada, impressa em log ou enviada para o navegador.
- ▸Desative source maps públicos se você não tiver uma razão clara para expô-los.
Tela de login não é a mesma coisa que segurança
A tela de login é só a porta de entrada. A pergunta real é se cada sala privada depois dessa porta confere quem está entrando.
Em termos técnicos, toda rota, server action, endpoint, tela de dashboard e download privado precisa de autorização. O teste simples é entrar como Usuário A, copiar uma URL ou ID privado e tentar acessar como Usuário B. Se o Usuário B vê ou altera dados do Usuário A, existe uma falha real.
- ▸Teste URLs diretas, não só links visíveis no menu.
- ▸Teste leitura e escrita separadamente.
- ▸Bloqueie endpoints privados antes de consultar registros sensíveis.
Seu banco precisa de regras, não só de tabelas
No desenvolvimento, o objetivo costuma ser fazer funcionar. Em produção, o objetivo muda: cada leitura e escrita precisa provar quem é o usuário e quais registros ele pode tocar.
É aqui que aparecem termos como RLS, row-level security, Firebase rules, permissões do Appwrite, functions do Convex e checks server-side. São nomes diferentes para a mesma ideia simples: um usuário não pode abrir o armário de outro usuário.
- ▸Ative autorização por linha ou documento quando a plataforma permitir.
- ▸Use menor privilégio possível para service roles e funções backend.
- ▸Teste com múltiplas contas reais antes do lançamento.
Pagamento não é só um botão de checkout
Um botão de checkout pode parecer perfeito enquanto a lógica por trás está frágil. O ponto perigoso não é só cobrar o cartão; é decidir quem ganha acesso depois do pagamento.
O servidor deve confiar no Stripe ou no provedor de pagamento por webhooks assinados, não em valores enviados pelo navegador. Um usuário nunca deve liberar recurso pago mudando uma URL, repetindo callback antigo ou alterando estado no frontend.
- ▸Valide assinatura dos webhooks.
- ▸Armazene estado de pagamento no servidor.
- ▸Teste pagamentos falhos, assinaturas canceladas, eventos duplicados e sessões expiradas.
Um app seguro hoje pode ficar arriscado depois
Uma revisão única é só uma foto. Ela diz que o app parecia aceitável naquele momento. Não significa que ele vai continuar seguro na semana seguinte.
O risco muda de duas formas. Você pode alterar o app, ou o mundo ao redor dele pode mudar: pesquisadores podem descobrir uma nova falha pública em um pacote, framework, banco ou ferramenta que seu app já usa. Monitoramento contínuo é como o dono descobre quando algo importante mudou.
- ▸Rode scans externos recorrentes.
- ▸Cruze novas vulnerabilidades divulgadas publicamente com as tecnologias detectadas em produção.
- ▸Envie alertas claros para o dono quando uma correção precisa de ação.
FAQ
Um app criado com IA é menos seguro que um app tradicional?
Não necessariamente. O risco é a velocidade: o app pode chegar a usuários reais antes de alguém revisar secrets, login, banco, pagamentos e monitoramento com cuidado.
Consigo usar este checklist sem ser técnico?
Sim. Você não precisa entender todos os termos técnicos. Precisa saber o que pedir para sua IA, desenvolvedor ou plataforma verificar.
Preciso de monitoramento contínuo se o primeiro scan estiver bom?
Sim. Um scan bom é como um exame bom hoje. Amanhã, seu app pode mudar, ou uma nova falha pública pode ser descoberta em algo que ele já usa.