7,403 Lovable apps left customer data readable without a login
Researchers checked 159,041 Lovable projects and pulled email addresses, passport numbers, payment details and chat messages out of 7,403 of them, no login needed. The cause: Supabase tables anyone can read.
What happened
On 2 November 2026, German security firm Crissy Field published research, first reported by Handelsblatt, on 159,041 public Lovable projects collected from Common Crawl between December 2025 and September 2026.
34,545 of those projects used Supabase. 24,664 sent database records to the browser as soon as the page loaded. With further read-only requests using the same public key the app ships to every visitor, the researchers found records with email addresses in 10,560 tables across 7,403 sites: 30% of the sites they looked at closely.
What was readable included more than 80,000 forum profiles and 200,000 chat messages, tens of thousands of ticket and food orders with phone numbers, addresses and payment information, more than 1,000 passport records, contracts, invoices, photo albums, and AI summaries of a property manager's internal email.
Nobody broke into Lovable or Supabase. Each app's database rules let anyone with the public key read the tables. Lovable told Handelsblatt the problem is industry-wide, and its terms make customers responsible for their apps and data.
Who is affected
- Any Lovable app with a Supabase backend where a table has Row Level Security off, or a policy that lets anyone read it.
- The same mistake shows up in apps from Bolt, v0, Cursor and hand-written code: the public anon key is meant to be public, so the table rules are the only thing standing between a stranger and your data.
- The researchers didn't check Lovable Cloud's built-in database and say similar mistakes may exist there.
How to check
- Open your live app in a private window, signed out. In DevTools, Network tab, filter for rest/v1 and look at what comes back: any row with someone else's email, phone or address is a leak.
- In Supabase, open Advisors > Security Advisor. Any table listed as "RLS disabled in public" is readable by anyone with your app's key.
- Or scan the published URL with Shippable: it uses the same public key a visitor gets, tries to read each table, and names the tables and columns (like email) it could read as proof.
How to recover
- Turn on Row Level Security for every table in the public schema, then add policies so people only read their own rows (auth.uid() = user_id). In Lovable, ask: "Enable Row Level Security on every table and add policies so users can only read and edit their own rows. Keep anything meant to be public read-only."
- For data that really is public (a product list, published posts), allow read only and keep personal columns like email out of that table or behind a view.
- Re-scan, signed out, to confirm the tables now return nothing.
- If customers' personal data was readable, treat it as a breach: check the Supabase API logs for reads you don't recognise. In the EU, you may have to report it to your data protection authority within 72 hours.
Check your app
Free and read-only. Before you push, run npx shippable-dev scan localhost:3000 in your project folder, no account needed. For your live app, you prove it's yours with a one-line tag first.