Why can users see other users' data?

The root cause

If User A can see User B's data, the database is returning rows it shouldn't. In a Lovable Cloud/Supabase app, that's a Row Level Security (RLS) problem, not a front-end bug — even if the leak is only visible through the UI.

Where to look

• RLS disabled entirely on the table. Anyone with the app's public key can then query all rows.
• A SELECT policy that's too broad, e.g. using (true), which allows any authenticated (or even anonymous) user to read every row.
• A policy checking the wrong column, such as comparing against a table ID instead of the row's user_id.
• Roles stored on the user's own profile row in a way that lets them read or infer other users' data through a join.

How to fix it

1. Ask Lovable to list RLS policies on the affected table.
2. Confirm there's a policy restricting SELECT (and UPDATE/DELETE) to auth.uid() = user_id, or the equivalent ownership check.
3. Re-test by logging in as two different accounts and confirming each only sees their own rows.

Check the RLS policies on messages — a logged-in user can currently see other users' messages. Restrict SELECT so users only see rows where they're the sender or recipient.

What usually goes wrong

• Fixing the UI to "hide" other users' rows instead of fixing the database policy — this only hides the leak from casual use; the data is still reachable via the API.
• Joins across tables where the joined table has no RLS of its own, leaking data indirectly even though the main table looks correctly locked down.
• Assuming a feature "worked in testing" — testing with only one account never surfaces this class of bug. Always test with at least two accounts.

This is a serious issue if it reaches production with real users. If you've found this in a live app, treat it urgently and consider a focused security review — PromptSites.com can audit RLS policies quickly if you want a second pair of eyes.

Related: /questions/what-is-row-level-security-rls, /questions/how-do-i-fix-rls-errors.