159,041 Lovable projects analyzed: what the Crissy Field study really shows

Crissy Field, a German security firm, analyzed 159,041 Lovable projects published between December 2025 and September 2026, in partnership with Handelsblatt. In part of them, personal data could be read without logging in. The cause is not a platform flaw: it is a missing access rule in the database.

What the study measured

• 34,545 projects use Supabase as their database.
• 24,664 websites send database records as soon as the page loads, with no login.
• Email addresses were found in 10,560 tables, across 7,403 of these websites (30%).
• Serious cases include a forum with more than 80,000 profiles and more than 200,000 chat messages, a provider with more than 1,000 passport records, and event organizers and restaurants exposing addresses, phone numbers and payment information.

The authors state that the 30% figure is not a confirmed leak rate: an email address can be a public contact or test data. The sample is not representative of all Lovable applications, and Lovable's built-in database (Lovable Cloud) was not examined.

The cause: a missing access rule

A Supabase application uses a public key that is visible in the browser. That is expected. What protects the data are the access rules defined table by table (RLS, Row Level Security). If a table has none, or if a rule lets everyone read, anyone with the public key can read it.

What Lovable's scan covers, and what it does not

Lovable runs a free security scan on every publish. It flags tables without RLS and rules that let everyone through, including on a connected Supabase project. It is a useful first barrier: never publish while ignoring its warnings.

This scan analyzes code and configuration. It does not test the running application. It can confirm that RLS is enabled without telling you whether a signed-in customer can read another customer's orders. Lovable says so itself: these scans do not replace a security review.

5 checks before real customer data goes live

• RLS is enabled on every table, with no exception.
• No table holding personal data can be read by a visitor who is not signed in.
• Forms: a visitor can submit, only the administrator can read.
• Each user only sees their own rows: account A never reads account B's data.
• The admin key (service_role) never appears in the code sent to the browser.

Run these checks again after every significant change to the application.

Karim's take

Lovable saves weeks of build time. It does not replace checking who can read what. On the applications I build, this check is part of the delivery, not an option. This site applies exactly these rules: your quote requests can only be read by me.