Security · October 19, 2026

Vibe-Coded Apps Keep Leaking Data: A Security Checklist

Vibe-coded apps have exposed medical, payment and personal data. What went wrong, and the checklist to run before your tool touches client records.

In March 2025, a researcher named Matt Palmer and his colleagues looked at 1,645 apps on Lovable's public showcase. These were the apps Lovable was proud of. In 170 of them, about one in ten, they found 303 endpoints that anyone on the internet could read or write. Names, emails, phone numbers, payment details, subscription data. On one site, they could insert a record that marked a payment as "paid" without ever going through Stripe.

That finding became CVE-2025-48757, rated 9.3 out of 10 for severity. It was not an exotic attack. It was a setting nobody had turned on.

If you run a service business, this is the part of vibe coding that should worry you most. A clinic, a law firm, an accounting practice or a staffing agency does not hold throwaway data. It holds the data clients trusted it with. A demo that leaks is embarrassing. A client portal that leaks is a phone call to your insurer, and in some industries, to a regulator.

This post walks through the incidents that keep repeating, why they happen, and the checklist we would run before any vibe-coded tool touches a real client record.

The same mistake, over and over

Lovable and Supabase: the open database

Most beginner-friendly builders, including Lovable and Bolt, pair your app with a Supabase database. To keep things simple, the app talks to that database directly from the user's browser, using a public key. That is a legitimate design. It is only safe if every table has Row-Level Security (RLS) policies that say who may read and write which rows.

When RLS is off, or written wrong, the public key opens the whole database. Anyone who opens their browser's developer tools can find it. That is what Palmer's team found, and later reporting says roughly 70% of the apps they sampled had RLS disabled entirely.

Lovable responded by adding a security scan in April 2025. Useful, but limited: it checks whether a policy exists, not whether it is correct. A policy that says "any logged-in user can read every row" passes the scan and still lets one of your clients read another client's file. The CVE is officially listed as disputed, because Lovable's position is that each customer is responsible for protecting their own app's data. Legally that may be right. Practically, it means the responsibility is yours.

Moltbook: the same thing, a year later

In early 2026, Moltbook, a social network for AI agents whose founder said he had not written a single line of code by hand, left its Supabase key in the site's front-end code with RLS not configured. Researchers got full read and write access to the production database: about 1.5 million API tokens, around 35,000 emails, and thousands of private messages, some containing other companies' API keys. It was fixed within hours. The data had already been reachable.

A year of headlines had not changed the default behavior. The tools still let you ship without the lock on the door.

EnrichLead: keys in the browser

In March 2025, a non-technical founder announced a SaaS built with Cursor and "zero hand-written code." Within about two days, people found API keys sitting in the front-end code, no real authentication, an open database and no rate limiting. They bypassed the paywall, tampered with data and ran up his API bills. When he asked the AI to fix it, the fixes kept breaking other parts of the app. He shut it down within a week.

Note the order of events. The security problem became a cost problem, then a product problem, then the end of the product.

Base44 and Lovable: when the platform is the weak point

Not every failure is the builder's fault. In July 2025, the security firm Wiz found that Base44, owned by Wix, had undocumented login endpoints that let anyone with an app's public ID register on a private company app, skipping single sign-on. Wix fixed it in under 24 hours and found no evidence of exploitation.

In April 2026, reporting by The Next Web described a flaw in Lovable's own platform that let a free account read other users' projects, including source code with hardcoded credentials and AI chat histories, for projects created before November 2025. It was reported through Lovable's bug bounty in March and disclosed publicly about 48 days later. Lovable first said it had not suffered a data breach and described the behavior as intentional, then later partially apologized. The facts are still argued over. The lesson is not: anything you put into a hosted builder, including secrets you pasted into a chat, lives on someone else's infrastructure.

It is not a few bad apps

It would be comforting if these were outliers. The broader research says otherwise.

That second number matters most. The AI is not careless now and careful next year. It writes code that works, and "works" and "safe" are different tests. Security holes rarely show up when you click through your own app. They show up when someone else goes looking.

Why this hits service businesses harder

A consumer side project that leaks email addresses is bad. A service business tool usually holds something worse:

  • A clinic or therapy practice: intake forms, symptoms, appointment history.
  • A law firm: case notes, uploaded documents, who is suing whom.
  • An accounting or financial advisory firm: tax returns, bank statements, account numbers.
  • A staffing agency: CVs, ID documents, right-to-work checks, pay rates.
  • A home services company: addresses, access codes, when the client is away.

There is also a structural problem. Most service-business tools are multi-client by nature. A client portal exists so that Client A sees Client A's documents and nothing else. That is exactly the kind of rule RLS enforces, and exactly the kind of rule that a scan for "does a policy exist" will not check. The app looks perfect when you log in as yourself. The failure only appears when Client A types a different ID into the address bar.

Your clients will not care which tool you used. They will care that their file was readable.

The pre-launch checklist

Run this before any vibe-coded tool handles real client data. If you cannot answer an item, that is the answer.

Database and access

  1. RLS is reviewed, not just enabled. For every table, write down in plain English who should see which rows, then test it. Log in as two different test clients and try to read each other's records, including by changing IDs in the URL. Do not rely on a built-in scanner.
  2. No table is readable by "anyone logged in" unless every logged-in user genuinely should see every row.
  3. Admin actions are checked on the server. Hiding a button in the interface is not access control.

Secrets

  1. No secrets in front-end code. Open your live site, open the browser's developer tools, and search the loaded files for "key", "secret" and "sk_". Anything that can spend money or read private data must live on the server.
  2. Rotate every key that has ever been pasted into a chat, a prompt or a public repository. Assume it was seen.

Money

  1. Payments are verified on the server. The app should only mark something as paid after Stripe confirms it through a server-side webhook. A user should never be able to write "paid" into their own record.
  2. Billing caps are set on every usage-billed service. OpenAI, Anthropic, Google Maps, your email provider. Simon Willison warns specifically about people running up thousands of dollars on APIs with no limit set.
  3. Rate limits exist on login, sign-up and any endpoint that calls a paid API. Otherwise one script can drain your budget overnight, as EnrichLead found.

Recovery

  1. Development and production are separate. Separate databases, separate keys. You and the AI experiment on fake data, never on client records.
  2. Backups exist, run automatically, and you have restored one. A backup you have never restored is a hope, not a backup.
  3. You know how you would find out. Logging is on, and someone checks it. If a breach happened today, how many days would pass before you noticed?

Review

  1. Someone who understands the code has reviewed the critical paths. Login, permissions, payments, file uploads, anything touching client data. Simon Willison's rule is a good bar: don't ship code you could not explain to somebody else. If you cannot explain it, pay someone who can, before launch rather than after.
  2. You know your obligations. Health, legal and financial data often come with rules about where it is stored and who can access it. A hosted builder's default region and terms may not meet them.

None of this makes vibe coding the wrong choice. For a prototype with fake data, an internal tool behind your company login, or a demo to test whether clients want the thing at all, these tools are excellent and fast. The checklist is the line between a prototype and something you can put your clients' names into.

Where we come in

Most of the security failures above share a cause: the product was built for a demo and then given real users. Nobody stopped to do the unglamorous last part. Addy Osmani calls it the last 30%, and in a service business, most of that 30% is about protecting other people's data.

Our view is that automation is the floor and the leap is a product your clients actually use and pay for. A product clients use is a product that holds their data, so security is not a phase at the end; it is built into the first version. We build a working prototype before any money changes hands, so you can see the idea is right. Then one fixed build fee covers turning it into something production-safe, and we stay on as product lead, paid on what the product earns, so we are around when the next vulnerability report lands.

If you are building it yourself, use the checklist. If you would rather spend your time running the business, we are happy to talk.