// docs / security guides / lovable checklist

Lovable security checklist: 25 items before launch

Lovable is a fast path from idea to a published full-stack app on Supabase and Vite. This checklist targets the risks that come with that stack: RLS that must be enabled and tightened on every table Lovable creates, test keys from integrations, import.meta.env leaking env vars into the Vite bundle, GitHub sync exposing secrets, and missing security headers. 25 items across secrets, database, auth, headers, deployment, and Lovable-specific gotchas.

PRE = pre-deploy (audit your source). DEPLOY = at deploy time. POST = post-deploy verification.

Segredos e chaves API (5 itens)

As integrações de mercado de Lovable e a construção do Vite podem vazar env vars no pacote do cliente se não tomarmos cuidado.

PRE — Audit import.meta.env references. Vite expõe todos os vars prefixados VITE_ como import.meta.env.VITE_* no cliente. Nunca use VITE_SUPABASE_SERVICE_KEY ou VITE_STRIPE_SECRET. Em vez disso, roteie por meio de um endpoint somente de servidor.
PRE — Replace Lovable marketplace test keys with live restricted keys. Lovable Stripe / Reenviar / etc. integrações às vezes são fornecidas com chaves sk_test_* ou pk_test_*. Antes de ir ao ar, troque-as por chaves restritas ativas que limitam os danos se comprometidas.
PRE — Check the .env file is not committed. Lovable cria um arquivo .env com chaves de integração. Execute git ls-files .env. Se for rastreado, remova-o imediatamente: git rm --cached .env e adicione a .gitignore.
PRE — Verify GitHub sync doesn't expose service keys. Se Lovable sincronizar com GitHub, confirme o fluxo de trabalho de ações GitHub ou as configurações de Vercel não ecoam segredos nos logs de construção. Verifique suas ações → execuções do fluxo de trabalho → clique em uma execução → veja se algum segredo foi impresso.
POST — Run Secrets in JavaScript Bundles on the deployed app. Lovable's Vite build pode vazar chaves para import.meta.env. Uma varredura passiva irá encontrá-los.

Controle de acesso ao banco de dados (5 itens)

Every table Lovable creates needs RLS enabled and tightened before production.

PRE — Enable RLS on every public table. In Supabase Studio, Tables → for each public.* table → the RLS toggle must be ON, with policies for each command.
PRE — Write explicit policies per table and role. Mínimo: SELECT permite ao usuário ler apenas linhas onde user_id = auth.uid(). Lovable às vezes gera tabelas sem políticas; você deve adicioná-los.
PRE — Check Lovable's generated policies, not just the toggle. A policy such as USING (true) keeps RLS "on" while letting every caller through. Scope each policy to auth.uid(). (FORCE ROW LEVEL SECURITY only affects the table owner; it does not fix an open policy.)
DEPLOY — Re-verify RLS is enforced after deploy. Abra Supabase Studio pós-implantação. A alternância RLS de cada tabela deve ser ON. Caso contrário, sua migração não se aplica.
POST — Run a FixVibe scan on the deployed app. Check the Supabase Row-Level Security result: it shows any table an anonymous visitor can read with your public key.

Autenticação e sessões (4 itens)

A autenticação de Lovable é Supabase Auth. O risco está em como Lovable conecta tudo.

PRE — Ensure all API routes use getUser(), not getSession(). getSession() lê um cookie não verificado; getUser() valida com Supabase. Pesquise getSession() nos manipuladores API e substitua-o.
PRE — Check Lovable's generated auth handlers for token expiry. Os tokens Magic-link precisam de expiração imposta pelo servidor. O padrão é 1 hora — não substitua, a menos que seja essencial.
PRE — Audit the sign-in redirect guard. O parâmetro de consulta next deve começar com /, nunca //. Se estiver faltando, adicione a proteção manualmente.
POST — Test logout destroys the session. Faça login, saia, inspecione cookies (DevTools → Aplicativo → Cookies). O cookie da sessão deve ser limpo.

HTTP cabeçalhos e CSP (3 itens)

O andaime Vite de Lovable não adiciona CSP por padrão. Hosts estáticos requerem configuração de cabeçalho explícita.

PRE — Add security headers via your host's config. Vercel: vercel.json headers matriz. Netlify: arquivo _headers. Inclui CSP, HSTS, X-Frame-Options, X-Content-Type-Options.
PRE — CSP must not have 'unsafe-inline' in script-src. Use nonces ou hashes. A construção do Vite de Lovable funcionará com CSP estrito.
POST — Run HTTP Security Headers on the deployed URL. A verificação relata cabeçalhos ausentes e fornece orientação de correção específica da plataforma.

Higiene de implantação (5 itens)

Lovable hosts published apps itself (Lovable docs). If you export the code and deploy it to Vercel, Netlify or Cloudflare Pages instead, each host handles headers and env vars differently.

DEPLOY — Scope env vars to Production only. Vercel: Configurações → Variáveis de ambiente → escopo de cada uma para Production. Nunca compartilhe chaves de teste Stripe com o Preview.
DEPLOY — Verify build logs don't echo secrets. Verifique os logs de compilação do seu provedor de implantação. Se algum segredo for impresso, ele estará comprometido.
DEPLOY — Add security headers to vercel.json or _headers. Para Vercel, use headers configuração. Para Netlify / Cloudflare, use o arquivo _headers no diretório público.
POST — Test a Vercel Preview link in a private browser window. Certifique-se de que CSP o nonce esteja atualizado em cada solicitação e que os cabeçalhos estejam presentes.
POST — Rotate any test key that ever shipped to production. Mesmo que seja uma chave sk_test_*, gire-a depois de vê-la em produção.

pegadinhas específicas de Lovable (3 itens)

Padrões exclusivos do scaffold e do fluxo de implantação do Lovable:

import.meta.env is Vite-specific and all-or-nothing. Vite expõe VITE_* vars no pacote do cliente por design. Não há conceito de ambiente somente de servidor no Vite sem um limite API separado. O padrão de Lovable é muito cliente; você deve adicionar API rotas para operações confidenciais.
GitHub sync can auto-commit without review. Se Lovable sincronizar as alterações de volta para GitHub, confirme se o fluxo de trabalho não está sendo enviado automaticamente sem sua aprovação. Caso contrário, uma atualização maliciosa pode chegar ao main.
Static-host headers are a different beast than middleware. Vercel, Netlify e Cloudflare Pages lidam com cabeçalhos de maneira diferente. Se você trocar de host, verifique novamente se a configuração do cabeçalho foi aplicada - a plataforma pode não apresentar um erro se um cabeçalho não for compatível.

Próximas etapas

Revise general vibe coding security checklist para 51 itens de ferramentas cruzadas. Então veja step-by-step hardening para padrões mais profundos em CSP, RLS e autenticação.