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.

Secrets and API keys (5 items)

Lovable's marketplace integrations and Vite build can leak env vars into the client bundle if not careful.

  1. PRE — Audit import.meta.env references. Vite exposes all VITE_ prefixed vars as import.meta.env.VITE_* in the client. Never use VITE_SUPABASE_SERVICE_KEY or VITE_STRIPE_SECRET. Route through a server-only endpoint instead.
  2. PRE — Replace Lovable marketplace test keys with live restricted keys. Lovable's Stripe / Resend / etc. integrations sometimes ship with sk_test_* or pk_test_* keys. Before going live, swap them with live restricted keys that limit damage if compromised.
  3. PRE — Check the .env file is not committed. Lovable scaffolds an .env file with integration keys. Run git ls-files .env. If it's tracked, remove it immediately: git rm --cached .env and add to .gitignore.
  4. PRE — Verify GitHub sync doesn't expose service keys. If Lovable syncs to GitHub, confirm the GitHub Actions workflow or Vercel settings don't echo secrets into build logs. Check your Actions → Workflow runs → click a run → see if any secret is printed.
  5. POST — Run Secrets in JavaScript Bundles on the deployed app. Lovable's Vite build can leak keys into import.meta.env. A passive scan will find them.

Database access control (5 items)

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. Minimum: SELECT allows user to read only rows where user_id = auth.uid(). Lovable sometimes generates tables without policies; you must add them.
  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. Open Supabase Studio post-deploy. Each table's RLS toggle should be ON. If not, your migration didn't apply.
  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.

Authentication and sessions (4 items)

Lovable's auth is Supabase Auth. The risk is in how Lovable wires it together.

  1. PRE — Ensure all API routes use getUser(), not getSession(). getSession() reads an unverified cookie; getUser() validates with Supabase. Search for getSession() in API handlers and replace it.
  2. PRE — Check Lovable's generated auth handlers for token expiry. Magic-link tokens need server-enforced expiry. Default is 1 hour — don't override unless essential.
  3. PRE — Audit the sign-in redirect guard. The next query param must start with /, never //. If missing, add the guard manually.
  4. POST — Test logout destroys the session. Sign in, sign out, inspect cookies (DevTools → Application → Cookies). The session cookie must be cleared.

HTTP headers and CSP (3 items)

Lovable's Vite scaffold doesn't add CSP by default. Static hosts require explicit header configuration.

  1. PRE — Add security headers via your host's config. Vercel: vercel.json headers array. Netlify: _headers file. Include CSP, HSTS, X-Frame-Options, X-Content-Type-Options.
  2. PRE — CSP must not have 'unsafe-inline' in script-src. Use nonces or hashes. Lovable's Vite build will work with strict CSP.
  3. POST — Run HTTP Security Headers on the deployed URL. The check reports missing headers and provides platform-specific fix guidance.

Deployment hygiene (5 items)

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: Settings → Environment Variables → scope each to Production. Never share test Stripe keys with Preview.
  2. DEPLOY — Verify build logs don't echo secrets. Check your deployment provider's build logs. If any secret is printed, it's compromised.
  3. DEPLOY — Add security headers to vercel.json or _headers. For Vercel, use headers config. For Netlify / Cloudflare, use _headers file in the public dir.
  4. POST — Test a Vercel Preview link in a private browser window. Ensure CSP nonce is fresh on each request and headers are present.
  5. POST — Rotate any test key that ever shipped to production. Even if it's a sk_test_* key, rotate it after you've seen it in production.

Lovable-specific gotchas (3 items)

Patterns unique to Lovable's scaffold and deployment flow:

  1. import.meta.env is Vite-specific and all-or-nothing. Vite exposes VITE_* vars in the client bundle by design. There's no server-only env concept in Vite without a separate API boundary. Lovable's default is client-heavy; you must add API routes for sensitive operations.
  2. GitHub sync can auto-commit without review. If Lovable syncs changes back to GitHub, confirm the workflow isn't auto-pushing without your approval. Otherwise, a malicious update could land in main.
  3. Static-host headers are a different beast than middleware. Vercel, Netlify, and Cloudflare Pages all handle headers differently. If you switch hosts, re-check your header config is applied — the platform may not give you an error if a header is unsupported.

Next steps

Review the general vibe coding security checklist for 51 cross-tool items. Then see step-by-step hardening for deeper patterns on CSP, RLS, and auth.

// scan your app

Stop reading. Start finding the gaps in yours.

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 scans / month, no card.
  • Passive scans against any URL — no domain verification needed.
  • Tuned for Cursor, Claude Code, Lovable, Bolt, v0, Replit.
  • Coding-agent prompts for code/config findings, plus operator steps for DNS/provider fixes.
Run a free scan →

no signup required

Lovable security checklist: 25 items before launch · FixVibe