Your vibe-coded app is probably leaking data right now. Here's how to check — no code required.

I'm not a "real" developer.

I built my first real product the way a lot of people do now: an idea, an AI, and a lot of "just make it work." It was a member-management platform — three different kinds of users on it at once: members, the staff serving them, and admins. It felt like magic. Things that should've taken months showed up in days.

And at first, it worked. It really did.

Then I kept adding features. With three types of users, every feature had to behave differently depending on who was logged in — and it got complicated fast. At some point I went to check how my data was actually protected, and found the truth: RLS — the lock on my database — was barely set up. Around the same time, I kept seeing posts online about people getting wrecked by exactly this: an app with the database left open, real users' data exposed. The risk was enormous.

So I tried to fix it. And that's where it got bad.

I'd fix one permission rule — and a feature that had been working would break. I'd fix that — and the thing I'd just fixed would break again. Patch one hole, two more open. Working features fell over one by one, until the whole thing was tangled beyond saving. I couldn't move forward, and I couldn't roll back.

In the end I did the only thing left: I deleted everything. Two months of work, gone. I rebuilt it from zero — and that version, the one I built knowing what I know now, is the one that actually shipped.

I wasn't careless. I just didn't know what I didn't know. The AI ships the part you can see (the app works!) and quietly skips the part you can't (is it safe?) — and when you try to bolt security on afterward, onto a codebase that's already complex, it fights you the whole way.

So here's the checklist I wish someone had handed me on day one. Five things you can check in about ten minutes, no coding required. If you built something with AI and real people use it, please go through these.

Plain version: RLS (Row Level Security) is the lock on your database tables. With it off, your "public" key isn't really public-safe — anyone who finds it can read, change, or delete everything in that table. With AI-built apps, it's off by default more often than not.

How to check: In Supabase, go to Database → Advisors → Security. It will literally list every table with RLS disabled. Or open the Table Editor and look for the "RLS disabled" warning on your tables.

How to fix: Turn RLS on for every table that holds user data, then add a policy (more on why that's the tricky part below).

Plain version: Supabase gives you two keys. The anon key is meant to be public — it's safe as long as RLS is on. The service_role key is the master key. It ignores all your security. It should never, ever touch the browser. If the AI put it in your app's client code (it loves to, because it's "easier"), anyone can open your site and pull the whole database.

How to check: Search your code for service_role or SERVICE_ROLE. If it shows up anywhere outside a server file (like an app/api/ route), that's a red flag. Bonus check: open your live site, hit F12 (DevTools), and search the loaded files for your key.

How to fix: The service_role key belongs only in server-side code. Everything in the browser should use the anon key + RLS.

Plain version: Your .env file holds your secret keys. If it ends up on GitHub — even in a private repo — assume it's compromised. Bots scan GitHub for keys around the clock and find them within minutes. AI tools that run git add . sweep it up without telling you.

How to check: Look in your GitHub repo. Is there a .env file sitting there? Open your .gitignore and make sure it lists .env.

How to fix: Remove it from the repo — and rotate (regenerate) any key that was ever in there. Once a secret hits a repo, deleting it doesn't un-expose it. The only safe move is a new key.

Plain version: Variables with these prefixes get baked into your website and shipped to the browser. That's correct for public stuff (a public URL, an analytics ID). It's a disaster if a real secret has that prefix — because now anyone can open DevTools and read it. AI does this when it hits an error and "fixes" it by making the variable public.

How to check: Search your code for NEXT_PUBLIC_ or VITE_. If any of them is followed by something with SECRET, KEY, SERVICE, or PASSWORD in the name, you've got a leak.

How to fix: Drop the prefix and move it server-side. Then rotate the key.

Plain version: This is the "works on my machine, breaks when I deploy" classic. localhost means "this computer." When a real user loads your site and the code calls localhost, it's pointing at their machine, not your server — so it just breaks. Not a security hole, but it's the #1 reason live apps silently fail.

How to check: Search your code for localhost.

How to fix: Replace hardcoded URLs with an environment variable so production uses your real domain.

Turning RLS on is the easy 20%. Writing the right rules — and keeping them right while everything else changes — is the hard 80%. That's the part that broke me.

Here's why it's so brutal: a permission rule can look perfect, pass every glance, and still be wrong. The classic is a rule that checks "are you logged in?" when it needed to check "do you own this specific row?" — so every logged-in user can read everyone else's private data. It reads correct. It runs fine. It's wide open.

And it's not static. Every time you re-prompt the AI to add or fix a feature, it can silently re-break a rule you'd already gotten right. That's the exact loop I got stuck in — fix one, break another, forever — until I had to throw away two months of work and rebuild. No generic scan or AI prompt can know who should see what in your app. That takes understanding your intent, and holding it steady as the app grows.

That's the real problem I'm building for.

I'm building SnapDeck — a security net for apps built with AI. It scans for everything above (and more), in plain English, on your own machine. Your keys never leave your computer. No pasting your database credentials into some random website. (Please never do that, by the way.)

It's in early access. If you want in — or you just want more notes like this, the real numbers, what I ship, what breaks — subscribe below. I'm a solo dev in Jeju trying to go from $0 to $1K MRR in 90 days, in public, and I write down what I learn the hard way so you don't have to.

Go check your RLS. Seriously. I'll wait.

— Json

P.S. If you run one of these checks and find something scary, that's a good thing — it means you found it before someone else did. Reply and tell me what you found.