"RLS on" isn't "RLS right"
Supabase lets your browser talk straight to the database. Row level security policies are the only thing deciding who sees which rows. A policy of USING (true) counts as "enabled" but lets everyone read everything.
Pit stops for vibe-coded apps
You shipped fast.
Now lock it down.
We check Lovable apps on Supabase for open database tables and leaked secret keys, then fix them in a pull request you review and merge.
Opens your email app. No account, no card, no repo access needed for the free check.
The problem
Why vibe-coded apps leak data
AI builders get you to a working app in an afternoon. The database rules that keep one user out of another user's data are easy to miss, and a green checkmark doesn't always mean they're right.
Secret keys in the frontend
Anything in your client code, including VITE_ environment variables, ships to every visitor's browser. Put an OpenAI, Stripe or Supabase service_role key there and anyone can copy it from view-source.
The app keeps changing
Every prompt can add a table or rewrite a file. In Lovable's own words, it "treats code you wrote the same as code it generated, and it can change either in a later request." A fix today can quietly come undone next week.
The receipts
-
CVE-2025-48757: a security researcher reported that apps built on Lovable "often lack secure RLS configurations", and that the security scanner Lovable later added "merely checks for the existence of any RLS policy, not its correctness."
Read the researcher's statement -
Escape.tech reported "2,038 highly critical vulnerabilities and 400+ leaked secrets discovered across 1.4K vibe-coded applications."
Read the Escape report -
A public scan shared on Hacker News reported 2,217 of 20,052 scanned URLs (11.04%) exposing Supabase credentials. In the same thread, Supabase's CEO wrote: "People disabling RLS, or making RLS a simple pass-through, is a battle we are constantly fighting."
Read the Hacker News thread
How it works
In and out of the pits in 3 steps
-
Pit in: free check
Send us your app's URL. We look only at what any browser would load (your HTML, JavaScript and response headers) and flag exposed keys and missing headers. Prove you own the app and we'll also run a read-only check of which tables are open, reporting table names and counts, never your data.
-
Tyre change: lockdown fix
Give our GitHub App access to just that one repo. We test the fix on a copy of your database, never production, then open a pull request on a separate branch with the policies, the migration and the code changes, plus a plain-English report.
-
Back on track: you merge
You review the pull request and merge it. We never push to your main branch and never merge for you. Want us watching your back? Add re-scans so new tables and new keys get caught early.
Pricing
Simple pricing, no surprises
For Lovable apps on Supabase, including Lovable Cloud. Prices in USD.
Free Check
$0
- Scan of your live URL, no access needed
- Secret keys exposed in your JavaScript
- Supabase detection and security headers
- Open-table check once you prove ownership (names and counts only)
The main event
Lockdown Fix
$79 one-time
- Pull request with RLS policies (
USINGandWITH CHECK) on every exposed table - Storage buckets made private
- Secret keys moved server-side
- Migration file for your schema
- Before-and-after test: user A can't read, change or delete user B's rows
- Key rotation checklist and git history findings
Re-scan
$19 / month
- Re-scan on every push to your repo
- Weekly scan of your live app
- Alert when a new table ships without RLS
- Alert when a new key shows up in your code
Online checkout isn't live yet. Email us and we'll reply with next steps.
FAQ
Questions from the grid
Can I get a check on any app?
No. We only check apps you own or are authorized to test, and you'll need to prove it before we send a single request to your database. You can prove ownership by adding a small verification file to your site, a DNS TXT record on your domain, or a meta tag. We never scan apps whose owners haven't asked us to.
What does the free check look at?
Without verification, only what any visitor's browser already loads: your HTML, JavaScript files and response headers. We look for secret key types (we never show full keys), whether Supabase is in use, and missing security headers. After you verify ownership, we also run read-only requests with your public anon key to see which tables and buckets are open. We report table names and row counts, never row data, and we don't write anything to your live app.
What access do you need for the $79 fix?
Our GitHub App, installed on only the one repo Lovable syncs to. It can create a branch and open a pull request. It never pushes to your main branch, never force-pushes and never merges. If you use your own Supabase project, you can optionally connect it with read-only scopes so we can see your real schema. We don't ask for your service_role key.
I'm on Lovable Cloud. Does this work?
Yes, with one extra step. Lovable doesn't run migration files added through Git on Lovable Cloud, so you'll get the exact SQL and a ready-to-paste Lovable prompt to apply the fix yourself.
Will the fix break my app?
Strict rules can lock out real users if they're wrong, so we test them on a copy of your database first, including a check that a normal signed-in user can still see their own data. It arrives as a pull request you review, with a note on how to roll it back. Nothing changes until you merge it.
Is this a penetration test or a security certification?
No. It's a focused check and fix for the most common problems in Lovable + Supabase apps: row level security, exposed keys, storage buckets and secrets in git history. It's not a full audit and we can't promise your app is free of every vulnerability. Your report lists what we checked and what we didn't.
Who does the work?
Automated agents do the scanning, fixing and testing. A human reviews the tricky cases, such as shared team data, payment tables or a live secret key. We'd rather tell you that than pretend otherwise.
I think a key already leaked. What now?
Rotate it first, at the provider (OpenAI, Stripe, Supabase and so on), since removing it from your code doesn't make a copied key stop working. The lockdown fix includes a rotation checklist with direct links and moves the key server-side. We never ask you to send us the key itself.
Why would I need re-scans?
Every new prompt can add a table or move code around, and a new table without row level security can be readable by anyone holding your public anon key. Re-scans catch that when you push, not after someone else finds it.
Do you support Bolt, v0, Replit, Cursor or Firebase?
Not yet. We're starting with Lovable apps on Supabase because that's where these problems come up most. Email us if you're on something else and we'll let you know when we get there.
Box, box, box.
Find out what your app is showing the world before someone else does.
Get a free check