Segurança e visibilidade para a tua app de Lovable

"Segurança no Lovable" são duas coisas que convém separar. A primeira é o projeto do Lovable em si: o que colas no chat, onde guarda os segredos, quem pode ver o teu projeto e onde a app acaba publicada. A segunda é o código que o Lovable gera, que é uma SPA em React com Supabase e traz sempre as mesmas cinco ou seis falhas. Este guia cobre as duas, com um bloco de instruções para a secção Knowledge do teu projeto, um prompt de revisão antes de publicar e a forma de verificar o resultado de fora.

Parte 1: proteger o teu projeto do Lovable

O que colas no chat fica lá

O chat do projeto é o histórico da tua app: cada prompt, cada chave que colaste "para funcionar" e cada resposta. Se uma chave secreta entra pelo chat, o modelo tende a escrevê-la diretamente no código do frontend, e a partir daí viaja no bundle para todos os visitantes. A regra é simples: as chaves nunca entram pelo chat. Quando o Lovable te pede um segredo para ligar um serviço, usa a caixa de segredos que ele oferece; isso guarda-o como variável das Edge Functions do Supabase, do lado do servidor, e o código gerado lê-o com Deno.env.get.

Segredos: servidor sim, navegador não

O Lovable sabe fazer duas coisas com uma integração: chamá-la a partir do navegador ou a partir de uma Edge Function. A primeira é correta para chaves públicas (a anon do Supabase, a publishable do Stripe, o ID de um projeto). A segunda é a única opção para chaves secretas (OpenAI, Resend, a secret do Stripe, a service_role). Se ao pedires uma funcionalidade o resultado a chama a partir de um componente React com a chave lá dentro, pede-lhe explicitamente que a mova para uma Edge Function. Mais em segredos que a tua app deixa fugir no navegador.

Visibilidade do projeto e do código

Um projeto público no Lovable expõe o código e o histórico de prompts a quem tiver o link, incluindo qualquer chave que alguma vez colaste. Revê a visibilidade nas definições do projeto e, se ativaste a sincronização com o GitHub, confirma que o repositório é privado. Se uma chave esteve num projeto ou repositório público, dá-a por comprometida e roda-a.

Onde vive a app publicada

O Lovable publica num subdomínio .lovable.app ou no teu próprio domínio. Esse alojamento não te deixa configurar cabeçalhos de segurança nem redirecionamentos personalizados. Para muitas apps chega; se precisas de Content-Security-Policy, HSTS ou regras de cache, exporta para o GitHub e faz deploy na Vercel ou na Netlify com o respetivo ficheiro de configuração. Lembra-te também de que o URL de preview de cada versão é acessível a quem o tiver.

O Supabase é teu, não do Lovable

Ao ligar o Supabase (ou ao usar o backend gerido do Lovable, que é Supabase por baixo), o Lovable cria tabelas, políticas e funções por ti. Mas RLS, buckets e definições de Auth continuam a ser responsabilidade tua. O Lovable acrescentou uma revisão de segurança antes de publicar depois da CVE-2025-48757; toma-a como um primeiro filtro, não como garantia, e repassa o guia de segurança para Supabase, que tem três consultas SQL para auditar o projeto num minuto.

Parte 2: as falhas que o Lovable mete no teu código

• Tabelas sem RLS ou com políticas using (true). A origem da CVE e a falha mais grave. Qualquer pessoa com a chave anon lê e escreve os teus dados.
• Verificações de permissões só no frontend. Uma rota /admin que apenas esconde o botão se o utilizador não for administrador. O servidor (RLS ou a Edge Function) tem de o verificar também, porque a API pode ser chamada sem passar pela interface.
• Edge Functions sem autenticação nem limite. O template responde a qualquer pessoa, com Access-Control-Allow-Origin: *, e se chama a OpenAI ou envia emails, qualquer pessoa pode gastar a tua quota. Exige o JWT do utilizador, limita a origem e põe um teto de pedidos por utilizador.
• Buckets públicos para ficheiros de utilizadores. O Lovable cria o bucket público porque assim as imagens "aparecem". Para documentos privados, bucket privado e URLs assinados.
• Invisível para a IA e os motores de busca. A app é uma SPA de Vite: o HTML chega vazio e os bots do ChatGPT ou do Perplexity não veem nada. Se a landing e o blog importam, separa-os da app. Detalhe em porque é que as apps feitas com IA são invisíveis para a IA.
• Sem cabeçalhos de segurança nem metadados. Nem CSP, nem HSTS, nem X-Frame-Options, e o título é o do template. O primeiro exige deploy fora do lovable.app; o segundo resolve-se com um prompt.
• Validação só no formulário. O campo tem maxLength mas a Edge Function ou a tabela aceitam o que chegar. Valida também no servidor e nas restrições da base de dados.

Um bloco para a secção Knowledge do teu projeto

Nas definições do projeto, o Lovable tem uma secção de conhecimento que o modelo lê em cada pedido. Cola isto para que as regras se apliquem desde o primeiro prompt:

Regras de segurança deste projeto:
- Toda a tabela nova tem RLS ativado e uma política explícita por operação. Nunca uses using (true) nem with check (true) exceto em tabelas de conteúdo público só de leitura, e avisa-me quando o fizeres.
- Nunca ponhas chaves secretas no código do frontend. As integrações com chaves secretas vão numa Edge Function que lê o segredo com Deno.env.get.
- Toda a Edge Function verifica o JWT do utilizador salvo indicação minha em contrário, limita Access-Control-Allow-Origin ao nosso domínio e valida a entrada.
- As permissões de administrador verificam-se no RLS ou no servidor, nunca só no frontend.
- Os ficheiros carregados por utilizadores vão para buckets privados com políticas e URLs assinados.
- As colunas role, is_admin, plan e credits não são editáveis pelo utilizador.
- Põe título, meta descrição e etiquetas Open Graph reais no index.html.

Um prompt de revisão antes de publicar

Revê a segurança deste projeto e não mudes nada ainda. Responde com uma lista:
1. Tabelas sem RLS e políticas com using (true) ou with check (true).
2. Chaves ou tokens presentes no código do frontend, com o ficheiro e a linha.
3. Edge Functions que não verificam o JWT, que respondem com Access-Control-Allow-Origin: * ou que não validam a entrada.
4. Rotas ou ações de administrador protegidas só no frontend.
5. Buckets públicos com ficheiros de utilizadores.
6. Colunas de privilégio que um utilizador pode modificar.
7. Metadados do index.html que continuem a ser os do template.
Para cada ponto, propõe a alteração exata e espera pela minha confirmação.

Verifica o resultado de fora

Abre a tua app publicada numa janela anónima, clique direito, "Ver código-fonte", e procura service_role, sk_live, sk- e Bearer nos ficheiros JavaScript que carrega. Depois testa a API do Supabase sem sessão:

curl -s "https://O_TEU_PROJETO.supabase.co/rest/v1/profiles?select=*" -H "apikey: A_TUA_CHAVE_ANON" -H "Authorization: Bearer A_TUA_CHAVE_ANON"

Se devolver linhas, essa tabela está aberta. O Scanaris faz isto e cerca de quarenta verificações mais em 30 segundos: deteta que a app é do Lovable, testa as tabelas do Supabase sem sessão, procura segredos no bundle, revê cabeçalhos, cookies, CORS e ficheiros expostos, e verifica se o teu conteúdo é legível sem JavaScript. Por cada falha dá-te um fix prompt para colar no chat do Lovable com a alteração exata, e pode voltar a analisar todos os dias, porque uma regeneração de código pode trazer de volta uma falha que já tinhas corrigido.

Perguntas frequentes

O Lovable já corrigiu o problema do RLS?

O Lovable acrescentou uma revisão de segurança antes de publicar e melhorou os templates, mas o modelo continua a gerar políticas abertas quando uma consulta falha. A responsabilidade do RLS é tua: usa as consultas do guia do Supabase.

Posso pôr cabeçalhos de segurança numa app alojada em lovable.app?

Não a partir do Lovable. Se precisas deles, sincroniza com o GitHub e faz deploy na Vercel ou na Netlify, onde se configuram com um ficheiro. A app continua a ser editada no Lovable.

O que faço se colei uma chave secreta no chat?

Roda-a no serviço de origem mesmo que já não esteja no código: o histórico do chat e os bundles anteriores conservam-na. Depois acrescenta-a pela caixa de segredos e pede ao modelo que mova a integração para uma Edge Function.