How to tell if your vibe-coded app is leaking data

"Leaking data" sounds dramatic, but it usually means something boring: a door was left unlocked. The app works fine for you, so you never notice. A stranger who goes looking finds it in minutes.

Here are five tests you can run yourself. None of them need you to read code.

Test 1: The second account test

This is the most useful test, and it takes five minutes.

1. Log in to your app with your normal account and create some data: a profile, a note, an order.
2. Open a private or incognito window and sign up with a different email.
3. Try to find the first account's data. Look at lists, search, and any page that shows "your" stuff.
4. If a page URL has a number or long ID in it (like /orders/1042), change it and see what loads.

If the second account can see anything that belongs to the first, your app is leaking data between users.

Test 2: The logged-out test

Log out completely, or use a fresh private window. Then visit the pages that should need a login, by typing their addresses directly: /dashboard, /admin, /settings, /account.

If any of them show real data without asking you to log in, they're open to everyone.

Test 3: Check your database for open tables

If your app uses Supabase (most Lovable and many Bolt apps do), open your project's Table Editor. A red Unrestricted label next to a table means anyone with your app's public address can read and change that table.

If you use Firebase, open your database Rules in the Firebase console. Rules that say allow read, write: if true or ".read": true mean the whole database is open.

Test 4: Look at what your app sends to the browser

You don't have to understand this one, just look for scary words.

1. Open your live app in Chrome.
2. Right-click the page and choose Inspect, then open the Network tab.
3. Reload the page and click around.
4. Click a few of the requests and look at the Response tab.

You're looking for things a visitor shouldn't see: other people's emails, phone numbers, addresses, or words like password, secret, or service_role. Apps sometimes load every user's record and only *hide* the extra ones on screen. Hidden on screen is not the same as private.

Test 5: Search your app for secret keys

In the same Inspect window, open the Sources tab, then press Ctrl+Shift+F (Cmd+Option+F on a Mac) to search all files. Try searching for sk_live, sk-proj, sk-ant, and service_role.

If any of those show up, a secret key is in your public app. Make a new key in that service's dashboard, delete the old one, and ask your app builder to move the key to the server side.

What to do if you find a leak

1. Fix the lock first. Ask your builder tool to turn on database security (for Supabase, Row Level Security with policies) or to require login on the open page. Be specific about what you saw.
2. Replace any exposed keys. Deleting the key from your code isn't enough. Old copies can stay cached. Make a new key and turn off the old one.
3. Run the tests again to confirm the fix worked.
4. Think about your users. If real people's personal info was exposed, you may need to tell them. The rules depend on where you and your users are, so look up the requirements for your country.

Running these five tests before launch, and again after big changes, catches most of the leaks that make the news.