Is your Lovable app safe?
Lovable gets you a working app fast. What it doesn't always do is lock the database down. Check yours in about a minute, for free, and get the fix for anything that's open, including a prompt you can paste straight back into Lovable.
Check the live database
Your app uses a Supabase project you can log in to. Connect it read-only and see which tables anyone can read, plus weak Auth settings. No account needed.
Check my Supabase projectScan the code
Your project syncs to GitHub (the way in if you use Lovable Cloud). GuardLayer reads the code and any supabase/migrations files for missing RLS, exposed keys and open functions.
Scan my repoWhat goes wrong in Lovable apps
Tables anyone can read
Lovable builds on Supabase, and every table in the public schema is reachable with the key that ships in your app. If Row Level Security is off, or a policy says using (true), anyone can download those rows. That's how 170 Lovable apps leaked data in 2025.
The Lovable RLS vulnerability, explainedA secret key in the browser
The anon or publishable key is meant to be public. The service_role or secret key is not: it skips every policy. When a prompt asks the AI to "just make it work", that key sometimes ends up in frontend code.
What to do if your service_role key is exposedEdge Functions and APIs with no auth check
A function that sends email, charges a card or calls an AI API needs to check who's calling. Generated functions often don't, so anyone who finds the URL can run them on your bill.
How to protect a Supabase Edge FunctionPolicies that look fine but aren't
RLS is on, the scan is green, and the data still leaks. A policy that only checks "is the user signed in?" lets every user read every row, and with open sign-ups or anonymous sign-ins that's anyone. And RLS picks rows, not columns: if users can update their own profile, they can usually set their own role or plan too.
Where roles belong so users can't change themAuth settings left on the defaults
Email confirmation off, leaked passwords accepted, no CAPTCHA on sign-up. None of it breaks the app, so nobody notices until someone abuses it.
Leaked password protection, and where to turn it onFix it without writing SQL
Every Live check report has a "Copy fix prompt for AI" button. Paste it into Lovable's chat: it lists each problem with the SQL fix, and tells the AI to use a migration and never "fix" an error by turning RLS off or opening a table to everyone, which is the usual way these holes come back. Then run the check again.
Working in Claude Code or Cursor instead? Add GuardLayer as an MCP server and the agent can run the check and confirm its own fixes.
Before you share your Lovable app
The short list we'd check on any vibe-coded app before real users sign up:
- Row Level Security is on for every table in the public schema
- No policy uses using (true) on a table with user data
- Each user can only read and change their own rows (test it with a second account)
- The service_role or secret key appears nowhere in frontend code
- Every Edge Function checks the caller before doing anything
- Storage buckets with user files are private
- Email confirmation and leaked password protection are on
The longer version, with how to check each one: the vibe-coded SaaS security checklist.
Questions
Is Lovable safe to use?+
The platform itself is fine to build on. The risk is in what the generated app ships with: Lovable apps run on Supabase, and the database is only as safe as its Row Level Security policies. In 2025 a researcher found 303 exposed endpoints across 170 Lovable apps (CVE-2025-48757), all from missing or weak policies. Check your own app before you share it, and again after big changes.
Is Lovable Cloud safe?+
Lovable Cloud runs on Supabase too, so the same rule applies: your data is protected by your RLS policies, not by the key being secret. If your project syncs to GitHub, scan the repo here: GuardLayer reads the code and any supabase/migrations files in it. If you use your own Supabase project, connect it for a live check.
Lovable has its own security scan. Do I need this too?+
Run Lovable's scan as well; more than one check is good. A scan that only checks RLS is on can pass while data still leaks: a policy that lets any signed-in user read every row is public if anyone can sign up, and a user who can edit their own profile can often set their own role to admin. GuardLayer reads your policies and your Auth settings together to catch exactly that, sees your live project as it is right now (including changes made outside Lovable), and can re-check every push to GitHub. Every finding comes with the fix, and a prompt you can paste back into Lovable.
Can GuardLayer change or read my data?+
No. The Supabase connection is read-only and only reads your database structure: tables, policies, grants, functions and settings. It never reads rows, and access ends within an hour unless you create an account.
Is the key in my Lovable app's code a problem?+
If it's the anon or publishable key, no: it's public by design, and RLS is what protects your data. If it's the service_role or a sb_secret_ key, yes: rotate it in Supabase now and move the code that needs it to an Edge Function.
Check your Lovable app now
Read-only, free, about a minute. It never reads your rows.
Check my Supabase project