Is Your AI-Built App Leaking Customer Data? A 7-Point Security Check for Lovable, Bolt and Cursor Apps

Quite possibly. Apps built with AI tools like Lovable, Bolt and Cursor usually work beautifully and still leave the door open: databases a stranger can read without logging in, secret keys sitting in plain view, and no check on who's allowed to change things. The 7-point check below catches the most common problems, and you can do the first two yourself this afternoon.

I like these tools a lot. You describe the app you want, the AI writes it, and by Sunday evening you have something with a sign-up page and a payment button. People call this "vibe coding."

The catch is what the AI is aiming for. It's trying to make the app work when you click around it. A stranger poking at your app from the outside isn't part of that test, so nobody checks for them.

How common is this, really?

Common enough that I'd assume your app has at least one of these problems until someone checks. A few numbers from the past year:

• Security company Escape looked at more than 5,600 publicly available vibe-coded apps, most of them built on Lovable. It found over 2,000 security holes, more than 400 exposed secrets and 175 cases of exposed personal information, including medical records and bank account details. Most of it was reachable without logging in.
• A scan of about 31,000 live vibe-coded apps in August 2026 found that 57% of the reachable apps using Supabase (a popular database service these tools plug into) let anyone read their data tables without signing in. Roughly 1 in 23 of all the apps had a secret key in files anyone could download.
• A study by Symbiotic Security found that 16% of the live vibe-coded apps it tested let anonymous visitors change or delete data. Not just look at it. Delete it.
• Researchers presenting at ICML 2026, a major AI conference, tested AI coding agents on real programming tasks. The best setup produced working code 57% of the time, but code that was also secure only 11.8% of the time.

Escape calls its own numbers a lower bound, because it only looked from the outside.

Why do AI-built apps leak data?

Mostly because of three gaps you can't see from inside your own app.

The first is a database with no bouncer. Many AI builders keep your data in Supabase, which has a feature called Row Level Security, usually shortened to RLS. Picture your customer list as a big spreadsheet. RLS is the bouncer standing next to it who checks who's asking and only shows each person their own row. Supabase's own documentation says a table without RLS is readable and writable by anyone with access to it, and tells you to turn it on for every table. With RLS off, that spreadsheet is close to public.

The second is secrets ending up in the browser. Your app talks to other services (payments, email, AI) using keys, which work like passwords. Some of those keys belong only in the back office, on the server. When one gets placed in the part of the app that loads on a visitor's screen, anyone who knows where to look can copy it. It's a bit like taping the office key to the front window.

The third is an app that trusts what it shows. A very common pattern: the AI hides the "Delete customer" button from anyone who isn't an admin. Looks fine. But that button is just a nice way of sending a request to the server, and if the server never checks who's asking, someone can send the same request directly and it'll do it.

How do I check my AI-built app before launch?

Work through these in order. The first two you can do yourself. For the rest, I've included words you can send straight to whoever built the app, or paste into the AI tool itself.

1. Test your app as a stranger. Open a private or incognito browser window, don't log in, and try to reach pages that should be for members only. Then create two test accounts. Log in as the second one and try to see, edit or delete the first one's things. If you can, so can anyone.
2. Make sure every table has RLS turned on. In your Supabase dashboard, open each table and check that Row Level Security is enabled and has rules attached (Supabase calls them policies). If you're not sure what you're looking at, send this: "Please confirm Row Level Security is enabled on every table in our Supabase project, with policies so each user can only see and change their own data."
3. Hunt for exposed keys. Send your developer: "Please check that no secret or service keys are in the front-end code. Anything named with VITE_ or NEXT_PUBLIC_ at the start ends up in the browser, so it must not hold anything secret. If a secret key was ever exposed, please rotate it." Rotating means cancelling the old key and issuing a new one, like changing the locks after you lose a key.
4. Check that the server enforces admin rules. Ask: "For every admin action, does the server itself check the user's role, or is the button just hidden?"
5. Lock down file storage. If customers upload anything (photos, documents, IDs), the folders holding those files should be private. Ask: "Are all our storage buckets with customer uploads set to private?"
6. Ask the AI to review its own work, then check it anyway. In one small study of six web apps, adding security instructions to the prompt cut confirmed problems roughly in half. Try something like: "Review this app for who can access what, exposed secrets and unsafe handling of user input, and fix what you find." Then repeat step 1, because the AI sounds just as confident when it's wrong.
7. Get a human to look before real customer data goes in. If the app will hold customer, health or payment information, an independent review costs a lot less than explaining a breach to your customers.

If you'd like this as a printable list to tick off, I made a free AI-built app security checklist.

What if my app is already live?

Do steps 1 to 3 today. They cover the worst and most common problems, and none of them requires taking the app down.

If you find an open table or an exposed key, fix the setting, rotate the key, and ask your developer to go through the logs (the app's record of who accessed what) for signs that a stranger read data they shouldn't have. Depending on where your customers live and what was exposed, you may have a legal duty to tell them, so get advice early rather than late.

Should I stop using AI app builders?

No. They let one person ship in weeks what used to take a team most of a year, and I think that's wonderful. Just add a security check before launch, the same way you'd have someone read a contract before you sign it.

If you've built something with Lovable, Bolt, Cursor or similar and you'd like a second pair of eyes, that's what my security reviews for AI-built apps are for. Get in touch and we'll work out what your app actually needs. And if you're hiring developers rather than building it yourself, here's how to choose a secure outsourced development team.

Frequently asked questions

Are vibe-coded apps secure?

Not by default. Large scans in 2025 and 2026 found open databases, exposed keys and missing access checks in a big share of live AI-built apps. They can be made secure, but someone has to check.

What is Supabase Row Level Security (RLS)?

It's a set of rules on your database that decides which users can read or change each row of data. Without it, a table can be read, and sometimes changed, by anyone using the app's public connection.

How do I check my Lovable or Bolt app for security issues?

Start by using the app logged out and as a second test user, and see what you can reach that you shouldn't. Then have your developer confirm RLS is on everywhere, no secret keys are in the front end, admin actions are checked on the server and storage is private.

Can I just ask the AI to make my app secure?

It helps, but it isn't enough on its own. A security-focused prompt reduced problems in one small study, yet AI tools write insecure code with the same confidence as secure code. Test the result.

Do I need a security review before launching an AI-built app?

If it will store customer, health or payment data, yes. For a simple internal tool with no personal data, the self-checks above may be enough.

Sources

• Escape: 2k+ vulnerabilities in vibe-coded apps (methodology)
• VibeEval: Vibe Coding Security Monthly, August 2026 (summarizes the 31,000-app Reeve scan, the Symbiotic Security study, the SUSVIBES benchmark presented at ICML 2026, and the twin-prompt study)
• Supabase docs: Row Level Security
• Vite docs: Env variables and modes
• Next.js docs: Environment variables

Sara Wolpin is the founder of PinSecurity and a working CISO. She reviews AI-built apps for founders and small businesses, and builds secure custom software through PinForge.