Is your Lovable app leaking user data? How to tell if your Supabase RLS is broken
Quick answer: How can I tell if my Lovable app is leaking data?
Lovable apps talk to Supabase with a public key anyone can find in the browser, so Row Level Security (RLS) is what keeps users’ data private. If RLS is off on a table, or a policy lets everyone through, anyone can read it. Warning signs: Security Advisor errors, tables an AI created that nobody reviewed, and policies you’ve never checked.
Most founders who ask this have a nagging feeling rather than evidence. Maybe someone posted about a data leak in a vibe-coded app, maybe a scan flagged something, maybe you just realized you never looked at your database rules. This guide explains what “leaking” actually means in a Supabase app and how to spot the warning signs without writing a line of code.
First, make sure the key in your app is the public one. Check your app now: the free Supabase key checker tells you which key type your frontend ships.
Your Supabase key being public is normal. That’s why RLS matters
Open any Lovable app, press F12, and you’ll find the Supabase project URL and a key in the JavaScript. That’s by design. Supabase’s API key docs say the publishable (legacy: anon) key goes in anything you ship, because “anyone can read it, so it only reaches what Row Level Security allows.”
Read that the other way round: RLS is the only lock on your data. Your login screen and your app’s UI don’t protect anything, because anyone can send requests to your database with the public key and skip your frontend entirely.
What “leaking” actually means
In practice it’s one of three situations:
- RLS is off on a table. Supabase’s Security Advisor calls this “Table publicly accessible”, and spells out the consequence: anyone with your project URL can read, edit and delete all data in it.
- RLS is on, but a policy lets everyone in. A rule that is always true (for example, “allow select for everyone”) looks secure in a list of policies and protects nothing.
- Signed-in users can see each other’s rows. The policy only checks that someone is logged in, not that the row belongs to them. With open signup, “logged in” means anyone who creates an account.
It’s happened before: CVE-2025-48757
In March 2025, researchers scanned 1,645 projects from Lovable’s public showcase and, by their account, found inadequate RLS on 303 endpoints across 170 projects (about 10%), exposing things like user tables, subscriptions and API tokens. They only looked at home pages. The issue was published as CVE-2025-48757. Lovable disputes it, on the grounds that each customer is responsible for protecting their own app’s data, and the record is marked as disputed. Either way, the practical lesson is the same: the app owner is the one who has to check.
Signs you might be affected (no code)
Supabase’s Security Advisor shows errors
In your Supabase dashboard, open Advisors → Security Advisor. Look for “Table publicly accessible”, “Sensitive data publicly accessible” or “Security policy allows unrestricted access”. If you’re on Lovable Cloud, Lovable lists your policies under More → Cloud → Database → RLS policies. You don’t need to fix anything yet. Just note what’s red.
An AI tool created tables you never reviewed
Every “add a feature” prompt can create a table and a policy. If you’ve never opened the list of tables and asked “who should be able to read this?”, nobody has.
You once “fixed” an error by opening things up
If a list came back empty and the fix was to turn RLS off, add an “allow all” policy, or switch to the service_role key, the error went away by giving everyone everything. Background in Supabase returns an empty array and leaked service_role key.
One account can see another account’s data
Create two test accounts and use the app as each of them. If account B ever sees account A’s projects, messages or orders, a policy is too wide. Only test with accounts and data you own.
Not sure which of these is your problem? The free health check looks at your live app in seconds, or request a free scan and we’ll tell you what we find.
What Lovable’s security scan does and doesn’t tell you
Lovable has improved a lot here. When the CVE researchers wrote their statement in 2025, they said the first security scanner only checked that some RLS policy existed. Lovable’s current security docs describe a Quick scan that runs on publish and flags tables without RLS and rules that let everyone through, plus an on-demand Deep scan that looks for users who can see or change data that isn’t theirs.
Run both. But take Lovable’s own caveat seriously: it says these tools “do not replace a thorough security review” and suggests a professional review for apps handling sensitive data. A scan reads your rules. It doesn’t know your business: whether a coach should see all clients, whether invoices are per user or per team, whether that “public” table was meant to be public.
What not to do
- Don’t switch the frontend to the
service_roleor secret key to make data show up. It skips every policy. - Don’t turn RLS off to get rid of empty lists. That’s a ten-second test, never a fix.
- Don’t accept “allow all” policies on anything private, even “temporarily”.
The October 30 twist
From October 30, 2026, new Supabase tables aren’t reachable from your app until access is granted (details in our October 30 checklist). When your next feature breaks with 42501, the tempting quick fix is to grant everything to everyone. On a table with weak RLS, that recreates exactly the leak described above.
Get it checked
Our free health check can’t see your RLS, to be clear. It looks at your live app from the outside and catches things like leaked secret keys in your JavaScript. Checking policies needs a look at the database and repo, which is what the Audit does.
Want to know for sure?
The $49 Audit reviews every table’s RLS policies and grants and tells you in plain English what’s exposed, within 24 hours. The $199 Fix closes up to 5 issues as a tested pull request within 72 hours. Not fixed, full refund.
FAQ
Is it bad that my Supabase anon key is visible?
No. The publishable (anon) key is meant to be public. Row Level Security decides what it can reach, so the question is whether your policies are right, not whether the key is hidden.
Does Lovable turn on RLS automatically?
Lovable’s docs say its Quick scan flags tables without RLS every time you publish, and its Supabase guide tells you to verify your policies yourself before going live. Don’t assume it’s handled: a policy can exist and still be too permissive. Check the Security view and your Supabase Security Advisor.
What’s the difference between RLS being off and a bad policy?
With RLS off, anyone with your project URL can read and change the whole table. With a bad policy, RLS is on but the rule lets too many people through, for example every signed-in user instead of just the owner. The result can be the same.
Can the free health check see my RLS?
No. It checks your live app from the outside (HTTPS, headers, source maps, leaked keys). RLS lives in your database, so it takes a repo or database review, like the free full scan or the $49 Audit.
I enabled RLS and now my app shows nothing. What happened?
RLS is working but no policy matches your requests yet. See our guide to Supabase returning an empty array.
What should I do if I think data already leaked?
Close the hole first, then look at what was exposed and for how long. If personal data of EU users may have been read, you may have notification duties under GDPR. Get legal advice on that. We can help with the technical side.
Related guides
- Supabase returns an empty array but the table has data? It’s usually RLS
- Leaked your Supabase service_role key in a vibe-coded app? What to do now
- Supabase’s October 30 change is live: a 5-minute checklist for new tables
- Stripe says “paid”, your app says “free”: why the feature didn’t unlock
Launching soon? Run through our launch checklist for AI-built apps: 14 checks, each linked to the full guide.