German security firm Crissy Field found that 24,664 apps built with the AI coding platform Lovable returned database records to anyone who asked, with no authentication. The exposed data includes passport records, payment details and more than 200,000 chat messages.
Crissy Field Scanned 159,041 Lovable Projects
The researchers pulled 159,041 Lovable projects from the Common Crawl archive. Of those, 34,545 used Supabase databases. Crissy Field found that 24,664 of the Supabase-backed projects returned database records without authentication, using only the key that the page gives every browser. The researchers made read-only requests.
Readable emails turned up on 7,403 sites across more than 10,500 tables. The firm’s central finding is that the apps hand out access through a key that every visitor receives, and that the database permissions behind that key were not set to restrict what it could read.
Passports From One Provider’s Database
One provider’s database held more than 1,000 passport records, including expiry dates and nationalities. Passport data is among the most sensitive categories an app can hold, and it was readable by any visitor who knew how to send the request.
Orders, Tickets, Chats and Contracts Also Exposed
Event and restaurant apps exposed tens of thousands of orders and tickets. Those records contained emails, phone numbers, addresses, payment information and ticket codes. A lifestyle forum leaked more than 200,000 chat messages and 80,000 user profiles.
Contracts, Invoices and WhatsApp Messages in Lovable Databases
Other data found in the exposed databases included contracts, invoices, photo albums and internal WhatsApp messages. The variety shows that the problem was not limited to one app type or industry. Any app that stored records in an unprotected Supabase table was affected, whether it handled restaurant bookings or private conversations.
Why Unprotected Browser Keys Expose Entire Tables
Supabase gives front-end code a key that runs in the browser, and the security of the data depends on rules set in the database, commonly called row-level access policies. When those rules are missing or too permissive, anyone holding the browser key can read the tables. Crissy Field’s results indicate that tens of thousands of projects lacked adequate rules. The firm’s conclusion is that easy app building does not replace expert review of access permissions.
The scanning method also deserves attention. Because the researchers drew projects from a public web archive and used only the key that each page serves to every visitor, the same approach is available to anyone. Attackers do not need special access, and the data can be collected by automated tools at the scale Crissy Field describes. The firm made only read-only requests, but others might not.
The scale of the exposure is partly a product of how many projects exist. Lovable lets users create apps without writing code, and the 159,041 projects in the sample show how many have been published. The sources do not say what share of all Lovable apps the sample represents, so the 24,664 figure applies to the projects scanned, not to the platform overall.
The people harmed are not the app builders alone. Customers who bought tickets, booked tables or joined a forum had no way to know whether the builder had configured database permissions. Passport holders in the provider’s database fall into the same position.
What Crissy Field Recommends and What Is Still Missing
The researchers recommend a review of access permissions on these apps. The source article does not include a statement from Lovable, so the platform’s position and any plan to change defaults or notify affected builders is unknown.
For app owners who built on Lovable and Supabase, the finding gives a concrete check: confirm that every table that holds personal or payment data has access rules that block unauthenticated reads. Users of such apps have no direct way to test this, so the burden falls on the builders and the platform.
