A security study of apps made with Lovable found cases where database records could be read without signing in. The numbers are large, and the examples include personal and business information. But the headline figure is easy to misread: Crissy Field did not establish that 30% of all Lovable apps leaked data, nor did it report a compromise of Lovable's own systems. Its findings concern a non-representative sample of customer-built apps that used Supabase.
What did the researchers count?
Crissy Field says it identified 159,041 Lovable projects in Common Crawl snapshots collected from December 2025 through September 2026. It found Supabase in 34,545 projects. Of those, 24,664 sites sent database records when a page loaded without a login. That first observation was not itself treated as a vulnerability: some apps intentionally display public data.
The researchers then made additional read-only requests using the same API key the site used. In 7,403 of the 24,664 sites, they found at least one database table with records containing email addresses. The report counts 10,560 such tables. The 30% is the fraction of this closer-inspected subset, not of all 159,041 projects and not a measured share of every Lovable app. Crissy Field also says an email address can be a public contact or test value, while records without email addresses would be missed. It therefore calls the figure an indicator, not a confirmed leak rate.
What kinds of information were accessible?
The report gives examples to show why database permissions matter. One German lifestyle forum exposed more than 80,000 profiles with names, email addresses, birth dates and gender information, along with more than 200,000 chat messages. Several event and restaurant sites exposed sales records that included contact details, payment information and ticket codes. A property manager's database included AI-generated summaries of internal email, and one service provider had more than 1,000 identity-document records containing details such as passport numbers and expiry dates.
Other examples included contracts, invoices, photo albums, internal WhatsApp communications, support requests and a large set of customer emails. These are examples from datasets the researchers inspected, not evidence that every app in the sample held such information. Crissy Field says it downloaded only portions of the available data, did not determine whether anyone misused it, and is withholding access details that could make further reads easier.
What does the study not show?
The sample came from Common Crawl, an archive of public web pages, so it cannot represent all projects created on Lovable. The study focused on Supabase because the researchers considered that integration common and relatively straightforward to examine. It did not test Lovable's own database product, and the authors say comparable problems there are possible but outside this analysis. The report is about app-level access-control settings, not an intrusion into Lovable's platform.
There is also a timing limit. The projects were observed across a December 2025 to September 2026 archive window. The report does not tell a reader whether a particular app remains exposed today, whether its owner was notified, or whether a fix has been deployed. The data cannot identify the risk of an individual site. Handelsblatt reported on the joint investigation on November 2; Crissy Field's current page notes that it contains later analysis and updated figures. The report says the newspaper contacted Lovable, but the research page does not include the company's full response.
This is a different kind of finding from a breach of a software vendor. VIBPS's recent account of Cursor's extension incident follows an intrusion into Cursor's systems and a malicious package served by its marketplace; the Lovable study instead tested access rules in customer-built apps. The distinction affects who needs to investigate: app owners should review their own database permissions, while a platform incident requires the vendor's incident guidance.
What did the Cursor extension incident expose?
Why can a public API key still be safe?
Supabase's publishable key is designed to appear in a browser app. Seeing that key is not, by itself, proof that a database is open. Row Level Security (RLS) and its policies decide which rows the database returns to a given user. A public app may intentionally serve a small set of records to everyone; private customer or staff data needs policies that restrict reads and writes to the right people. The study's concern is that additional requests could retrieve records beyond what a page initially displayed.
For a maker using Lovable with Supabase, the useful response is to review the live database rules rather than infer safety from the generated UI or from whether a key is visible. Check which tables contain real personal or business data, confirm RLS is enabled, and test permissions while signed out and with separate user accounts. Lovable documents automated security checks, but Crissy Field cautions that automated scans do not replace a qualified review before sensitive data is used. If a project could match a finding, investigate its current configuration and contact the relevant service provider; the study does not say that every Lovable project is affected.
The wider lesson is not that AI-generated apps are automatically unsafe. It is that a working app can still have a database policy that is too broad. A builder can generate the interface and connect a database, but access decisions still need to match the data and the people who should see it.
Crissy Field's research report, including its sample, findings and limitations
Handelsblatt's November 2 report on the joint investigation (German)
Supabase documentation: Row Level Security
How to protect an app while an AI coding agent works
VIBPS is the social network for software, where makers can publish what they build and find an audience for their work. Access control is one of the checks that should be part of turning a prototype into a product people can trust.