7,403 Lovable apps, one missing line of SQL

A German security firm called Crissy Field went through 159,041 apps built with Lovable and found that a lot of them hand their database to anyone who asks. Passport numbers, ticket sales with payment details, 200,000 chat messages from a forum, all readable without logging in. Handelsblatt broke it on 2 November, and Crissy Field put out its own report with newer numbers. That report is what I'm going from here.

I've read a version of this story before, which is the annoying part.

What they found

They pulled Lovable projects from Common Crawl, built between December 2025 and September 2026. 34,545 of them used Supabase as the database. Of those, 24,664 sent database rows as soon as the page loaded, with no login.

That on its own is fine. A menu or a list of events is meant to be public. So they made a few more read-only requests with the same key the page was already using, and found tables with email addresses in them on 7,403 sites. That's 30% of the ones they looked at closely.

They're careful about that number, and I'll be too. Some of those emails will be public contact addresses or test data, and plenty of personal data has no email column at all, so it misses some too. The sample also isn't all of Lovable. But the examples they list don't need a statistic:

• A German lifestyle forum with more than 80,000 profiles (names, emails, dates of birth) and over 200,000 chat messages.
• Event organisers and restaurants with tens of thousands of ticket and food orders, including phone numbers, addresses, payment information and ticket codes.
• A service provider with more than 1,000 identity document records: passport numbers, expiry dates, nationalities.
• A property manager exposing AI-written summaries of internal emails about tenants and owners.

They don't know if anyone misused any of it. Lovable told Handelsblatt the problem is industry-wide.

Why this keeps happening

A Lovable app is mostly a frontend. The browser talks straight to Supabase using what's called the anon key. That key is meant to be public, it's sitting in the JavaScript bundle for anyone to read, and that's fine by design. What stops a stranger with that key from reading your users table is Row Level Security, RLS: Postgres rules on each table that say which rows each role can see.

Supabase's docs are blunt about what happens without it: "A table in an exposed schema without RLS is readable and writable by any role with a grant on it." And on a lot of projects the anon role gets every privilege on new tables by default, so "any role" includes someone who isn't logged in.

So the app can look perfect. The login screen works, the dashboard only shows you your own stuff. But that filtering is happening in the frontend. Copy the request out of the network tab, drop the filter, and the database sends back everything.

This exact thing was reported in March 2025. Matt Palmer and Kody Low scanned 1,645 sites from Lovable's own showcase and found 170 with tables open to anyone. That became CVE-2025-48757. Lovable added a security scanner afterwards, and Palmer's complaint at the time was that it checked whether a policy existed, not whether it was right. Crissy Field's sample starts eight months after that, so whatever the tooling does now, it isn't catching enough.

The responsibility gap

Crissy Field makes a point I agree with. Lovable's marketing says you don't need technical knowledge to build an app. Its terms say you're responsible for your app and your data. Both of those can be true on paper, but the person who needed no technical knowledge to build it is the same person who now has to understand Postgres grants to secure it.

"It's industry-wide" is also true, and it doesn't help much. Misconfigured access control is the oldest bug there is, humans write it all the time. What's different is that when a tool generates thousands of apps the same way, they break the same way, and one script can check all of them.

If you've shipped something on Supabase

This isn't just a Lovable thing. If your frontend talks to Supabase directly, check these:

• RLS on every table in the public schema. The dashboard flags tables without it. Don't ignore the warning because the app "works".
• Revoke the default grants, then add back what you need. Supabase's own guide now says to revoke all from anon and authenticated and grant only what each role should do. A policy alone still leaves an insert path if the grant is there.
• Watch out for using (true). A policy that allows everything is still technically a policy, which is why "has a policy" is a bad security check.
• Test as a stranger. Open the site logged out, copy one Supabase request from the network tab as curl, and change the query to select=*. If more comes back than the page shows, you have the bug. Only do this on your own apps.
• Keep the sensitive stuff off the client path. Passport numbers don't need to be one query away from the browser. Put them behind a server function that checks who's asking.

For what it's worth, my own projects don't let the browser talk to the database at all. They go through a server with its own Postgres role that only has the grants it needs. That's more setup than Lovable asks of anyone, and it's a big part of why I'd still want someone who knows databases to look over an app before it holds anyone's passport number.

First published on my blog. Cover photo: Watty62, CC BY-SA 4.0, via Wikimedia Commons (source).