AI App Security Checklist: What to Check Before You Launch a Lovable or Bolt App, After Researchers Found Passport Data and 200,000 Chat Messages Readable Without a Login
Researchers found Lovable-built apps that let anyone read passport details, 200,000 chat messages and other customer records with no login. Here is the launch checklist to run on your AI-built app first.
Where Worldwide
On this page 9 sections
Crissy Field, an application-security and software firm in Hamburg, reports that apps built with the AI tool Lovable let anyone read passport details, more than 200,000 chat messages and other customer records straight from the app's database, without logging in. If you are about to launch an app built with Lovable, Bolt or a similar tool, your app can have the same mistake, and the checklist below shows how to find it before real customer data goes in.
What the researchers found in Lovable apps
Crissy Field did the research with the German business newspaper Handelsblatt, which ran its article on November 2, 2026. The team used Common Crawl, a public archive of web pages, to find Lovable projects published between December 2025 and September 2026. Their report gives these numbers:
- 159,041 Lovable projects analyzed, 34,545 of them using the Supabase database service.
- 24,664 sites sent database records to the browser as the page loaded, with no login and no other interaction.
- Email addresses turned up in 10,560 tables across 7,403 of those 24,664 sites (30%).
The examples they describe:
- A German lifestyle forum with more than 80,000 profiles (names, emails, birth dates, gender) and more than 200,000 chat messages.
- A service provider with more than 1,000 identity records, including passport numbers, expiry dates and nationalities.
- Event organizers and restaurants with tens of thousands of ticket and food sales records, including emails, phone numbers, postal addresses, payment information and ticket codes.
- A property management company with AI-generated summaries of internal emails about tenants, owners and business partners.
- Contracts, invoices, personal photo albums, internal WhatsApp messages, and one provider's 280,000 sent customer emails.
What is confirmed and what is not
Confirmed by the researchers: when they checked, this data could be read without a login. They held back the access details so nobody else could use them.
Not known:
- Whether anyone misused the data. The report says: "We could not establish whether any of it had been misused."
- How common this is. The researchers say the 30% figure "should therefore not be read as a confirmed data leak rate." Some of the emails may be public contact details or test data, and the Common Crawl sample does not represent every Lovable app.
- The exact setting that failed. The report blames "access control mistakes" and does not name a specific setting. It also did not look at Lovable's own database features, which arrived in late 2025.
- What Lovable said. Handelsblatt sent Lovable the findings. The report does not describe a reply.
It happened before: CVE-2025-48757
This is the second time researchers have reported the problem. In March 2025, a different group of researchers found Lovable apps with weak Supabase row level security (RLS), the database rules that decide which rows each user can see. Their own statement says 303 endpoints across 170 of 1,645 projects (about 10.3%) were affected. They tested home pages only. The CVE was published on May 29, 2025.
They also flagged a problem that matters for your launch: Lovable's security scan checked whether an RLS policy existed, not whether it was correct. So a passed scan does not prove the data is protected.
Who is responsible for an AI-built app's security
The customer is. Lovable's terms (last updated August 28, 2026) say: "You are responsible for your Customer Data and for the applications and projects you build, deploy, and make available," and "You are solely responsible for reviewing, validating, and using any AI Output."
Our view, in one line: AI can write the code, but a person has to review it before it ships.
Why it matters for a business
If your app leaks bookings, invoices or ID documents, your customers will blame you, not the tool you used. The leaked records in this study were the core data of real businesses, including restaurants, event organizers, a property manager and a service provider. Broken access control is number one on the OWASP Top 10 2025, the most widely used list of web application risks. Being built with AI does not change the risk. It means more apps reach customers without anyone reviewing them first. We cover that gap in AI can build your app, who keeps it running.
How Supabase keys and row level security work
A Supabase app usually ships two kinds of key:
- Publishable key (
sb_publishable_..., or the olderanonkey): Supabase says this key is safe to put in a web page, but it "only reaches what Row Level Security allows." If RLS is off on a table, anyone holding the key can read that table. - Secret key (
sb_secret_..., or the olderservice_rolekey): this key bypasses every RLS policy. Supabase says it must never go into "a browser, a shipped application, or source control."
Public keys are normal. A public key is only a problem if a table has no RLS or its policies are wrong.
AI app launch security checklist
Work through this before real customer data goes in, and again after any big change.
| Check | How to check | Done when |
|---|---|---|
| RLS is on for every table in exposed schemas | In the Supabase SQL editor run select tablename, rowsecurity from pg_tables where schemaname = 'public'; |
Every row shows true |
| User-owned data has policies limited to signed-in owners | Read each policy. Supabase's pattern is to authenticated plus using ((select auth.uid()) = user_id) |
Each policy names the role it applies to and checks ownership |
| A policy exists and does the right thing | Do not rely on a scanner. Read each policy against what each table holds | Someone has read every policy against its table |
| Views do not bypass RLS | Views created by postgres skip RLS by default. On Postgres 15 or later, set security_invoker = true |
Each view obeys its tables' policies |
| No secret key in the app | Search your code, repo and build settings for sb_secret_ and service_role |
Found nowhere outside the server; rotate any key that leaked |
| Logged-out test | Open the site in a private window, open developer tools, Network tab, and reload | No customer records in any response |
| Second-account test | Sign up as user B and try to load user A's records | Requests come back empty or blocked |
| Sensitive data waits for review | Passports, payments, health and contracts stay out until a person has reviewed access | Review signed off |
If you also need to check that the site is visible and locked down in other ways, see your website is live: can anyone find it, and is it locked?.
AI app security questions people are asking
Is my Lovable app leaking data?
Run the logged-out test and the second-account test from the checklist. If customer records show up in the Network tab without a login, or user B can see user A's data, then yes.
Is the Supabase anon key safe to put in my app?
Yes, if RLS is on for every table and the policies are right. The secret or service_role key must never reach the browser.
What is row level security in Supabase?
Row level security is a set of database rules that decide which rows each user can read or change. When RLS is on and no policies exist yet, the publishable key cannot reach any data.
Does Lovable's security scan make my app safe?
Not on its own. The CVE-2025-48757 researchers found the scan only checked that a policy existed. Crissy Field says automated checks "are no substitute for a professional security assessment."
Was the data in the Crissy Field study stolen?
Nobody knows. The researchers say they could not establish whether any of it was misused.
Does this apply to Bolt and other AI app builders?
The study only looked at Lovable. The same checklist works for any app whose browser talks directly to a database.
The bigger lesson
AI tools make it fast to build an app, but your business is still responsible for the data inside it. The fix is to put a review step between "it works" and "it's live". If you would rather run the database on servers you control, see self-hosting infrastructure, and read the gap in app development for what usually gets skipped.
Want someone to check your app before launch? See security hardening or get a quote.
Get security alerts by email, plus our free checklist, at /security-alerts.
Sources: Crissy Field: Lovable research report; Statement on CVE-2025-48757; Lovable Terms; Supabase: Row Level Security; Supabase: API keys; OWASP Top 10 2025.
Have a question about this article?
Ask it here and we will answer you directly by email. Questions are private, never posted.
Security alerts by email
Hear about the next one first.
When attackers start using a flaw in software businesses run on, we email what it is, whether it touches you and what to do that week, with a round-up of our latest security writing. Free, one-click unsubscribe. You get the checklist straight away: 12 things to secure this week.
Want a result like this?
Security alerts, breaches and the technology a business runs on: what happened, who it affects and what to do.
Get a Tech QuoteKeep reading
AI Agent Security Controls: OpenAI's Test Agents Breached Hugging Face, What Is Confirmed and the Access Limits to Set This Week
OpenAI's test agents broke into Hugging Face's production systems in July 2026. Here is what is confirmed, wha...
Enterprise AI Security Study: TCS Says 84% Value AI Productivity, Only 10% Let AI Agents Act Without Human Approval, and the Controls to Check
A TCS survey of 1,333 senior leaders says only 10% of enterprises let AI agents act without human approval acr...
Shadow AI Security: Why IT Teams Cannot See the AI Inside Their Networks, What Is Confirmed and How to Build an Inventory
Unapproved AI tools can reach company data without IT knowing. Here is what is claimed, what IBM's breach data...
