Guide · Lovable
Users can see other users' data in my Lovable app
Updated
If one user can see another user's data, the standard fix, the way Supabase's docs describe it, is to turn on row-level security for every table your app reads through the API and add policies so each signed-in person can read only their own rows, for example using ( (select auth.uid()) = user_id ). Hiding rows on screen is not enough; the rule has to live in the database.
In our checks of 44 live AI-built apps, 5 (11%) let anyone read data that should be private, without signing in.
What we add from real checks: the owner almost never sees it. It shows up only for a second account, or a signed-out visit to a shared link, on the live address.
Why it happens
The database enforces who can read what through row-level security. If that protection is missing or too loose, the app is the only thing standing between visitors and everyone's data, and your app's public key is in every visitor's browser.
Possible causes
- Row-level security is off on a table. Supabase's own docs say such a table is readable and writable by any role with a grant.
- Security is on, but a rule lets every row through for every user, such as
using (true). Lovable's docs call these access rules that let everyone through. - The app filters on screen, not in the database: the page asks for all rows and shows only yours, but everyone's were sent to the browser.
- Uploaded files sit in a public storage bucket that anyone with the address can open.
- A secret or service_role key is in front-end code, which bypasses every rule.
How to fix it
- In the Supabase dashboard, open Advisors, Security Advisor. Fix every "RLS disabled in public" error (Supabase calls it "Table publicly accessible") and look at every "permissive RLS policy" warning, which flags rules such as
using (true). - Turn row-level security on for each table that holds personal rows:
alter table public.your_table enable row level security; - Add a read policy so people see only their own rows:
create policy "Users can view their own rows" on public.your_table for select to authenticated using ( (select auth.uid()) = user_id ); - Add matching insert, update and delete policies, or saves will start failing. See data won't save: row-level security.
- For uploaded files, make the bucket private and add policies on
storage.objects, following Supabase Storage: Access control. - Remove any secret or service_role key from front-end code. Supabase says to never use a secret key in the browser, because service_role bypasses row-level security. If one was exposed, replace it with a new key.
How to tell it's fixed
- On the live address, sign up two brand-new accounts and create a record in each. Each account sees only its own.
- Signed out, in a private window, open a link to one of those records. It shows nothing private.
- The Security Advisor shows no "RLS disabled in public" error.
The main catch
Turning row-level security on without policies locks everyone out: Supabase says that once it is enabled, no data is reachable through the API with the publishable key until you create policies. Add the read and write policies in the same change, then test with a new account, not yours.
You can't see it yourself
You're signed in, your customers aren't. You only ever look at your own account. Seeing someone else's data takes a second account, or a signed-out visit to a shared link, which you rarely try. Lovable's docs say its scans do not replace a thorough security review.
Frequently asked questions
Is my Supabase public key a secret?
No. The publishable (anon) key is meant to be in the browser. What keeps data private is row-level security on every table, which is why a table without it is open.
How do I find which tables are open?
Open Advisors, Security Advisor in the Supabase dashboard. It flags tables in the public schema without row-level security, and policies that let every row through.
Does Lovable's security scan catch this?
It can flag open tables and loose rules, but Lovable's docs say its scans do not replace a thorough security review. Test with a second account and a signed-out visit as well.
I turned row-level security on and now my app shows nothing. Why?
A table with security on and no policies returns no rows. Add a select policy for the owner of each row, and insert and update policies for saving.
Can VibeFix fix it for me?
Yes, if you ask. The free check confirms the problem first. Our AI agent can find the cause, fix it in your code and re-check your live app: $79 for one bug, paid up front. If we can't complete your re-check, you get your money back.
Sources (official documentation)
Related: Data won't save: "new row violates row-level security policy" · Is a secret key or admin page visible on my live app? · My builder says the app is tested, but my customers hit problems
VibeFix is independent. Lovable, Bolt, Replit, Base44, v0, Supabase, Firebase, Stripe and Vercel are trademarks of their owners.
Fixed it? Prove a real stranger gets in
A fix that works from your own account proves nothing about a new customer. Your AI reads your code. VibeFix signs up like a stranger.
Free check. Paste your live app's link: an AI agent signs up to your live app once as a brand-new person ("VibeFix Test") with a real inbox of its own, on a phone and on a computer, and shows how many problems a new user still hits, what each one is, and one screenshot. No account needed. It never changes your app and never emails your users.
Want it fixed?
Our AI agent finds the cause, fixes it in your code and re-checks your live app. $79 for one bug, paid up front. If we can't complete your re-check, you get your money back.
It starts with a free check that confirms the problem on your live app, no account needed.