Lovable app security: what the 24,664-site report proves
Lovable app security after the exposure report: why 30% is not a leak rate, how to test Supabase permissions, and when to harden or rebuild.
Lovable app security comes down to whether your database refuses the requests it should refuse, and you can test that. A Crissy Field report updating Handelsblatt's 2 November story found 24,664 Lovable-built sites returning Supabase records the moment a page loaded. Its authors say the 30% email figure is not a confirmed leak rate.
The report's counts, as of 15 November 2026, are below. The right-hand column is how we read each one.
| What was counted | Figure | How to read it |
|---|---|---|
| Lovable projects identified, December 2025 to September 2026 | 159,041 | The sample, not all Lovable apps |
| Projects using Supabase | 34,545 | The focus of the analysis |
| Sites sending database records on load, no login | 24,664 | What the researchers observed |
| Sites with email addresses in records (10,560 tables) | 7,403 | 30% of the 24,664; not a leak rate |
What the Lovable app security report proves, and what it does not
The 24,664 figure is an observation: those sites sent Supabase database records as soon as they loaded, with no login or other interaction. The report's examples include a German lifestyle forum with more than 80,000 profiles and more than 200,000 chat messages, and a service provider with more than 1,000 records holding identity document details, passport numbers among them.
The 30% is where coverage goes wrong. Email addresses appeared in 10,560 tables across 7,403 of the 24,664 sites, and the report says the figure "should therefore not be read as a confirmed data leak rate". Emails can be public contact addresses or test data, and records without an email address were missed. The authors say these effects partly offset each other but could not establish by how much.
Three more limits matter. The sample is not representative of all Lovable applications, only parts of the datasets were retrieved, and Lovable's own database offering was not examined. The report also does not name a specific Supabase setting as the cause, so the mechanics below are where to look, not the report's finding.
One number to leave alone: a claim that roughly 70% of Lovable apps ship with row level security disabled circulates in blog coverage. We could not trace it to a primary source, so we have not used it, and we would not quote it in a board paper.
Why a Supabase app can leak behind a login screen
Backend database rules decide what a request can reach, not the login page or the frontend filter. In Supabase those rules are row level security (RLS) policies plus table grants, and the Supabase documentation and Wavect's remediation guide list the ways they fail:
- No RLS. Supabase says a table in an exposed schema without RLS is readable and writable by any role with a grant on it.
- RLS on, no policies. Then no data is accessible through the API with a publishable key until you create policies. That is the safe state, and a broad allow-all policy added to get screens working undoes it.
- Grants outlive policies. On existing projects, a new table in
publicstarts with every privilege already granted to the three API roles, and adding policies does not remove them. Wavect adds that the new-table default does not revoke grants on old tables, so one fixed table proves nothing about an older one. - Permissive policies combine with OR. Adding a narrow owner policy beside a surviving allow-all policy does not narrow the result.
- Columns and functions. RLS does not restrict columns within a permitted row, and a
security definerfunction runs with its owner's privileges, so test what its caller gets back.
The report adds a governance point: Lovable's Terms and Conditions place responsibility for applications and data handling on the customers themselves. Whoever shipped the prototype owns the permissions model. If non-engineers are shipping apps in your company, our post on citizen developer governance covers who should review them.
How to test Lovable app security with three identities
The method below follows Wavect's guide to proving a permissions fix. It needs no scanner, but it does need someone who can read the policies.
- Write down the intended permissions for each caller: signed out, user A, user B and any backend task.
- Seed synthetic records with clearly different values for A and B. Keep one permitted read that proves the record and route work, a positive control, so an empty result cannot pass as a denial.
- Run allowed and forbidden reads and writes as each identity, covering views, storage, edge functions and exports, not only tables. After a rejected write, check the original row is unchanged.
- Repeat against the deployed app with real identities, not just a local policy regression.
- Record the evidence: deployment revision, migration, responses, row counts and before and after state.
Close the finding only when the deployed allow and deny cases pass and permitted workflows still work. Wavect is explicit that a local test, a screenshot showing RLS enabled or a clean scan does not establish this alone, and the Crissy Field authors say automated checks are no substitute for a professional security assessment.
Harden or rebuild: what decides it
The strongest case for hardening is real. The policies for a simple app are a few SQL statements, the product has already been validated with users, and a rebuild throws away working screens. If your data is per-user rows behind one role, nothing regulated sits in it and the three-identity test passes, harden it and move on.
The case for rebuilding rests on what the app holds and how it is likely to grow. The report's own recommendation is that before an application handles real customer or business data, its access permissions, interfaces and separation between user accounts should be reviewed. When that review shows the logic cannot be tested, rebuild.
| Your situation | Harden | Rebuild |
|---|---|---|
| Data model | One table per user, one role | Multiple tenants, roles or approval flows |
| Data held | Low sensitivity, public-by-design content | Identity documents, contracts, invoices, chat history |
| Testability | Policies readable; three-identity test passes | Access rules scattered through generated frontend code |
| Next 6 months | Still validating the idea | ERP, payment or partner integrations planned |
Say it plainly: an MVP rebuild is the wrong choice if the problem is a missing policy on two tables. Hardening is the wrong choice if you cannot say who is allowed to read each row. For budgeting a rebuild, our breakdown of the four decisions that move app cost shows what to settle first.
Scoping a Lovable app that now holds real customer data
If your prototype has real users and you cannot yet answer the three-identity test, the next step is deciding what to keep. Our MVP development team can scope a production rebuild against the product behaviour you have already validated, or tell you plainly that hardening is enough. Bring the intended permissions per caller; that one page decides most of the answer.
Frequently asked questions
A Lovable app is as safe as the permissions on its backend database. The Crissy Field report found 24,664 Lovable-built sites returning Supabase records on page load, though it calls its 30% email figure unconfirmed. Review access permissions and user separation before the app handles real customer data.
Test with three identities: signed out, user A and user B. Seed synthetic records, keep one permitted read as a positive control, and confirm rejected writes leave rows unchanged. Repeat it against the deployed app, because a local test or an enabled-RLS screenshot alone does not close the finding.
Not by itself. Supabase says RLS with no policies blocks API access, but policies combine with OR, grants on older tables persist, and column and function privileges sit outside row rules. An allow-all policy beside a narrow owner policy still returns every row, so test the deployed behaviour.
Crissy Field analysed 159,041 Lovable projects, 34,545 of them on Supabase, and found 24,664 sites sending database records on load without a login. Email addresses appeared in 7,403 of those sites. The authors say 30% is not a confirmed leak rate and the sample is not representative.
Harden it when the data is low sensitivity, the model is simple and the three-identity test passes. Rebuild when you hold identity documents or contracts, need multiple tenants or roles, or cannot read the access rules out of the generated code. The deciding question is who may read each row.
