VIBEHP GUIDE · UPDATED OCT 2026
Lovable app security checklist
Lovable gets you from idea to working app fast, but the default Supabase setup leaves a few doors open that you need to close yourself before real users arrive. Work through this list top to bottom; the first two sections cover the issues that actually leak data.
📊 We scanned 21 public vibe-coded apps: 57% had at least one Supabase policy open to everyone, 62% had committed a .env file, and 24% failed a clean npm install. The average launch health was 63/100.
01Database: Row Level Security
- ☐Every table in Supabase → Table Editor shows RLS enabled. No exceptions for "temporary" tables.
- ☐Search
supabase/migrationsforusing (true)andwith check (true). Each one should be data you're happy for anyone on the internet to read or write. - ☐Policies on user data compare against
auth.uid(), e.g.using (auth.uid() = user_id). - ☐Admin-only tables check a role from a protected table, not a value the client can send.
- ☐Storage buckets holding private files are not public, with policies on
storage.objects.
02Keys and secrets
- ☐The Supabase publishable/anon key in the frontend is fine. The service_role key must never appear in
src/. Search forservice_role. - ☐OpenAI, Stripe secret, Resend and other secret keys live in Supabase Edge Function secrets, never in
VITE_*variables (those ship to the browser). - ☐Run
git log --all -p | grep -E "sk-|sk_live_", or a secret scanner. Keys removed from files still live in git history, so rotate any that leaked. - ☐
.envis in.gitignore, and a.env.examplelists each variable with a placeholder.
03Edge functions and auth
- ☐Edge functions that do privileged work verify the user's JWT (
supabase.auth.getUser()) before acting. - ☐Functions that call paid APIs (AI, email, SMS) have basic rate limiting or per-user quotas.
- ☐Email confirmation is on, and redirect URLs are restricted to your domain in Supabase Auth settings.
- ☐Stripe webhooks verify the signature before granting anything.
04Ready for production
- ☐A clean
npm ci && npm run buildworks in a fresh clone, the same way your host will build it. - ☐Data calls handle errors (check
errorfrom Supabase), and there's a React error boundary, so a failed request isn't a white screen. - ☐Dependencies have no critical known vulnerabilities (
npm audit). - ☐You've opened your live site in an incognito window and tried to read another user's data via the browser console. It should fail.
Don't want to check all this by hand?
Paste your GitHub link. VibeHP runs every check on this page (plus a git-history secret scan and a real build) and gives you an HP score out of 100, with a copy-paste AI prompt for every fix.
Check my HP for $19 →One-time · Your code is deleted right after the scan
FAQ
Is the Supabase anon key in my Lovable app a security problem?
No. The anon (publishable) key is designed to be public. Your data is protected by Row Level Security, so the risk is tables with RLS off or policies like using (true).
How do I fix RLS issues in Lovable?
Ask Lovable: "Enable Row Level Security on every table and add policies so users can only read and write their own rows using auth.uid(). List each policy and explain it." Then verify in the Supabase dashboard.
Where should my OpenAI key go in a Lovable app?
In a Supabase Edge Function secret. Call OpenAI from the edge function, never from the browser and never in a VITE_ variable.