Seu app feito com IA está seguro? As 8 falhas que mais aparecem

Lovable, Bolt, Cursor, v0: a IA entrega um app que funciona, mas nem sempre seguro. As 8 falhas mais comuns e como conferir cada uma antes de publicar.

A IA é ótima em fazer o app funcionar. O problema é que "funcionar" e "estar seguro" são coisas diferentes: quando aparece um erro de permissão, o caminho mais curto para a IA é liberar a permissão — e o app volta a funcionar, aberto para qualquer um.

Depois de analisar centenas de projetos feitos com IA, as mesmas oito falhas aparecem de novo e de novo. Nenhuma delas é exótica. Todas deixam alguém de fora ler, alterar ou gastar o que é seu.

1. Chave secreta no navegador

Tudo o que vai para o navegador pode ser lido por quem visita o site. Chave da OpenAI, do Stripe ou a service_role do Supabase no código do front é chave pública — e alguém vai usá-la por você.

2. Arquivo .env enviado para o GitHub

O .env guarda as senhas do projeto. Se ele foi versionado, está no histórico do repositório, e robôs vasculham o GitHub atrás disso o dia inteiro.

3. Tabela do Supabase sem RLS

A chave pública do Supabase vai no site de propósito. O que protege os dados é a RLS (Row Level Security). Tabela sem RLS, ou com uma política using (true), pode ser lida e alterada por qualquer visitante.

4. Rota de API que não pede login

A rota que grava no banco, apaga arquivo ou chama uma API paga precisa conferir quem está chamando. Sem isso, qualquer um que descubra o endereço faz o mesmo — e a conta da IA chega para você.

5. Trocar o id na URL mostra dados de outra pessoa (IDOR)

A rota confere o login, mas não confere se o pedido é DAQUELE usuário. Basta trocar /pedidos/123 por /pedidos/124 para ver o pedido de outra pessoa.

6. SQL montado com o que o visitante digita

Concatenar texto do usuário numa consulta SQL ainda é uma das formas mais comuns de vazar o banco inteiro. A correção é antiga e simples: parâmetros.

7. CORS liberado para qualquer site, com cookie

"Liberar geral" o CORS para sumir com um erro, junto com credenciais, deixa qualquer site na internet fazer pedidos em nome de quem está logado no seu.

8. Cookie de sessão sem proteção

Cookie de sessão sem HttpOnly pode ser lido por um script malicioso; sem Secure, viaja sem criptografia. É a chave da conta do usuário.

Como conferir o seu projeto

1. 1Faça o checklist à mão, item por item (o link está no fim da página), ou rode npx vibedefender na pasta do projeto: a análise é local e o seu código não sai do computador.
2. 2Corrija primeiro o que é crítico: chave exposta e tabela aberta.
3. 3Troque toda chave que já esteve exposta. Corrigir o código não desfaz o vazamento.
4. 4Rode de novo depois de cada correção.

Dicas curtas de segurança para quem cria com IA: siga @npx_vibedefender no Instagram.