Your Lovable app works. Is it safe to launch?
You prompted your way to a working app, hit Publish, and it’s live at your own domain. Then the doubt arrives at 1am: is any of this actually secure? Could someone read my users’ data? Would I even know?
The doubt is justified. Lovable apps talk to the database directly from the browser, which means a misconfigured policy is not a bug — it’s a public data leak. In 2025 a researcher found 303 exposed endpoints across 170+ Lovable projects in one sweep (CVE-2025-48757). The good news: the failure modes are extremely consistent, and every one of them is checkable.
The 8 risks real Lovable apps ship with
Compiled from documented incidents, CVEs, and platform docs — the same failure modes a Launch Check hunts for in your app, with what to do about each.
-
Row Level Security missing or broken — anyone can dump your tables
Lovable apps query Supabase Postgres straight from the browser with the public anon key, so RLS policies are your entire authorization layer. The AI has historically created tables without RLS, or with policies that don’t actually restrict anything — that’s CVE-2025-48757: 303 vulnerable endpoints across 170+ Lovable projects leaking emails, phone numbers, payment status, and API keys, all readable by unauthenticated requests.
What to do: In the Supabase dashboard (or Lovable Cloud’s database view), verify RLS is enabled on every table — then read each policy and hunt for “USING (true)” or anything that never references auth.uid(). Test like an attacker: query your tables with curl and only the anon key, logged out, and as user B against user A’s rows. Re-check after every schema-changing prompt.
-
Secret API keys in the browser bundle
Ask Lovable to “integrate OpenAI/Stripe/Resend” and the fastest working demo is a direct frontend call with the secret key in the bundle — readable by anyone in DevTools. Two Lovable-specific traps: pasting the Supabase service_role key (which bypasses all RLS) into the client, and storing secrets as VITE_-prefixed variables, which are public by definition. The CVE-2025-48757 research recovered live Gemini and Google Maps keys from deployed apps.
What to do: View-source your deployed bundle and search for any key that isn’t the anon key. Move secrets into edge-function secrets and have the frontend call the function as a proxy — Lovable builds this pattern if you ask for it explicitly. Rotate anything that was ever hardcoded or pasted into the chat.
-
Preview and production share one backend — prompts edit your live database
Publish snapshots only the frontend. Schema migrations and edge-function changes the AI makes while you iterate hit your one shared backend immediately — so once real users exist, “restructure the users table” executes against production data. Chat Restore reverts code, not the database: lost data doesn’t come back.
What to do: Before real users arrive, separate environments: GitHub sync, a dev branch, and a second Supabase project for development. At minimum, take a manual database backup before any schema-touching prompt, and treat chat restore as code-only undo.
-
Authorization living in React instead of the database
Lovable gates access where it’s easiest — hidden buttons and route guards in the frontend — while the auto-generated Supabase REST API stays reachable by anyone. A February 2026 disclosure of one popular Lovable app found 16 vulnerabilities (6 critical), including guard logic that blocked logged-in users but allowed anonymous ones, exposing 18,697 user records.
What to do: Enforce roles in RLS policies and edge-function checks, never in components. Prompt Lovable explicitly: “enforce this permission in RLS, not in the UI” — then verify by calling the REST endpoints directly with another user’s IDs and with no session at all.
-
Trusting the Publish security scan as a launch gate
The automatic scan on publish is a 10–15 second configuration lint. The Deep scan that actually reviews access control never runs automatically, you can publish over critical warnings, and Lovable’s own docs say the tools “do not replace a thorough security review.” Apps have passed the scan and leaked anyway — the 18,697-record app shipped through this exact pipeline.
What to do: Run the Deep scan manually before launch and treat a clean result as a smoke test, not a sign-off. For anything holding PII, payments, or auth, get an independent human review of the RLS policies, edge functions, and auth flows.
-
Edge functions publicly invokable — or silently reverting
Lovable deploys Supabase Edge Functions automatically when changed. Recurring failures: verify_jwt = false on functions that should require auth (anyone can invoke them to send email or burn your paid AI credits), and functions missing from supabase/config.toml losing their settings on redeploy — a function you secured can quietly revert.
What to do: Audit supabase/config.toml: every function listed, verify_jwt explicit, false only for true webhooks (which must verify signatures instead). Inside each function, confirm the caller’s identity comes from the JWT — not the request body. Invoke each one unauthenticated with curl to prove the behavior.
-
The backend dies silently — and nothing tells you
A free-tier Supabase project auto-pauses after 7 days of inactivity; the published app then renders a blank screen with no error. Lovable Cloud draws from prepaid usage balances that can simply run out. Lovable ships zero uptime monitoring, error tracking, or alerting — every one of these outages is discovered by your users, not you.
What to do: Upgrade the backend to a paid plan for production (or add a scheduled keep-alive ping), enable auto top-up with a sane limit on Cloud, and add external monitoring before launch: an uptime check that actually queries the database, plus error tracking (Sentry is promptable into Lovable apps).
-
lovable.app hosting is a snapshot, not a deployment pipeline
Publish deploys a static snapshot — later edits aren’t live until you republish, which produces the classic “preview works, prod broken” drift. There’s no CI gate, no canary, no rollback beyond republishing, and Lovable generates no tests — so every republish is an untested full replace of production.
What to do: For a real launch, make GitHub sync the source of truth and deploy the frontend via Vercel/Netlify with preview deploys and instant rollback. If you stay on Lovable hosting, make republish a deliberate release step: Deep scan + a manual click-through of your money paths first.
Why trust this list? We build with AI ourselves and we've deployed production systems to millions of users. Reviewing and hardening AI-built apps is all we do — we know exactly what Lovable gets right, and exactly where it breaks.
A checklist can't read your app. We can.
The items above are the pattern — your app is the specific case. A Launch Check ($799, one-time) is a senior engineer reviewing your actual Lovable app across security, architecture, tests, delivery, and operations — back in 24–72 hours as a severity-ranked launch plan, plus a 15-minute findings call.
Start a Launch Check Not ready? Self-score free in 2 minutesGuarantee: If the report doesn’t change how you launch, tell us within 14 days — full refund.
Already live and something's breaking? Emergency rescue — same-day triage →
Common questions
Is Lovable safe for production?
The platform itself is fine — the generated configuration frequently isn’t. The risk concentrates in Row Level Security policies, client-side authorization, and exposed keys, because Lovable apps query the database directly from the browser. Fix those (and verify them like an attacker would) and a Lovable app can absolutely run in production.
Is Lovable’s built-in security scan enough?
No — and Lovable says so themselves: the docs state the scans “do not replace a thorough security review.” The publish-time scan is a fast configuration lint; it has passed apps that later leaked thousands of records. Use it as a smoke test and get the access-control logic reviewed by a human before launch.
Can you review my app if it’s on Lovable Cloud and I can’t export the code?
Yes. We review through the platform — your staging or published URL, the database policies, and collaborator access where supported. Most of what matters (security, reliability, operations) is observable from the running app and its configuration.