Users can see other users' data in my Lovable app

Short answer: if one signed-in user can see another user's records, your database is answering everyone, and your app is only hiding the extra rows on screen. The fix is a database rule called row-level security (RLS) on every table that holds user data, with a policy that lets each person read only their own rows. Check it on the live app with two accounts, fix it with one prompt to your builder, then check again.

It's more common than it sounds. Of 28 live apps people pasted into our free test (27 September to 3 October 2026), 5 let anyone read data that should be private, from other users' records to an API key.

Check it in 5 minutes

Do this on your published app, not the preview.

1. Open your app in a private window and sign up as user A. Create something private: a booking, a note, a profile detail.
2. Open a second private window (or another browser) and sign up as user B.
3. As user B, look everywhere user A's data could appear: lists, search, dashboards, profile pages, admin pages.
4. Copy the address of one of user A's pages (for example a booking or profile link) and open it as user B, then again signed out.
5. If user B, or a signed-out visitor, sees anything of user A's, you have the problem.

Step 4 matters most. Some apps hide other people's rows in the list, but still show a record to anyone who has its link.

Why it happens

• Row-level security is off on a table. Supabase's own docs say a table in an exposed schema without RLS "is readable and writable by any role with a grant on it". Your app's public key is in the browser, so "any role" includes any visitor.
• A policy lets everyone through. RLS is on, but a rule like using (true) allows every row for every user. Lovable's security 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. Anyone who looks at what the browser received sees everyone's.
• Files are in a public storage bucket. Uploaded documents or photos can be opened by anyone with the address.
• A secret key is in the browser code. A service or admin key in front-end code bypasses every rule.

Fix it in Lovable

1. In your project, open the Security view and click Run deep scan. Lovable's deep scan checks access control and "exposed personal and sensitive data". The quick scan runs on its own when you open the publish dialog, but it checks less.
2. Paste this into Lovable's chat, one table at a time if it has many:

Users can see other users' data on my LIVE site. Turn on row-level security for every table that stores user data, and add policies so each signed-in user can read, update and delete ONLY rows where user_id equals auth.uid(). Remove any policy that allows everyone (using (true)). Make storage buckets with user files private. Make sure no service-role or secret key is in front-end code. Then list every table and bucket and the rule on each.

1. Read the list it gives back. Every table with user data should say "own rows only". Any table that should be public (for example a product catalog) should be read-only for everyone.
2. Publish, then repeat the 5-minute check on the live app, with both accounts and signed out.

The rule it should write for reading your own rows looks like this (from Supabase's docs): create policy "Users can view their own profile." on profiles for select to authenticated using ( (select auth.uid()) = user_id );

Built with something else?

The same check works for any builder: two accounts, one shared link, one signed-out visit. Apps on Supabase (Bolt and others) use the same fix. On other databases, ask your builder for the same outcome in plain words: "each user can only read and change their own records, enforced by the database, not just hidden on screen."

Why a scan isn't the last step

Lovable's docs say its scans "cannot guarantee complete security" and "do not replace a thorough security review". A scan reads your setup. The two-account test shows what a real second user actually gets on the live site, and that's the proof that matters.

Check your live app now: paste your link at vibe-fixer.com. An AI agent signs up and uses your live app like a first customer, shows what it found, gives you the exact fix for one problem to paste into your builder, free, then re-tests the live app to prove it.

Related: Data won't save: row-level security errors · Test your live app like a real customer · Who can fix my vibe-coded app?