Your AI-Built App Might Already Be Leaking Data. Here’s How to Check.

I keep having the same conversation.

Someone builds a real app in a weekend using Lovable, v0, or Bolt. It works. It looks great. They're about to post the link in a founder group or send it to their first hundred users.

Then I ask one question: "Who can see other people's data on there?"

Most of the time, they've never checked. Not because they're careless. Because nobody told them they needed to.

What these tools actually built for you?

Here's the part that gets skipped in every "how to vibe code an app" tutorial.

When you describe an app in plain English and an AI builds it, it's not just generating your login screen and your buttons. It's also connecting your app to a real, live database, usually a service called Supabase.

Think of that database as a filing cabinet in the cloud. Every signup, every message, every uploaded photo gets stored in a drawer somewhere inside it.

By default, a filing cabinet with no rules lets anyone holding a key open every drawer. The rules that decide who can open which drawer are called Row Level Security, or RLS for short.

Your app needs those rules written explicitly. If nobody writes them, the AI doesn't stop your app from working. It just quietly leaves every drawer unlocked.

This already happened. More than once!

A security researcher scanned 1,645 live apps built on Lovable.

170 of them let any stranger, with no login at all, read other users' names, emails, financial details, and API keys.

Every single case had the same root cause. The database tables were created, but nobody ever wrote the RLS rules behind them.

That vulnerability got a name: CVE-2025–48757. It was reported in March. Affected users weren't notified until 69 days later.

A separate case is harder to read about.

• A dating safety app, built by a founder who has said publicly he doesn't know how to code, exposed 72,000 images through an unlocked storage folder
• Roughly 13,000 of those were identity verification selfies, the exact photos people submit to prove they're safe to meet
• No login was required to view them, just a direct link
• Multiple class-action lawsuits followed!

Neither founder was reckless. They were doing exactly what these tools are built for: moving fast.

The tools just don't tell you, out loud, what they skipped along the way.

The test that actually matters

You don't need to read code for this. You need two email addresses and about ten minutes.

Here's the single most important check, the one behind almost every real story above:

1. Sign up for two throwaway accounts on your own app
2. Log in as "User A"
3. Try to view or edit anything that belongs to "User B": their profile, their orders, their uploaded files

If User A can see or touch anything belonging to User B, stop what you're doing. That's the exact failure pattern behind the 170 exposed Lovable apps, not some minor edge case.

A second quick one, if you're using any paid API inside your app:

• Open your site
• Press F12 to open developer tools
• Click the Network tab and reload the page
• Search for the word "key" or "secret"

If a long, random string shows up next to something that isn't supposed to be public, someone else can copy it and use your paid service on your dime. This has already happened to founders who had no idea their API key was sitting in plain view in their own frontend code.

Why this doesn't get talked about enough

Search for "is Lovable secure" or "is Bolt safe" and most of what comes back is written for developers. It talks about RLS policies and service role keys like you already know what those mean.

If you don't have a technical cofounder, none of that helps. You just want one answer: can a stranger see your users' data right now.

That's the actual gap. Most security writing out there assumes you already understand databases. Barely any of it is written for someone who typed a prompt into an AI tool and ended up with something real.

Before you send that link to anyone

Run the two-account test above before your next launch, before you add a payment form, and definitely before you send the link to anyone outside your immediate circle.

Ten minutes now costs nothing. A data breach later costs your users' trust, your time, and possibly a lawsuit that looks a lot like the one above.

If you want the full walkthrough, including five checks total, a red flag checklist, and a plain-English explanation of what a real fix looks like versus a rushed one, I put it all together in a short guide called Is My Vibe-Coded App Safe to Launch? It's written for exactly this moment, the one right before you hit publish.

You didn't build a website. You built a database with a front door. It's worth knowing who else has the key!