Is Lovable Safe? Security Issues + Launch Checklist (2026)

Is Lovable safe? Depends which "Lovable" you mean, and most people asking are mixing the two up. The company runs a compliance programme and ships a scanner. The thing it generates for you ships with a database that is only as locked as the row-level policies the AI happened to write. In the one incident that got a CVE number, those policies were missing or wide open in roughly 1 in 10 apps checked. So: safe to build with, risky to launch from until you have personally confirmed the data layer. Here is the whole picture, sourced.

Is Lovable safe to use?

For prototyping, yes. For an app that will hold other people's data, only after you have done the work in the checklist below.

Split it into two questions, because the answers differ.

Is Lovable, the company, safe to hand your account and code to? Reasonably. Its security page displays SOC 2 Type II and ISO 27001 badges and says Lovable "supports SOC 2 and GDPR requirements," with security documentation and data protection agreements available for enterprise review. The actual reports sit behind a request process, so if your buyer needs the paper, ask for it. The same page says Business and Enterprise plan data is not used to train models, and Free and Pro users can opt out in settings. Secrets are encrypted at rest. Lovable Cloud offers regional hosting in the EU, US and Asia Pacific. None of that is unusual for a 2026 SaaS vendor, which is the point. It is a normal company with normal controls.

Is the app Lovable builds for you safe? Not by default, and Lovable itself says so. Its own docs state that the built-in scans "do not replace a thorough security review" and "cannot guarantee complete security," and recommend "an additional professional review" for apps handling sensitive data. That is the honest line, and it matches what we see when founders send us Lovable apps: the UI is fine, the auth flow usually works, and the database is reachable by anyone who reads the network tab.

Every AI builder lands in the same place. Bolt, v0, Cursor, Replit, Copilot: all generate code that runs, not code that is secured. Veracode's 2025 study of 100+ models found AI-generated code introduced risky security flaws in 45% of tests, and larger, newer models did not improve that number. Lovable is simply the builder with the most users and the one public CVE, so it gets the most scrutiny. That is not a reason to pick a different tool. It is a reason to know exactly where the hole is.

Lovable security issues: what has actually happened

Here is the record, limited to things with a primary source. No breach rumours, no vendor-blog estimates.

Issue	Impact	Status	Your fix
CVE-2025-48757: missing or insufficient Supabase RLS on Lovable-generated apps (CVE record, Palmer write-up)	Unauthenticated read and write to database tables using only the public anon key. Researchers' scan: 303 vulnerable endpoints across 170 projects, about 10.3% of 1,645 apps checked, homepages only. Exposed: names, emails, third-party API keys, transaction and subscription rows, including the ability to change payment status.	Published 30 May 2025. CVSS 3.1 base 9.3 (Critical), CWE-863. No patch version exists; the CVE record lists the issue as affecting Lovable "through 2025-04-15." Lovable disputes the classification (see below).	Enable RLS on every table in an exposed schema, write per-user policies, revoke blanket grants from anon, then test as a logged-out user. Walkthrough: Supabase RLS hardening for Lovable and Bolt.
"RLS enabled" but policy is using (true) (Supabase RLS docs, Palmer statement)	Same exposure as above, but the dashboard shows green. Supabase's docs warn that a policy of to anon using (true) gives every unauthenticated visitor read access to all rows. Palmer's statement says Lovable's scanner at the time "merely checks for the existence of any RLS policy."	Ongoing. This is a configuration pattern, not a bug that gets fixed upstream.	Read every policy, not just the toggle. Any policy that evaluates to true for anon on a table with user data is a leak. Replace with auth.uid() = user_id style checks.
Secrets pasted into client code (Lovable, June 2025)	Third-party keys shipped to the browser. Lovable's own post says it blocks "around 1200 private API keys" per day from being inserted into code, which tells you how often the model tries.	Partially mitigated by Lovable's key-blocking. Not a guarantee; keys with unusual formats get through.	Move every privileged call to an edge function or server route with the key in an environment variable. Audit with our exposed API keys guide.
Supabase Data API default change, 30 Oct 2026 (Supabase changelog)	Not a breach. New tables in the public schema are no longer automatically granted to anon, authenticated and service_role. Existing tables keep their grants. Apps that create tables without explicit GRANT statements get error 42501 "permission denied for table" from the Data API.	Default for new projects since 30 May 2026; applies to all existing projects from 30 Oct 2026.	Two jobs. For old tables: revoke the grants you never meant to give. For new ones: bundle GRANT with ENABLE ROW LEVEL SECURITY and policies in the same migration, as Supabase recommends. Grants and RLS are separate layers; you need both right.
Stale scan results (Lovable docs)	Scan findings are tied to a specific code version. Change the project after a scan and the old "no issues" result stays on screen with a clock icon.	By design.	Re-run the Deep scan after every change that touches tables, auth or payments, and before each real launch.

On the dispute. The CVE record carries a note that the issue "is disputed by the Supplier because each individual customer of the Lovable platform accepts a responsibility over protecting the data of their application." That is a fair description of how Supabase works: the anon key is designed to be public, and row-level policies are the customer's to write. Palmer's position is that a tool marketed to non-engineers should not ship defaults that produce "systemic data exposure," and that the scanner at the time only checked that some policy existed. Both can be true. Legally, the data is yours to protect. Practically, the AI wrote the policy, you clicked publish, and the 170 projects were real. Since then Lovable has shipped a publish-time scan, a Deep scan, auto-fix and a trust page, which is a real improvement. It has not changed who is accountable when a table is open: you.

Why Lovable apps leak data (it's usually RLS)

Most Lovable apps use Supabase, and Supabase exposes your Postgres tables over an HTTP API. The browser talks to that API directly with a public key. There is no backend in between to hide things. The only thing standing between a logged-out stranger and your users table is Row Level Security.

Supabase's docs put it plainly: "A table in an exposed schema without RLS is readable and writable by any role with a grant on it." Enable RLS and the API returns nothing until you write policies, which is the safe state. Then the AI writes the policies, and that is where it goes wrong, in three recurring ways.

1. RLS never enabled. The table was created in a hurry, the toggle is off, every row is public. This was the bulk of CVE-2025-48757.
2. RLS enabled, policy is a pass-through. using (true) for anon or authenticated. The dashboard looks protected. It is not. Supabase documents this exact footgun.
3. Read is scoped, write is not. A select policy checks auth.uid(), but the insert or update policy was never written, or was written open. This is how Palmer was able to set payment_status to paid without paying.

There is a fourth cause arriving on 30 October 2026, in the other direction. Supabase is turning off automatic grants for new public-schema tables. That is good for security and bad for anyone whose migrations assume a new table is reachable the moment it exists. If your Lovable app starts throwing 42501 errors after that date, this is why. The fix is the same discipline: every table gets an explicit grant, RLS on, and policies, in one migration.

The ten-minute test, no tools required: open your live app logged out, open the browser's network tab, copy the Supabase REST URL and anon key from any request, and call /rest/v1/<table>?select=* on each table you care about. If rows come back, you have a problem. If you want the full procedure with policy templates, it is in the RLS hardening guide.

Lovable security checklist before launch

Do these in order. Each one is a thing we have found missing on a real Lovable app that was about to take real users.

1. List every table. Supabase dashboard, Table Editor. Write the names down. You cannot secure what you have not enumerated, and Lovable creates tables you did not ask for.
2. Enable RLS on all of them. alter table public.<name> enable row level security; for each. Supabase's Security Advisor flags the ones you missed.
3. Read every policy as text. Not the toggle, the SQL. Anything that evaluates to true for anon on a table holding user data gets rewritten to auth.uid() = user_id or equivalent.
4. Check insert, update and delete separately. A scoped select policy does not protect writes. Each command needs its own policy.
5. Revoke what anon does not need. Per Supabase, on projects that still grant anon and authenticated by default, adding policies does not remove the grants. Revoke select on tables anon should never see.
6. Test logged out. The network-tab test above, on every table. Then test as user A trying to read user B's rows.
7. Move secrets server-side. Any third-party key the browser can see is public. Edge functions with environment variables. Rotate anything that ever shipped in a client bundle.
8. Lock down storage buckets. Same idea as tables: private by default, signed URLs for access, policies on the bucket.
9. Turn on leaked-password protection and rate limits in Supabase Auth. Lovable's Quick scan checks the first; the second is yours.
10. Run Lovable's Deep scan, then re-run it after you fix things, because results go stale. Treat "no issues found" as "the scanner found nothing," which is how Lovable's own docs phrase it.
11. Prepare for 30 Oct 2026. Add explicit GRANT statements to every migration that creates a table. Check the Data API exposure badge in Supabase's Table Editor.
12. Get a human to read it if the app touches money, health, or anyone's personal data. More on when below.

If you want to see what "production ready" means beyond security, the companion piece is is your Lovable app production ready.

What Lovable's security scan does and doesn't catch

Lovable now ships two scanners, documented at docs.lovable.dev. Here is what the docs actually say, with nothing added.

Quick scan (the June 2026 announcement calls it the basic scan). Runs automatically every time you publish, in about 10 to 15 seconds per Lovable's announcement. Checks database access rules and row-level security, leaked-password protection, known npm vulnerabilities, and MCP server exposure without authentication. Results are pass, warnings, or critical. Workspace admins can enable "Block publishing with critical issues"; new Enterprise workspaces start with it on. Both scans are free and do not use credits.

Deep scan. Does not run automatically; you start it from the Security view. Includes the Quick scan plus an AI review of application code for access control, unauthenticated or abusable endpoints, unsafe input and injection, leaked secrets, payments and billing, authentication, and exposed personal data. The docs say it usually takes 3 to 13 minutes. Enterprise admins can schedule it.

Auto-fix. Opt-in. Lovable's agent attempts "straightforward, low-risk findings" from the Quick scan during normal builds, making "only non-breaking changes." The docs are explicit that it "does not apply fixes for Deep scan findings." Fixes use your 10 free fixes per 24 hours, then credits.

Trust page. Published apps get /.well-known/trust.html, generated by Lovable, showing facts like HTTPS redirects, OSV dependency checks, an SBOM, and "record-level database protections are turned on." Lovable's own docs say it "is informational, not a certification," not an audit, and "not SOC 2, ISO 27001, a penetration test report, or a compliance attestation."

What it does not catch, in Lovable's words and ours:

• The Quick scan does not review application code at all. Input handling and authorization logic are out of scope until you run Deep.
• A policy that exists but is wrong. "RLS enabled" is a toggle check. Whether using (true) is appropriate for your orders table is a judgement the scanner does not make. This was the exact gap in 2025.
• Anything that changed after the last scan. Results are versioned and go stale.
• Business logic. Whether a user can skip a payment step, downgrade someone else's plan, or see a draft they should not. Lovable's docs: automated scans "cannot guarantee complete security."
• Your intent. The scanner cannot know that a table marked public was meant to be private.

Use the scanners. They are free and they catch the obvious things. Just read the disclaimer Lovable wrote on them, because it is accurate.

When to get a human audit

You do not need one for a landing page with a waitlist form. You do need one when any of these are true:

• The app stores anything a stranger would want: emails plus names, addresses, health or financial details, documents.
• Money moves through it. Stripe, subscriptions, credits, anything with a paid flag that a row-level policy protects.
• Users can see each other's data on purpose (teams, marketplaces, shared workspaces). Multi-tenant RLS is where AI-written policies fail most.
• You are about to put it in front of a customer who will ask for a security questionnaire, a pen test, or SOC 2 evidence. Lovable's trust page is not that, by its own description.
• You ran the logged-out test above and got rows back, and you are not sure you fixed all of it.

What we do: the Week-1 Build Audit is $500 flat. We read the schema, every policy, the edge functions, the auth config, the storage rules, and the client bundle for secrets, then hand you a scored fix list in priority order. If you then have us do the hardening, the $500 is credited 100% against that work. The Go-Live Intensive, from $14,000, is the version where we take the whole app from Lovable prototype to a hardened, monitored launch. Most Lovable apps do not need a rebuild. They need the data layer done properly once, which is a few days of someone who has done it before.

Already past the audit stage and just want it fixed? Start at fix my Lovable app. Short answers to the question you came in with are at is my Lovable app secure and, if you are shopping for help, Lovable to production agency.

Last thing. Lovable is a good tool. We use it. The people who get burned are not the ones who pick Lovable; they are the ones who assume the green scan badge means the same thing as someone having read the policies. It does not, and Lovable's own docs say it does not. Read the policies.