Lovable-Built Apps Left Data Open: What to Do Now

On 2 November 2026 Handelsblatt reported research by German security firm Crissy Field GmbH saying many apps built with the AI app-maker Lovable let anyone read sensitive data without logging in. Crissy Field examined 159,041 Lovable projects (December 2025 to September 2026). On 7,403 of 24,664 websites it looked at closely, it found database tables containing email addresses. The cases it lists include passport details, payment information and more than 200,000 chat messages. Crissy Field says the 30% figure is not a confirmed leak rate. If you or your team ship apps made with an AI builder, test them logged out today.

Who this is for: security leaders, engineering managers and founders whose teams (or business units) build apps with AI app-makers, and anyone who has to answer "who is responsible if this leaks?"

Independent analysis based on Crissy Field's English research report, which we read on 3 November 2026. We did not read the Handelsblatt article itself. PlayCISO is not affiliated with Crissy Field, Handelsblatt or Lovable. Crissy Field also sells application-security services, which its report invites readers to contact it about. Facts are as reported and may change.

What Crissy Field says it found

Crissy Field focused on Supabase, the database service it believes is the most widely used among Lovable projects. Using Common Crawl web-archive data it identified 159,041 Lovable projects, of which 34,545 used Supabase. Of those, 24,664 websites sent Supabase database records as soon as they loaded, with no login. Crissy Field notes that alone "is not a security issue: the data may be intended for public display". By making additional read-only requests with the same API key, it retrieved more content, finding email-address records in 10,560 tables across 7,403 of the 24,664 websites (30%).

The cases it lists (it does not name the organisations, and does not publish how to reach the data):

• A German lifestyle forum exposed more than 80,000 profiles with full names, email addresses, dates of birth and gender, and more than 200,000 chat messages.
• Several event organisers and restaurants exposed tens of thousands of ticket and food-sales records, including email addresses, phone numbers, postal addresses, payment information and ticket codes.
• A property management company exposed AI-generated summaries of internal emails with sensitive information about tenants, property owners and business partners.
• In what it calls "a particularly serious case", a service provider exposed more than 1,000 records with identity document details: passport numbers, expiration dates and nationalities.
• Also accessible: tens of thousands of contracts, invoices, personal photo albums and internal WhatsApp communications; newsletter subscriptions, waiting lists and support inquiries; and in one case 280,000 emails sent to a provider's customers.

Crissy Field's figures reflect "the records we actually downloaded; the affected datasets may contain more." It says the exposed data could be used for phishing, ticket fraud or identity theft, but that it could not establish whether any of it was misused.

Why this keeps happening: the shared-responsibility gap

Crissy Field says Lovable's marketing "repeatedly emphasizes that no technical knowledge is needed to build projects", which "can give the impression that the platform takes care of security too". Yet Lovable's Terms & Conditions "place responsibility for applications and data handling on the customers themselves", leaving "a troubling gap between the promise of an easy-to-use, all-in-one service and the responsibilities customers are expected to take on."

Its technical point is that database integrations on the platform "follow recurring patterns", so a misconfiguration approach that works against one app may work against others "with little extra effort". It adds that access-control mistakes "can happen in any application, whether written by people or built with AI", but that users without a technical background find them harder to spot. Its advice: an easy-to-use platform "does not remove the need for an expert review of access permissions before an application handles confidential data", and automated checks "are no substitute for a professional security assessment".

In a browser-to-database app the public key is in the page by design, so the access rules on each table (in Supabase, row-level security policies) are the security. That is the thing to verify. Lovable's reported "industry-wide" response may be right that other tools share the pattern; that is a reason to test every AI-built app, not a reason to relax.

Timeline

Because Crissy Field says its report has updated figures compared with the Handelsblatt article, numbers quoted in news coverage may differ from the ones here. We use Crissy Field's report throughout.

What security leaders should do this week

1. Inventory AI-built apps. Ask every team, including marketing, ops and "shadow IT", which apps were made with an AI app-maker and which hold customer, employee or payment data. Name an owner for each.
2. Run the 5-minute test on each one you own. Open it logged out in a private window, read what the browser's Network tab returns, and request a table directly with only the public key. Use our free Vibe-Coded App Security Checklist. Only test apps you own or are authorised to test.
3. Check row-level security on every table, and for allow-all policies. Confirm the service-role key is not in any browser code.
4. Look for secrets in the front end and repo history with the Secret Scanner or your own tooling, and rotate anything exposed.
5. Review what identity and payment data you collect. Do not store passport or card data in an app database; use specialist providers and delete what you do not need. See the API Data Exposure Lab to practise spotting APIs that return more than the screen shows.
6. Test AI features inside apps for prompt injection and over-broad data access with the Prompt Injection Tester.
7. Decide who is accountable. Read the builder's terms, record what is yours, and require an independent access-permission review before an AI-built app handles real customer data, repeated after significant changes.
8. If you find an exposure, treat it as an incident: close access, preserve logs, work out what could have been read, and follow your data breach response checklist for notification duties, which can run on short clocks such as 72 hours under GDPR.

Frequently asked questions

What did Crissy Field find in Lovable-built apps?

Crissy Field GmbH, a German application-security firm, examined 159,041 Lovable projects from December 2025 to September 2026. Of these, 34,545 used the Supabase database service and 24,664 websites sent Supabase records as soon as they loaded, with no login. By making further read-only requests it found records containing email addresses in 10,560 tables across 7,403 of those 24,664 websites (30%). It also describes cases with passport details, payment information and more than 200,000 chat messages.

Does the 30% figure mean 30% of Lovable apps leak data?

No, and Crissy Field says so. Its report states the 30% "should therefore not be read as a confirmed data leak rate". It applies only to the 24,664 websites examined more closely, email addresses may be public contact addresses or test data, the approach misses records without an email address, and the Common Crawl sample is "not representative of all Lovable applications".

What kinds of data were accessible?

Crissy Field lists, among others: more than 80,000 forum profiles with full names, email addresses, dates of birth and gender, plus more than 200,000 chat messages; tens of thousands of ticket and food-sales records with email addresses, phone numbers, postal addresses, payment information and ticket codes; AI-generated summaries of internal emails from a property management company; more than 1,000 records with identity document details including passport numbers, expiration dates and nationalities; tens of thousands of contracts and invoices; personal photo albums; internal WhatsApp communications; and in one case 280,000 emails sent to a provider's customers. It says it could not establish whether any of it was misused.

Was this a hack or a Lovable breach?

Crissy Field does not describe a break-in. It describes data that was "accessible without logging in" because of access-control configuration in apps built on the platform. It also says "Access control mistakes can happen in any application, whether written by people or built with AI". No source we have seen says Lovable's own systems were breached.

Who is responsible for the security of an app built with Lovable?

Crissy Field says Lovable's marketing repeatedly emphasises that no technical knowledge is needed, which "can give the impression that the platform takes care of security too", while Lovable's Terms & Conditions "place responsibility for applications and data handling on the customers themselves". Read the terms of any app-maker you use and treat access-permission review as your job.

What did Lovable say?

Crissy Field's report says only that Handelsblatt contacted Lovable with the findings. We were told Lovable said to Handelsblatt that the problem is industry-wide. We have not read that statement in the Handelsblatt article, so treat it as unverified here, and note it is Lovable's position, not a finding by Crissy Field.

How can I check my own app in five minutes?

Open your live app in a private window while logged out and see what loads. Watch the browser's Network tab and read what the API returns. For your own project, request a table directly with only the public key and no login; private tables should return nothing. Search your page source for secret keys. Our free Vibe-Coded App Security Checklist walks through each step. Only test apps you own or are authorised to test.

Is the Supabase anon key a secret?

No. The anon (public) key is designed to sit in front-end code, so row-level security policies on every table are what protect the data. The service-role key bypasses those rules and must never be in the browser.

Sources

• Crissy Field GmbH: Lovable: Many Apps Built on the Platform Expose Sensitive Data (primary source; all figures and quotes above unless attributed otherwise)
• Handelsblatt, Lina Knees: Lovable: Experten finden Datenlücke bei beliebter KI-Coding-Plattform (2 Nov 2026, in German; linked from Crissy Field's report, not read by us; the source for Lovable's reported "industry-wide" response)

This article is educational guidance for security and engineering leaders, not legal advice or a forensic report. It makes no claim about any specific app or organisation. Check Crissy Field's report for the latest figures.