for apps built with Lovable
Lovable apps are React and Vite in the browser, Supabase behind them, and a GitHub repo kept in sync. It is a great stack to build on, and it has a few well-known ways to leak. We check the published app and the synced repo, and every fix is a prompt you paste back into Lovable.
Free for one app. No card, no install.
what usually goes wrong
Anything in a VITE_ variable, or pasted straight into a component, is built into the JavaScript every visitor downloads. Secret keys (OpenAI, Stripe, Resend) belong in a Supabase Edge Function and its secrets.
This is Supabase's master key. It ignores every RLS rule. If the front end has it, anyone can read, change or delete everything, so it is the most urgent thing we can find.
Lovable creates Supabase tables as you describe features, and writes each change as a migration in your repo. Your anon key is public by design, so RLS is the only thing between it and your data. We read every migration and flag tables that never turned it on, or policies that let everyone in.
Lovable pushes every change to GitHub. Connect the repo and we scan it on each push: committed keys, packages with known holes, and new tables without RLS, often before you hit Publish.
the fix is a prompt
Lovable can fix almost everything we find, if it is asked the right way. Here is a typical repo finding, and the prompt that comes with it.
A migration creates the profiles table and never turns on Row Level Security, so your app's public Supabase key can read and change every row.
Security fix: the Supabase table "profiles" has Row Level Security turned off, so anyone with the public anon key can read and change it.
Add a migration that enables Row Level Security on "profiles" and adds policies so a signed-in user can only select and update their own row (where id = auth.uid()). No public access.
Do not change the UI. Check the profile page still loads for a signed-in user, then show me the policies you created.
verify your app
Lovable serves anything in your project's public folder exactly as it is, so the file proof works on your lovable.app address and on a custom domain.
Add a site verification for VibeProtect. Create the file public/.well-known/vibeprotect.txt containing exactly this single line:
vibeprotect-verify=3kQ9xZr1VbN0aT7mYw2cLp8e
Also add this tag inside <head> in index.html (or the root layout's metadata):
<meta name="vibeprotect-verification" content="vibeprotect-verify=3kQ9xZr1VbN0aT7mYw2cLp8e" />
Do not change anything else.
Your real token is in the app once you add it. The file ends up at /.well-known/vibeprotect.txt.
questions
Yes, it is designed to be public. It is only safe when every table has Row Level Security with sensible policies. Connect your GitHub repo and we read every migration Lovable wrote, flagging tables without RLS and policies that let anyone in.
It does, and you should keep using it. It reviews your project from the inside while you build. VibeProtect checks the published app from the outside, the way a stranger would, and scans the GitHub repo. The two catch different things.
They are written to change only what the finding is about and to tell Lovable not to touch the UI. Still, check your app after each fix, the same as after any prompt, and rescan to confirm the finding is gone.
One app is free, no card. The hardest part is asking Lovable to add a file.