How do I secure a vibe-coded app before launch? A 10-point checklist
Last updated: October 22, 2026
Short answer: an AI builder gets your app working fast, but it doesn't always keep secrets secret or lock your data down. Before you share the link, check three places: your live site (what any stranger's browser can see), your database (who can read and write each table) and your code (auth, payments and server logic). The ten checks below cover all three. Only test apps you own.
Start with the outside: a free SniffPup scan of your live URL checks secret keys in your HTML and JavaScript (masked in the report), public /.env, /.git, /.npmrc and /.DS_Store files, a public source map, security headers, cookie flags and your HTTPS redirect. It's passive: it never logs in and never uses a key it finds. It can't see your code or your database policies, so do the other checks too.
The checklist
1. No secret keys in the frontend
Anything in a VITE_ or NEXT_PUBLIC_ variable is built into the JavaScript every visitor downloads. Keep OpenAI, Anthropic, Stripe secret, AWS, Resend and Supabase service_role or sb_secret_ keys on the server only (an Edge Function, API route or serverless function). If one has already shipped, rotate it first, then move the code. See how to find exposed API keys on your website.
2. Row Level Security on every table
If you use Supabase, your anon key is public by design, so Row Level Security (RLS) is what protects your data. Turn it on for every table in the public schema and replace any using (true) placeholder on user data with an owner check. Step-by-step SQL is in the Supabase RLS checker guide.
3. Test your data signed out
Open a private window, or use curl with only your anon key, and try to read a table that should be private. If rows come back, a stranger can read them too.
4. Test as two different users
Sign up two test accounts. Signed in as user B, try to load user A's data. If it works, your rules check that someone is signed in but not that the row belongs to them.
5. No public .env, .git or source map files
Visit /.env and /.git/config on your live domain. Either should return a 404. A public source map lets anyone read your original source, so turn source maps off in production builds unless you mean to share them.
6. Run your builder's own scan
Lovable has Quick and Deep security scans, and Bolt has a security audit and database check. They can see your code and settings, which an outside scan can't. See the Lovable, Bolt and Cursor checklists.
7. Run Supabase Security Advisor
In the Supabase dashboard, open Advisors, then Security Advisor. Fix every error-level finding, such as RLS disabled in public or a security definer view.
8. Check payments on the server
Never trust a price, plan or "paid" flag sent from the browser. Create checkout sessions on the server, and grant access only after a verified payment webhook.
9. Lock down admin pages and storage
Admin checks belong on the server or in your database rules, not only in hidden buttons. Don't trust a user-editable field (such as Supabase user_metadata) for roles. Keep storage buckets with user uploads private.
10. Add security headers and re-check after changes
Set Strict-Transport-Security, X-Content-Type-Options, a Referrer-Policy and frame protection, and redirect HTTP to HTTPS. Every new prompt can change your app, so re-scan after big changes, not just once.
What SniffPup checks, and what it doesn't
The free scan covers checks 1, 5 and 10 from the outside, and tells you when your site talks to Supabase. Every critical issue is shown in full with its fix, free (with no critical, one other fix is free). A one-time $9 Full Fix Report unlocks the fix for every finding plus 30 days of re-scans. Plans are Solo $7/mo, Starter $15/mo and Pro $29/mo; Pro adds an owner-verified, read-only deep Supabase check that counts which tables an anonymous visitor can read.
SniffPup can't check your code, your payment logic, signed-in access between users or anything behind a login. A score of 100 means no issues were found in our checks, not that your app is secure. Other good tools do different jobs; see how SniffPup compares and the best free scanners for vibe-coded apps.
FAQ
How do I check if my vibe-coded app is secure?
Use more than one check. Run your builder's own security scan (Lovable and Bolt both have one), run Supabase Security Advisor if you use Supabase, test your data signed out with your public anon key, and run a free SniffPup scan of your live URL to see what any visitor can see: leaked keys in JavaScript, public .env and .git files, source maps and security headers.
Is it safe to have my Supabase anon key in the frontend?
Yes. The anon or sb_publishable_ key is meant to be public. It is only safe when every table in an exposed schema has Row Level Security on with policies that match who should see what. The service_role and sb_secret_ keys must never be in the frontend.
Does a SniffPup score of 100 mean my app is secure?
No. A score of 100 means no issues were found in SniffPup's checks. SniffPup reads only what your live site serves to the public, so it can't see your source code, server logic, database policies or anything behind a login.
Can SniffPup scan my native mobile app?
No. SniffPup scans live web URLs only. If your app has a web version or a marketing site, SniffPup can scan that URL.
What does SniffPup cost?
The scan is free. Every critical issue is shown in full with its fix, free; if there are no criticals, one other fix is free. A one-time $9 Full Fix Report unlocks every fix plus 30 days of re-scans. Plans are Solo $7/mo, Starter $15/mo and Pro $29/mo.
A clean report is not a guarantee of security.