Segurança para apps criadas com IA

O que significa "segurança em vibe coding"

As ferramentas de IA (Lovable, Bolt, v0, Cursor, Replit, Windsurf) geram apps com uma arquitetura muito concreta: o browser fala diretamente com a base de dados (Supabase, Firebase) e com serviços externos (Stripe, OpenAI, Resend). Quase não há servidor próprio pelo meio. Isso acelera tudo, mas passa a segurança do teu código para a tua configuração: o que te protege são as regras da base de dados, os headers HTTP, a política de CORS e o sítio onde vivem as chaves, não o quão limpo está o código da interface.

Essas peças não vêm bem configuradas por defeito, e a IA raramente as configura se não lho pedires. O objetivo dela é que a app funcione na demo, e uma tabela sem restrições ou uma chave colada no frontend "funcionam" na perfeição. O resultado são apps que parecem impecáveis e que expõem dados ou chaves a qualquer pessoa que saiba onde procurar: não é preciso ser hacker, basta abrir as ferramentas de programador do browser.

Por isso "segurança em vibe coding" não significa aprender criptografia nem contratar uma auditoria. Significa conhecer a meia dúzia de falhas que se repetem em quase todas as apps criadas com IA, saber verificá-las por fora e pedir à mesma IA que as corrija com instruções precisas.

Porque é que as apps criadas com IA falham no mesmo

Há um padrão. A IA otimiza para que o código compile e o ecrã mostre dados, não para que um desconhecido não os consiga ver. Quando uma consulta falha por permissões, a solução mais curta é tirar a permissão que estorva: desativar o Row Level Security, pôr uma regra que permite tudo ou usar a chave de administrador. E a IA escolhe a solução mais curta.

O segundo motivo é que copia templates. As variáveis com prefixo NEXT_PUBLIC_, VITE_ ou NUXT_PUBLIC_ são enviadas para o browser por desenho, e muitos exemplos da internet colocam lá chaves que nunca deviam sair do servidor. As regras do Firebase em modo de teste permitem ler e escrever a qualquer pessoa durante 30 dias, e lançam-se apps com esse modo ativo. Os headers de segurança não aparecem em quase nenhum tutorial, por isso também não aparecem na app.

O terceiro é que ninguém desenha o modelo de ameaça. Quem constrói com IA pensa no utilizador que quer, não no visitante que abre o separador Network, copia o URL da API e lhe tira o filtro. Este guia é sobre pôr-se no lugar desse visitante durante dez minutos.

As sete falhas que mais mordem as apps criadas com IA

Chaves de API no browser. Ao "ligar" um serviço, a chave acaba no JavaScript do cliente, onde fica pública para sempre: qualquer pessoa a pode ler vendo o código-fonte e usá-la à tua custa (faturas da OpenAI, emails enviados do teu domínio, acesso aos teus dados). As únicas chaves que podem ir para o cliente são as desenhadas para isso, como a chave anon ou publishable do Supabase, a chave pública do Stripe ou a configuração do Firebase, e só se as regras por trás estiverem bem.

Regras da base de dados em falta ou fracas. Sem Row Level Security ativo em cada tabela do Supabase, ou com uma política que permite tudo, qualquer pessoa lê e escreve os teus dados sem iniciar sessão, usando a mesma API que a tua app usa. No Firebase, as regras em modo de teste ou com allow read, write: if true fazem o mesmo. É a falha mais grave e a mais frequente, e foi a origem da vulnerabilidade CVE-2025-48757 que expôs dados de utilizadores em apps feitas com o Lovable.

CORS permissivo. Uma API que responde com Access-Control-Allow-Origin a refletir qualquer origem e ainda permite credenciais deixa que um site malicioso faça pedidos em nome dos teus utilizadores e leia as respostas. O asterisco numa API pública sem cookies é aceitável; refletir a origem com credenciais, nunca.

Headers de segurança ausentes. Sem Content-Security-Policy, Strict-Transport-Security, X-Frame-Options (ou frame-ancestors), X-Content-Type-Options, Referrer-Policy e Permissions-Policy, a tua app fica exposta a clickjacking, injeção de scripts, downgrade para HTTP e fugas de URLs internos. Configuram-se no servidor ou no alojamento (Vercel, Netlify, Cloudflare) em dez linhas.

Ficheiros sensíveis acessíveis. Um .env publicado por engano, uma pasta .git exposta, source maps que permitem reconstruir o código-fonte completo, backups da base de dados ou painéis de administração sem autenticação. São fáceis de encontrar porque os atacantes os procuram automaticamente em cada domínio novo que aparece.

Sessões e cookies mal configuradas. Cookies de sessão sem os atributos Secure, HttpOnly e SameSite, tokens guardados no localStorage ao alcance de qualquer script, ou sessões que nunca caducam. Um XSS pequeno transforma-se em roubo de contas quando a cookie é legível a partir do JavaScript.

Endpoints que confiam no cliente. Rotas de API que aceitam o identificador do utilizador, o preço ou o papel a partir do corpo do pedido sem o verificar no servidor. Se a interface esconde o botão de administrador mas a rota continua a responder a qualquer pessoa, o botão não protege nada.

O que rever consoante a tua stack

Lovable, Bolt ou v0 com Supabase. Confirma que todas as tabelas têm RLS ativo e políticas por operação (select, insert, update, delete) baseadas em auth.uid(); que a chave service_role não está em nenhuma variável pública; que os buckets privados do Storage têm políticas; e que as vistas e funções RPC não saltam as políticas. O painel do Supabase inclui um Security Advisor que lista o mais grave.

Cursor, Windsurf ou Replit com Next.js, Nuxt ou Express publicado na Vercel. Verifica que variáveis de ambiente levam prefixo público, que as rotas de API validam a sessão em cada pedido e não só na interface, que os headers de segurança estão definidos (vercel.json, next.config ou nuxt.config) e que não se publicam source maps em produção.

Firebase. Substitui as regras de modo de teste por regras baseadas em request.auth, tanto no Firestore como no Storage; ativa o App Check para que só a tua app possa usar os teus serviços; e confirma que as Cloud Functions que fazem algo sensível verificam o token do utilizador antes de agir.

A app "parecer bem" não quer dizer que seja segura

Esconder um botão na interface não protege nada: o pedido continua a ser um URL público que qualquer pessoa pode chamar diretamente a partir da consola do browser ou com curl. A segurança a sério vive no servidor e na base de dados, não naquilo que o utilizador vê. É por isso que verificar por fora —como faria um atacante— é a única forma de saber o que está realmente exposto.

Também não basta o cadeado HTTPS estar a verde. O HTTPS cifra o caminho entre o browser e o teu servidor; não diz nada sobre se o servidor entrega dados a quem não deve. Uma app com certificado perfeito e uma tabela sem RLS é uma app com uma fuga perfeitamente cifrada.

Como verificar tu mesmo em dez minutos

Um: abre o teu site e vê o código-fonte (clique direito, ver código-fonte da página). Procura key, secret, sk_, service_role e os nomes dos serviços que usas. Tudo o que aparecer aí é público.

Dois: com a app aberta, vai ao separador Network das ferramentas de programador, localiza um pedido à tua base de dados ou à tua API, copia o URL e abre-o numa janela anónima. Se devolver dados sem sessão, esse endpoint está aberto. Com sessão, tira-lhe o filtro de utilizador ao URL: se devolver linhas de outros, as políticas estão mal.

Três: pede os headers do teu domínio com curl -I https://oteudominio.com e confirma se aparecem Content-Security-Policy, Strict-Transport-Security e X-Frame-Options ou frame-ancestors. Se faltar algum, não está configurado.

Quatro: tenta abrir /.env, /.git/config, /config.json e algum ficheiro .js.map do teu bundle. Todos devem devolver 404 ou 403.

Cinco: cria duas contas de teste e confirma que nenhuma vê, edita ou apaga o da outra, ficheiros carregados incluídos. É o teste mais aborrecido e o que mais falhas encontra.

Como verificar em 30 segundos

O Scanaris automatiza esses testes e mais uns quantos. Analisa o teu site já publicado em modo só de leitura: não toca no teu código, não injeta nada nem tenta explorar nada; olha para o que já é público, como qualquer pessoa faria por fora. Verifica headers, cookies, certificado TLS, CORS, segredos no JavaScript, ficheiros sensíveis, tecnologias com versões conhecidas, as regras do Supabase se lhe deres uma ligação só de leitura, e ainda como o Google te vê e como as IA te leem.

Cada resultado vem ordenado por impacto (primeiro o crítico), explicado em linguagem normal e com um prompt de correção pronto a colar no Lovable, no Cursor ou na ferramenta que usares. Cola o teu URL, espera meio minuto e saberás se podes partilhar a tua app com tranquilidade.

O que vigiar depois de lançar

A segurança não é um estado, é um hábito. Cada tabela nova nasce sem RLS, cada função nova pode meter uma chave no sítio errado e cada dependência envelhece. Agenda uma nova análise periódica e revê as diferenças, não o relatório inteiro: o importante é o que se abriu desde a última vez.

Vigia também o que não depende do código: que o certificado e o domínio não caduquem, que o site responda, e que no browser dos teus utilizadores não apareçam scripts que tu não puseste. E quando corrigires algo, volta a verificá-lo por fora: a correção conta quando o scanner deixa de a ver, não quando a IA diz que está feito.

Aprofunda para a tua stack

Verificações de segurança essenciais

Guias relacionados

Perguntas frequentes