FixVibe

// 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.

Segreti e chiavi API (5 articoli)

Le integrazioni del marketplace di Lovable e la build di Vite possono far trapelare env var nel pacchetto client se non si fa attenzione.

  1. PRE — Audit import.meta.env references. Vite espone tutte le variabili con prefisso VITE_ come import.meta.env.VITE_* nel client. Non utilizzare mai VITE_SUPABASE_SERVICE_KEY o VITE_STRIPE_SECRET. Instradare invece attraverso un endpoint solo server.
  2. Le integrazioni Stripe / Rinvia / ecc. di PRE — Replace Lovable marketplace test keys with live restricted keys. Lovable a volte vengono fornite con le chiavi sk_test_* o pk_test_*. Prima di andare in modalità live, scambiale con chiavi live limitate che limitano i danni in caso di compromissione.
  3. PRE — Check the .env file is not committed. Lovable supporta un file .env con le chiavi di integrazione. Esegui git ls-files .env. Se è tracciato, rimuovilo immediatamente: git rm --cached .env e aggiungilo a .gitignore.
  4. PRE — Verify GitHub sync doesn't expose service keys. Se Lovable si sincronizza con GitHub, conferma che il flusso di lavoro delle azioni GitHub o le impostazioni Vercel non riportino i segreti nei log di build. Controlla le tue Azioni → Esecuzioni del flusso di lavoro → fai clic su un'esecuzione → verifica se viene stampato qualche segreto.
  5. POST — Run Secrets in JavaScript Bundles on the deployed app. La build Vite di Lovable può far penetrare le chiavi in import.meta.env. Una scansione passiva li troverà.

Controllo dell'accesso al database (5 articoli)

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

  1. 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.
  2. PRE — Write explicit policies per table and role. Minimo: SELECT consente all'utente di leggere solo le righe in cui user_id = auth.uid(). Lovable a volte genera tabelle senza criteri; devi aggiungerli.
  3. 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.)
  4. DEPLOY — Re-verify RLS is enforced after deploy. Aprire Supabase Studio dopo la distribuzione. L'interruttore RLS di ciascuna tabella dovrebbe essere ON. In caso contrario, la tua migrazione non è stata applicata.
  5. 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.

Autenticazione e sessioni (4 articoli)

L'autenticazione di Lovable è Supabase Auth. Il rischio sta nel modo in cui Lovable lo collega insieme.

  1. PRE — Ensure all API routes use getUser(), not getSession(). getSession() legge un cookie non verificato; getUser() convalida con Supabase. Cerca getSession() nei gestori API e sostituiscilo.
  2. PRE — Check Lovable's generated auth handlers for token expiry. I token Magic-link necessitano di una scadenza imposta dal server. L'impostazione predefinita è 1 ora: non sovrascrivere a meno che non sia essenziale.
  3. PRE — Audit the sign-in redirect guard. Il parametro di query next deve iniziare con /, mai //. Se mancante, aggiungere la protezione manualmente.
  4. POST — Test logout destroys the session. Accedi, esci, controlla i cookie (DevTools → Applicazione → Cookie). Il cookie di sessione deve essere cancellato.

HTTP intestazioni e CSP (3 elementi)

L'impalcatura Vite di Lovable non aggiunge CSP per impostazione predefinita. Gli host statici richiedono una configurazione esplicita dell'intestazione.

  1. PRE — Add security headers via your host's config. Vercel: vercel.json headers array. Netlify: file _headers. Include CSP, HSTS, opzioni X-Frame, opzioni X-Content-Type.
  2. PRE — CSP must not have 'unsafe-inline' in script-src. Utilizza nonce o hash. La build Vite di Lovable funzionerà con il rigoroso CSP.
  3. POST — Run HTTP Security Headers on the deployed URL. Il controllo segnala le intestazioni mancanti e fornisce indicazioni per la correzione specifiche della piattaforma.

Igiene della distribuzione (5 articoli)

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.

  1. DEPLOY — Scope env vars to Production only. Vercel: Impostazioni → Variabili d'ambiente → ambito ciascuno a Production. Non condividere mai i tasti test Stripe con Anteprima.
  2. DEPLOY — Verify build logs don't echo secrets. Controlla i log di build del tuo provider di distribuzione. Se viene stampato un segreto, è compromesso.
  3. DEPLOY — Add security headers to vercel.json or _headers. Per Vercel, utilizzare headers config. Per Netlify / Cloudflare, utilizzare il file _headers nella directory pubblica.
  4. POST — Test a Vercel Preview link in a private browser window. Assicurati che CSP nonce sia aggiornato su ogni richiesta e che le intestazioni siano presenti.
  5. POST — Rotate any test key that ever shipped to production. Anche se è un tasto sk_test_*, ruotalo dopo averlo visto in produzione.

Lovable trucchi specifici (3 articoli)

Modelli univoci per l'impalcatura e il flusso di distribuzione di Lovable:

  1. import.meta.env is Vite-specific and all-or-nothing. Vite espone VITE_* vars nel pacchetto client in base alla progettazione. Non esiste un concetto di ambiente solo server in Vite senza un confine API separato. L'impostazione predefinita di Lovable è molto client; è necessario aggiungere API percorsi per operazioni sensibili.
  2. GitHub sync can auto-commit without review. Se Lovable sincronizza nuovamente le modifiche con GitHub, verifica che il flusso di lavoro non venga inviato automaticamente senza la tua approvazione. In caso contrario, un aggiornamento dannoso potrebbe arrivare a main.
  3. Static-host headers are a different beast than middleware. Vercel, Netlify e Cloudflare Le pagine gestiscono tutte le intestazioni in modo diverso. Se cambi host, ricontrolla che la configurazione dell'intestazione sia applicata: la piattaforma potrebbe non fornire un errore se un'intestazione non è supportata.

Prossimi passi

Esamina general vibe coding security checklist per 51 elementi cross-tool. Quindi vedere step-by-step hardening per modelli più approfonditi su CSP, RLS e auth.

// scansiona la tua app

Smetti di leggere. Inizia a trovare le falle nella tua.

Drop in a URL — FixVibe runs every passive check from this guide plus the rest of its 230+ passive checks, usually in under a minute. Free, no install, no card.

  • Free tier — 3 scansioni / mese, senza carta.
  • Scansioni passive contro qualsiasi URL — nessuna verifica di dominio.
  • Ottimizzato per Cursor, Claude Code, Lovable, Bolt, v0, Replit.
  • Coding-agent prompts for code/config findings, plus operator steps for DNS/provider fixes.
Lovable security checklist: 25 items before launch · FixVibe