Lovable data exposure (Nov 2026): is your app one of them?

What was reported

A study by the security firm Crissy Field, published with the German business daily Handelsblatt, looked at 159,041 Lovable projects found in the public Common Crawl web archive. Coverage reports passport numbers, payment details and more than 200,000 private chat messages that could be read from a browser without logging in.

The counts depend on what was measured. One account names 7,403 sites with email addresses in 10,560 readable tables; another says 24,664 of 34,545 Supabase-backed apps returned database records without authentication. Either way, the cause was the same: database access rules, not a hack of Lovable or Supabase.

Why the built-in scan did not catch it

Lovable's security scan builds on the Supabase Security Advisor, which is good at one thing: telling you when a table has row level security switched off. It does not judge what a policy allows. A policy such as using (true) counts as "RLS on" and still opens the table to everyone with your public key, which every visitor has.

The other common gap is time: tables the AI adds after your first scan need their own policies, and nobody re-checks them.

Check your own app in 15 minutes

Run these on your own project only. All of them are read-only.

• Logged-out read test: request a table with only your public key (command below). Rows coming back means anyone can read that table.
• Tables without RLS: run the first query below in the Supabase SQL editor. Every name it returns is open.
• Policies that allow everyone: run the second query and look for qual or with_check equal to true, or policies for the anon or public role on private data.
• Storage: in Storage, any bucket marked Public serves its files to anyone who has the link.
• Keys: your website may contain the anon or publishable key, never the service role or sb_secret_ key. The free check at redproof.dev/check looks for it from your address alone.

# 1. Logged-out read test (your project URL and your public anon/publishable key)
curl "https://YOUR-PROJECT.supabase.co/rest/v1/profiles?select=*&limit=1" \
  -H "apikey: YOUR_PUBLIC_KEY"

-- 2. Tables in the public schema without row level security
select c.relname from pg_class c join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind = 'r' and not c.relrowsecurity;

-- 3. What every policy allows
select tablename, policyname, cmd, roles, qual, with_check
from pg_policies where schemaname = 'public' order by tablename;

If a table was open

Fix first, then find out what was seen.

• Turn on RLS and replace open policies with owner rules, for example using (auth.uid() = user_id), for select, update and delete
• If a service role or secret key was ever in the website, rotate it in Supabase and redeploy
• Look at the API logs in the Supabase dashboard for reads of that table from unknown sources
• If personal data of people in the EU or UK may have been read, data protection law may require you to notify the regulator within 72 hours and sometimes the people affected. Get advice for your case.

Fix prompt to paste into Lovable

Enable row level security on every table in the public schema. For each table that holds user data, add policies so users can only select, update and delete rows where user_id = auth.uid(), and only insert rows with their own user_id. Remove any policy that uses true for update or delete. Do not change the public key setup. Then list every table and its policies so I can check them.

Questions

Was Lovable hacked?

No. The reported data was readable because of how individual apps set up their Supabase access rules. Each app owner controls those rules.

Lovable's security scan says my app is fine. Am I safe?

Not necessarily. The scan mainly checks that RLS is switched on. A policy like using (true) passes it and still lets anyone read the table. Check what each policy allows.

Is it a problem that my anon key is visible in the browser?

No, it is designed to be public. It becomes a problem only when your policies let that key read or change data it should not.

How do I know if someone read my data?

Supabase keeps API logs in the dashboard. Look for reads of the affected tables that did not come from your app. On the free plan logs are kept only for a short time, so check soon.