What happened
Crissy Field, a Hamburg security firm, worked with the German business daily Handelsblatt to examine apps built with Lovable, an AI coding platform. The supplied report says the researchers extracted 159,041 Lovable projects from the Common Crawl web archive. The projects covered apps built between December 2025 and September 2026. They tested whether databases would return records to someone with no credentials.
Of those projects, 34,545 used Supabase as a backend. In 24,664 of those, the researchers say, database records were returned with no authentication required. Email addresses were readable on 7,403 sites, across more than 10,500 tables. The report describes one service provider’s database as exposing more than 1,000 passport records, including expiration dates and nationalities. It also cites a Lovable-built lifestyle forum whose database exposed more than 200,000 chat messages and 80,000 user profiles.
The article gives other examples of exposed material, including ticket bookings and restaurant orders containing home addresses and payment information, as well as business records such as contracts, invoices and WhatsApp logs. One CRM-style project reportedly exposed more than 280,000 customer emails, waiting-list entries and support tickets. These are examples in the report, not a complete inventory of all affected data or a verified count of people harmed.
The article explains that Supabase offers Row Level Security (RLS), intended to limit which rows a user can see in a shared table. RLS must be enabled and configured to provide that protection. It says Supabase’s public “anon” key can have broad read access unless restricted. The report frames the issue as a combination of applications shipped without adequate access controls and defaults that make it possible for an unauthenticated request to retrieve data. It also says Lovable had added an automated Security Scanner and an AI-driven Security Reviewer after a separate flaw, CVE-2025-48757; the scan found apps built after those tools existed.
What the archive adds
This is a new investigation that adds scale and a different product context to earlier reporting on exposed app data. A prior Field Note, A coffee chain's vibe-coded dashboard leaked data on 132 locations, documented a login screen that did not prevent sensitive data from being sent to an unauthenticated browser. A later Bootlegger follow-up reported the CEO’s confirmation that the legacy dashboard lacked effective login protection. The Lovable scan is a new event, not a restatement of those cases.
Trend signal
This supports the pattern that agent security moves to runtime boundaries: security depends on what an application actually permits at its data boundary, not on the prompt or the apparent presence of a login screen. The findings also reinforce a practical distinction for AI-built products: generated code and security-review features do not establish that deployed access controls work. The scan is evidence about the examined apps, not a universal measurement of all AI coding platforms.
Why now
The scan covers apps built from December 2025 through September 2026, and the report says the relevant Lovable security tools had already been introduced following an earlier flaw. That timing makes the central question whether the available checks meaningfully prevent unsafe deployments, rather than whether teams have been warned that database security matters.
Connections to other events
The earlier Telegram coverage of Bootlegger described a dashboard where a visible login screen did not keep data from unauthenticated visitors. This Lovable investigation reports the same basic boundary failure across a much larger set of independently built applications, with examples extending to passports, messages and customer records. Both cases show why teams must test what a browser or API can retrieve without credentials.
Why it matters
AI coding tools can make it much faster for a non-specialist to create and publish an application, but they do not remove the need to decide who can read each record. In the reported Supabase projects, a database that returned data without authentication could expose information belonging to app users, not just the builder. A generated interface may look finished while its backend remains broadly readable.
For teams, the useful lesson is to treat access control as a release condition, not a prompt-quality aspiration or a warning in a scanner. Test deployed endpoints from an unauthenticated session, verify that row-level policies are enabled and scoped to the intended user, and check that public keys cannot retrieve private records. The report does not establish that every Lovable app is unsafe; it does show that a large number of examined projects reportedly failed a basic unauthenticated-access test.
Limits and uncertainty
The supplied source is a secondary report describing Crissy Field’s work with Handelsblatt; it does not include the underlying scan dataset, methodology details, affected app list or independent reproduction of the findings. Its counts concern projects and sites examined, not confirmed victims or confirmed misuse of exposed records. The report does not establish whether the identified exposures remain live, whether the app owners or users were notified, or what remediation followed. It also does not show that Lovable alone caused each misconfiguration, or provide comparative rates for apps built with other tools. The findings support concern about access-control failures in the scanned sample, not a claim that all Lovable-built software is vulnerable.
Skill to build now
Before shipping an AI-generated app, run an unauthenticated access test against its deployed backend: with a clean browser session and no app login, try the same public-facing data requests and confirm they cannot return private rows. Then verify that Supabase RLS is enabled and that policies scope reads to the intended user. Treat any returned personal or business record as a release blocker, even if the app’s visible pages show a login screen.
Reader takeaway
A generated app is not secure because it works, and a login screen is not proof that its data is private. Verify the deployed data boundary directly: test what an unauthenticated visitor can read, and make access-control checks part of release approval.