Is My Vibe-Coded App Safe to Ship? The 10-Minute Check

You're about to hit deploy. The app works, the demo went well, and one question is stuck in your head: is this actually safe to ship, or am I about to hand my users' data to whoever asks nicely?

You don't need a full security audit to get an honest answer right now. You need five yes-or-no questions you can check yourself, in your browser, in about ten minutes.

That's this post. Answer each question with a straight yes or no. If you get five yeses, you're probably fine to ship today. If you get even one no, don't ship until it's fixed. Most of these take an afternoon, not a rewrite.

⚡ TL;DR

• Five yes/no questions cover the areas where vibe-coded apps actually leak: database access, secret keys, storage buckets, auth on sensitive endpoints, and source maps/headers.
• Every question is answerable by looking at a dashboard or trying something in your browser. No code reading required.
• Five for five: ship, then re-check after big changes. Anything less: fix it first, same day if you can, then re-run the check.

The 5-question gut check

Go through these in order. Each one tells you exactly where to look and what a "yes" looks like. If you want the exhaustive, section-by-section version of this same territory (with deeper fixes and prompts for your AI tool), that's the full pre-launch security checklist. This post is the fast version for when you just need an answer.

1. Does your database only show each user their own data?

Most vibe-coded apps run on Supabase, and the control that decides who sees what is Row Level Security (RLS): a per-user filter the database enforces on every query.

How to check: Open your Supabase dashboard, go to Authentication → Policies (or Table Editor → the table, then check its RLS toggle). Confirm every table holding real user data shows RLS enabled, and skim one policy to make sure it isn't USING (true). That phrase means "let everyone through," which is the same as no policy at all.

Yes = every table with user data has RLS on, with policies that actually restrict rows to their owner. No = any table is "RLS disabled," or a policy reads USING (true).

This is the single highest-leverage check on this list. CVE-2025-48757, the first published CVE for this exact pattern, found 170 of 1,645 scanned Lovable/Supabase apps (10.3%) leaking data this way through 303 endpoints. All reachable with nothing but the public anon key.

2. Are your secret keys actually secret?

Not every key in your app is a problem. The Supabase anon key and the Firebase web config are meant to live in your browser code. That's how those platforms work, and flagging them as "exposed" is a false alarm. The real danger is a different category: server-side secrets that should never leave your backend.

How to check: Open your deployed site, view page source or your browser's dev tools (Network or Sources tab), and search your JS bundles for sk_live_ (Stripe secret key), service_role (Supabase's RLS-bypass key), or any raw OpenAI/Anthropic/AWS key pattern.

Yes = none of those show up anywhere in your shipped frontend code. No = you find a Stripe sk_live_, a Supabase service_role key, an AI provider key, or cloud credentials sitting in browser-facing code.

A leaked service_role key is worse than no RLS at all: it bypasses every policy you just checked in question 1.

3. Can a stranger open your private files without logging in?

Uploaded files (profile photos, ID documents, receipts) live in storage buckets with their own access rules, separate from your database. This is the gap that's easy to forget because it's not "the database."

How to check: Find a file that belongs to a private, logged-in user (a profile photo, an upload) and copy its direct URL. Open that URL in a private/incognito window, fully logged out.

Yes = the file refuses to load without authentication. No = the file opens for anyone with the link, no login needed.

This exact gap, an unsecured storage bucket, is how the Tea app breach exposed roughly 72,000 images including around 13,000 selfies and ID photos in 2025, followed by a second breach exposing over 1.1 million private messages.

4. Do sensitive pages and API calls check who's asking, not just whether they're logged in?

Authentication proves who someone is. Authorization decides what they're allowed to touch. AI coding tools are good at the first and frequently skip the second.

How to check: Log in as yourself, open a page that shows your own data (an order, a profile, an invoice) with an ID visible in the URL or network request, then change that ID to a number that isn't yours and reload.

Yes = you get denied or redirected. No = someone else's data loads.

This flaw class is called IDOR (Insecure Direct Object Reference), and it's the one gap our own scanner-validation testing couldn't catch with a passive scan. It needs a live test like the one above because it requires judgment about intent, not a pattern match. It's also worth checking that any admin or paywalled feature is enforced the same way: if the only thing hiding it is a button the UI doesn't show you, that's not enforcement.

5. Is your production build free of source maps and basic security headers?

The browser-facing layer of your app leaks more than most founders expect. Source maps can hand an attacker a readable copy of your original source code, comments included.

How to check: Open your site's dev tools → Sources tab and look for .map files alongside your JS. Then check your response headers (Network tab, click your main document request) for Content-Security-Policy and X-Frame-Options.

Yes = no .map files ship to production, and the core security headers are present. No = source maps are live in production, or the headers are simply missing.

In our own scanner-validation test against a deliberately vulnerable app, missing CSP, missing X-Frame-Options, missing X-Content-Type-Options, and shipped source maps were all caught cleanly. These are exactly the kind of gap that's easy to miss by eye but trivial for a scan (or an attacker) to spot in seconds.

Your verdict

Count your yeses.

5 out of 5: You're probably fine to ship. "Probably" because this ten-minute check covers the highest-leverage failure areas, not every possible gap. For the exhaustive version, work through the full pre-launch security checklist when you have more time. Ship today, then re-run this same check after any feature that touches auth, data, or uploads.

4 out of 5 or fewer: Don't ship yet. The good news: none of these five gaps require a rewrite. RLS policies, removing a hardcoded key, locking a bucket, adding a server-side permission check, and turning off source maps are each an afternoon of focused work, often something your AI tool can do correctly if you ask it precisely (see the sample prompt in the full checklist). Fix the "no," re-check that one question, and only then ship.

Either way, treat this as a snapshot, not a guarantee. Your AI ships new code on every prompt, and new code can quietly reopen a gap you already closed.

FAQ

Do I need to check all five, or can I skip to the ones I'm worried about?

Check all five. They're independent failure modes: a clean database with a leaked service_role key is just as exposed as a locked-down key sitting on top of USING (true) policies. Ten minutes is short enough that skipping isn't saving you meaningful time.

My scanner flagged my Supabase anon key. Do I need to fix that before I ship?

No. The anon key and Firebase's web config are public by design, meant to sit in your browser. That's not the gap; a scanner or checklist that treats it as critical is crying wolf. The actual risk is question 1, whether the RLS policies behind that key restrict rows to their rightful owner.

I'm not technical. Can I really run this check myself?

Yes. Every question above is "open a dashboard and read a setting" or "try a URL in a private browser window." None of it requires reading code. The only tools you need are your browser's dev tools and, for question 1, your Supabase (or equivalent) dashboard.

The bottom line

"Is my app safe to ship" has a fast, honest answer: run the database, secrets, storage, auth, and headers check above and see how many yeses you get. Five means ship. Anything less means fix it first, same day if you can. An attacker can run this exact check against your live app in minutes; the only real defense is running it yourself first, and running it again after every deploy that touches user data.