Lovable app audit retrieves email records from 7,403 sites without login

An investigation of apps made with Lovable, a service that lets people build software with natural-language instructions, found thousands of websites with database records accessible without logging in. German security company Crissy Field examined 159,041 projects drawn from Common Crawl archives covering December 2025 through September 2026. The investigation, conducted with Handelsblatt, identifies an access-control problem in user-created applications: a generated interface can appear complete while its database permits visitors to retrieve private records.[1]

The researchers identified 34,545 projects using Supabase, a widely used hosted database. Of those, 24,664 websites supplied some Supabase records immediately when the page loaded. That alone was not evidence of a breach: a public product catalogue or list of event dates may be intended for every visitor. Crissy Field then made limited read-only requests using the same credentials already provided to the browser. It found records containing email addresses in 10,560 tables across 7,403 sites. This second step is where the access-control question became material.[1]

How the 30% figure was calculated

Crissy Field reports 7,403 divided by 24,664—about 30%—as the proportion of its more closely examined sites in which it could retrieve email-containing records. That is neither 30% of all 159,041 projects nor a confirmed percentage of Lovable applications leaking sensitive data. Some emails may have been deliberately public or belonged to testing environments. Other sensitive records contain no email at all, so the method could miss them. The researchers explicitly caution that the Common Crawl sample is not representative of the platform's overall project population.[1]

The clearest cases went beyond ambiguous contact addresses. Crissy Field describes a lifestyle forum with more than 80,000 profiles and over 200,000 messages accessible; event and food-ordering databases with contact and payment-related information; and a service provider with more than 1,000 records containing identity-document details, including passport numbers. It also found internal correspondence and customer communications. The researchers did not establish whether the exposed information had been misused, and did not publish the affected sites’ names.[1]

Why a public key can coexist with private data

Some browser-based apps legitimately include a public, or anonymous, Supabase key. That key identifies the application but is not meant to confer permission to read every row in its database. The critical control is usually row-level security: rules that decide which records a particular user or anonymous visitor may see. When those rules are absent or too broad, the browser can ask for data well beyond the page's intended display. The problem is therefore not that an app has a database or that its JavaScript contains an anonymous key. It is that the backend authorises requests it should reject.[1]

Lovable told Handelsblatt that the problem extends across the industry. Crissy Field likewise notes that access-control mistakes occur in human-written applications as well as AI-built ones, while arguing that repeated integration patterns can make similar flaws easier to find across many apps. A generated login screen does not establish that the database rejects an unrelated visitor’s request. The relevant check is the permission enforced on the record, not simply whether the interface asks someone to sign in.[1][3]

Lovable’s April disclosure concerned a separate incident. The company said a regression had allowed authenticated Lovable users to access chat histories and source code for some public projects, and that it fixed the issue after disclosure. The November investigation instead examines database permissions in apps created by users, particularly those integrating Supabase. Platform settings, developer choices and deployment checks may all affect that exposure, but the two reports do not describe a single continuing vulnerability.[1][2]

For owners of affected apps, the repair starts with checking the permissions around the data itself. Testing should cover anonymous access and whether one signed-in user can read another user’s records, with the owner’s authorisation and within the application’s scope. Those checks need repeating after database or workflow changes. The study’s concrete contribution is showing how often email-containing records were reachable in its sample, and documenting cases where the accessible material was plainly more sensitive than a public contact address.[1]

Report an error or suggest a correction