Lovable Data Leak Study: 24,664 Apps Sent Records Without a Login

What the Study Found

Crissy Field pulled 159,041 Lovable projects from Common Crawl, a public archive of crawled web pages, covering December 2025 to September 2026. 34,545 of them used Supabase as their database. Of those, 24,664 websites sent Supabase records as soon as the page loaded, with no login and no clicks. The team then made further read-only requests with the same API key and found records containing email addresses in 10,560 tables across 7,403 of those sites, or 30%.

The firm says it only retrieved partial slices of the data and did not download it in full. What it saw:

Sources: Crissy Field's report and the Handelsblatt article by Lina Knees. The report says it holds newer figures than the newspaper piece, so the numbers here come from the report.

What the Numbers Do Not Prove

The report is careful about its own limits, and you should be too before quoting it:

• 30% is not a leak rate. Crissy Field says the figure is not a confirmed data leak rate. An email address in a table can be a public contact address or test data, and records with no email address are not counted at all.
• The sample is not all of Lovable. Common Crawl only holds sites that were crawled, and the report says its sample does not represent all Lovable apps.
• Nobody knows yet if the data was misused. The report says it could not establish whether any of it had been.
• Lovable's own database features were not tested. The study looked only at the Supabase integration.

The report does not name the affected sites and does not publish how to access them. Handelsblatt contacted Lovable with the findings; the report does not quote a reply.

Why This Keeps Happening

Supabase lets a web app read its database straight from the visitor's browser, using a publishable key (older projects call it the anon key). Supabase's API keys docs say this key is safe to put in a web page, because it can only reach what Row Level Security allows. That is the whole deal: the key is public, and RLS is the lock.

When the lock is missing, Supabase's RLS guide says any role with a grant on the table can read it and write to it. Three details make that easy to hit in an AI-built app:

• Where the table was created matters. Supabase's API security guide says tables created through the Supabase Dashboard have RLS on by default, but tables created in the SQL Editor or through another tool need it turned on explicitly.
• Views skip RLS. The RLS guide says views bypass RLS by default unless they are created with security_invoker = true (Postgres 15 and later).
• Supabase's newer default only covers new tables. A breaking change stops new tables in the public schema from being exposed to the Data API automatically. Supabase scheduled it for all existing projects on 30 October 2026, but the changelog says existing tables are not affected. A table made before that keeps its old access. If new tables now fail with a 42501 error, see the two Supabase changes of late 2026.

None of this is new. CVE-2025-48757, published in May 2025, describes insufficient RLS policies in Lovable-generated sites that let unauthenticated attackers read or write database tables. It is rated 9.3 (critical), and Lovable disputes it on the grounds that each customer is responsible for protecting their app's data. Lovable's own Supabase docs put it plainly: "Missing RLS policies are the most common way app data gets exposed."

Check Your Own App

Do these steps on your own project only.

1. Run Supabase's Security Advisor. In the Supabase dashboard, open Advisors, then Security. The advisor docs list 0013_rls_disabled_in_public as an error: without RLS, anyone with your project URL can read, edit and delete everything in that table. Also look for 0010_security_definer_view (a view that bypasses RLS) and 0007_policy_exists_rls_disabled (you wrote a policy but RLS is off, so it does nothing).
2. Try to read your tables as a stranger. Copy the publishable key from Settings, then API Keys, in your Supabase dashboard, and request a table with no login, the way Supabase's API quickstart does:

   # Run this against YOUR project, with no user session.
   curl 'https://<PROJECT_REF>.supabase.co/rest/v1/<table>?select=*' \
     -H "apikey: <PUBLISHABLE_KEY>"

   <PROJECT_REF> is the part before .supabase.co in your project URL. No terminal? The quickstart also accepts the key in the address, so you can open this in a private browser window instead:

   https://<PROJECT_REF>.supabase.co/rest/v1/<table>?apikey=<PUBLISHABLE_KEY>

   If you get back rows that should be private, so can anyone who opens your site. Repeat for every table that holds user data.
3. Run Lovable's scan before you publish. Lovable's security docs say a Quick scan runs automatically when you open the publish dialog, and that its database review covers tables without row-level security. The Deep scan does not run on its own. Lovable also says these tools cannot promise complete security, and that you are responsible for your app meeting its security requirements.

How to Fix It

Here is the pattern that ends up exposed. The table holds personal data, it was created with SQL, and RLS was never switched on:

-- Bad: created in the SQL Editor, RLS never enabled
create table public.bookings (
  id bigint generated always as identity primary key,
  user_id uuid not null references auth.users,
  passport_number text,
  created_at timestamptz default now()
);

Turn RLS on, then add a policy for each thing users are allowed to do. Supabase says that once RLS is on, the publishable key reads nothing until you add policies, so your app may stop showing data until the policies exist. That is expected.

-- Fixed: RLS on, and each user only sees and creates their own rows
alter table public.bookings enable row level security;

create policy "Users read their own bookings"
on public.bookings for select
to authenticated
using ( (select auth.uid()) = user_id );

create policy "Users create their own bookings"
on public.bookings for insert
to authenticated
with check ( (select auth.uid()) = user_id );

Then close the other doors:

• Keep the secret key on the server. Supabase says a secret key (or the legacy service_role key) bypasses all of your RLS policies. It must never be in front-end code or in a variable your front end can read.
• Remove grants you do not need. If anonymous visitors never need a table, the RLS guide shows how to revoke access entirely (below), then grant back only what the app uses.
• Re-run the advisor after every schema change, including the ones your AI tool makes for you.

-- No access through the Data API for visitors or signed-in users
revoke all on table public.bookings from anon, authenticated;

VibeDoctor's Vibe Check does not log in to your database, so it cannot read your RLS policies; the Security Advisor is the tool for that. What it does scan is your repository: if your Lovable project is synced to GitHub, it flags committed secrets, including a .env file holding a Supabase service_role key, with the file path and line number. Free to sign up.

For a longer walkthrough of policies, see Supabase Row Level Security in vibe-coded apps. For Lovable's earlier platform-side incident, see the Lovable BOLA breach.

FAQ