Guia · Apps feitos com IA

Vibe coding e segurança: o que conferir antes de publicar seu app

A IA escreve o app para funcionar, e ele funciona — para você, logado como dono. O que ela costuma deixar para trás é o que só aparece para quem está do lado de fora: regras de acesso, chaves no código, arquivos públicos. Esta é a lista do que conferir antes de mandar o link para os primeiros clientes.

Atualizado em 29/09/2026 · leitura de 8 min · por Warden

Por que a IA deixa essas portas

Três razões — e nenhuma é descuido seu:

1. A IA persegue “funcionar”. Uma tabela sem regra de acesso funciona perfeitamente. Nada quebra, nenhum erro aparece.
2. Você testa logado, como dono. E o dono vê tudo de qualquer jeito — então o teste nunca mostra o que um estranho veria.
3. Cada prompt novo pode desfazer o anterior. Uma alteração pedida para outra coisa pode reescrever uma regra que estava certa.

O resultado é o mesmo em Lovable, Bolt, v0, Cursor ou Replit: o que fica exposto só aparece para quem olha de fora, sem login.

A lista: 10 verificações antes de publicar

1. Regras de acesso do banco de dados

No Supabase, o Row Level Security; no Firebase, as regras do Firestore e do Storage. Sem elas, a chave pública do site basta para ler as tabelas. Passo a passo em Supabase RLS: como saber se o seu banco está aberto.

2. Chaves secretas fora do navegador

Chave de IA, de pagamento ou de e-mail nunca vai no front-end. Se foi, troque antes de corrigir o código — veja chave de API exposta.

3. Permissão checada no servidor, não na tela

Esconder um botão não impede ninguém de chamar a mesma operação direto na API. Quem pode fazer o quê precisa estar na regra do banco ou no servidor.

4. Páginas e rotas de administrador

Endereços como /admin ou /api/admin precisam exigir login — e login de administrador, não de qualquer usuário.

5. Arquivos que não deveriam ser públicos

.env, a pasta .git, backups e chaves de conta de serviço às vezes são publicados junto com o site. Qualquer pessoa que digitar o endereço baixa.

6. Cabeçalhos de segurança

HTTPS obrigatório (HSTS), proteção contra o seu site ser embutido em outro para enganar o usuário (frame-ancestors) e uma política de conteúdo (CSP) que limite de onde vêm os scripts.

7. CORS

É quem pode ler as respostas da sua API a partir de outro site. Access-Control-Allow-Origin: * numa API com dado de usuário deixa qualquer site ler essas respostas.

8. E-mail do seu domínio

SPF, DKIM e DMARC são registros de DNS que dizem quem pode mandar e-mail em nome do seu domínio. Sem eles, alguém pode mandar mensagens que parecem vir da sua empresa — para os seus próprios clientes.

9. Limite de tentativas

Login, cadastro e formulários públicos sem limite de tentativas deixam robôs testarem senhas e encherem o seu banco. Este item só se vê por dentro, no código ou no painel do provedor.

10. Mensagens de erro

Erro que mostra ao visitante a consulta SQL, o caminho de um arquivo ou uma chave entrega o mapa do seu sistema. O visitante vê uma mensagem simples; o detalhe fica no seu log.

Faça uma revisão de segurança deste app antes da publicação:

1. Banco: RLS ligado em todas as tabelas, com políticas por usuário
   (user_id = auth.uid()); nenhuma regra "using (true)" em dado de usuário.
2. Chaves: nenhuma chave secreta no front-end nem com prefixo VITE_ ou
   NEXT_PUBLIC_; chamadas a serviços pagos passam por função no servidor.
3. Permissões: toda operação de administrador é checada no servidor ou na
   regra do banco, não só escondida na tela.
4. Rotas: nenhuma página ou API de administração acessível sem login.
5. Erros: mensagens para o usuário não mostram SQL, caminhos ou chaves.
6. Limite de tentativas em login, cadastro e formulários públicos.

Liste o que encontrou, o que alterou e o que precisa de decisão minha.

Depois de publicar

Os itens 1, 2, 5, 6, 7 e 8 dá para conferir de fora, na versão publicada, sem acesso ao código. Uma análise passiva faz isso em segundos. Repita depois de cada mudança grande: é quando uma regra que estava certa costuma ser desfeita.