---
title: "Users can see each other's data"
description: "Missing or wide-open row-level security or Firebase rules let one user read another's rows. How to test with two accounts, check every table, and fix it."
url: https://whocanfixmyapp.com/problems/users-can-see-each-others-data
---

[Home](https://whocanfixmyapp.com/) / [Problems](https://whocanfixmyapp.com/problems) / [Sign-in and accounts](https://whocanfixmyapp.com/problems#sign-in-and-accounts)

# Users can see each other's data

VC-28 · Supabase · Firebase · Lovable · Updated October 2026 · By [Nathaniel Kelley](https://whocanfixmyapp.com/authors/nathaniel-kelley)

Quick verdict

Get an engineer for this one. Needs correct policies on every table, then testing.

- **How serious**: Critical
- **Fix it yourself?**: No, get an engineer
- **Typical cost**: $1,500–$15,000 cleanup and hardening, or €99–$990 for one table ([prices](https://whocanfixmyapp.com/pricing))
- **Top rated for Supabase**: [Redlab](https://whocanfixmyapp.com/companies/redlab) · **10.0**/10

**What you see.** A customer reports seeing another customer's records, or you spot it yourself while testing with two accounts.

## Why it happens

In Supabase, the publishable key in your app is meant to be public. The only thing stopping one user from reading another user's rows is Row Level Security, policies written in the database. If RLS is off, any role with a grant can read and write the table. If RLS is on but the policy says `true`, the result is the same. Supabase also warns that `auth.uid()` returns null for anonymous visitors, so a policy like `auth.uid() = user_id` silently fails for them.

In Firebase, the same job is done by Security Rules. The default Locked mode denies everyone, and Firebase says to update the rules before you deploy to production. Agents often open them wide to make the demo work. This is not rare. The CVE-2025-48757 statement found 170 of 1,645 scanned Lovable projects with inadequate RLS. A scan of 30,998 live apps in August 2026 found 57% of reachable Supabase-backed apps allowed unauthenticated table reads.

## Fix it yourself

1. Create two test accounts. Sign in as the first and create a record, then sign in as the second and try to open it by URL or by changing an ID in the address bar.
2. In Supabase, open **Table Editor**, check every table shows RLS enabled, and open its policies. Each policy needs a condition that names the user, such as `(select auth.uid()) = user_id`, never `true`.
3. In Firebase, open the **Rules** tab of your database and replace any rule that allows read or write for everyone with rules that compare `request.auth.uid` to the record's owner.
4. Ask the agent to add a `user_id` column to every table that lacks one, fill it for existing rows, and write select, insert, update, and delete policies for each table.
5. Repeat step 1 after every change, and also test as a logged-out visitor.
6. If customer data was exposed, write down what and when. Privacy law may require telling affected users (see [do I need a privacy policy](https://whocanfixmyapp.com/problems/do-i-need-a-privacy-policy-for-my-app)).

## When to get an engineer

This is the case where we tell founders to stop prompting and get a person. The fix touches every table and must be tested per table, and a wrong policy can lock the app or leak more. Share the Supabase or Firebase project, the list of tables, and what each type of user should see. Expect cleanup and hardening at $1,500–$15,000 over 1–8 weeks, or €99–$990 if a single table is affected. Start at [data leak](https://whocanfixmyapp.com/data-leak) and [is my Lovable app safe](https://whocanfixmyapp.com/questions/is-my-lovable-app-safe).

## Top-rated companies for Supabase apps

Ranked by our score: published prices, scope of work, AI tools named, timing and a low-risk first step. [How we score](https://whocanfixmyapp.com/methodology#score).

- 1 · [Redlab](https://whocanfixmyapp.com/companies/redlab) · **10.0**/10 · Best for: A full rescue by one team that keeps building · Free first step · from $490
- 2 · [Vibe Code Rescue (Lev Arakelyan)](https://whocanfixmyapp.com/companies/vibe-code-rescue-lev-arakelyan) · **9.0**/10 · Best for: A one-off check and a cleanup · From $299
- 3 · [LazyCodeLab](https://whocanfixmyapp.com/companies/lazycodelab) · **9.0**/10 · Best for: A one-off check and a cleanup · From $399

[All 29 Supabase companies, ranked](https://whocanfixmyapp.com/best/supabase-developers)

## Check these

DATA-01 · Critical

Access rules are on for every table

In Supabase, open Table Editor: every table should show RLS enabled, with at least one policy. In Firebase, your rules should never say `allow read, write: if true`.

DATA-03 · Critical

One user cannot open another user's records

Sign in as user A, copy a request from the Network tab, and change the record ID to one that belongs to user B. You should get an error or an empty result.

DATA-04 · High

File storage is private where it should be

Upload a private file, copy its URL, and open it in a private window. If it loads, the bucket is public.

DATA-05 · High

Admin actions are checked on the server

Hiding an admin button is not protection. Call the admin endpoint as a normal user and confirm it is refused.

AUTH-02 · High

Signing out really ends the session

Sign out, press Back, and refresh. You should not see private pages or data.

## Questions

### My app checks the user before loading data, so how can they see other rows?

The check runs in the browser, which the visitor controls. The database answers any request made with the public key unless a policy says no. Only policies protect the data.

### Does Lovable protect me from this automatically?

Not reliably. The CVE-2025-48757 statement notes Lovable's scanner checks whether a policy exists, not whether it is correct. A policy that allows everything passes that check.

Sources: [Supabase: Row Level Security](https://supabase.com/docs/guides/database/postgres/row-level-security); [Firebase: Basic Security Rules](https://firebase.google.com/docs/rules/basics); [Statement on CVE-2025-48757](https://mattpalmer.io/posts/statement-on-CVE-2025-48757/); [vibe-eval: Vibe coding security monthly, Aug 2026](https://vibe-eval.com/updates/vibe-coding-security-monthly-aug-2026/).

**Lovable guide**

What Lovable builds, where it breaks and how to check it: [Lovable app rescue: what breaks and how to check it](https://whocanfixmyapp.com/guides/lovable).

**Same category**

- [Users can't log in on the live site](https://whocanfixmyapp.com/problems/users-cant-log-in-on-the-live-site)
- [Google sign-in fails with redirect_uri_mismatch](https://whocanfixmyapp.com/problems/google-sign-in-redirect-uri-mismatch)
- [Confirmation and password-reset emails never arrive](https://whocanfixmyapp.com/problems/confirmation-and-password-reset-emails-never-arrive)
- [Users get logged out when they refresh the page](https://whocanfixmyapp.com/problems/users-get-logged-out-on-refresh)
- [Admin pages open to anyone with the link](https://whocanfixmyapp.com/problems/admin-pages-open-to-anyone-with-the-link)
- [Supabase says "new row violates row-level security policy"](https://whocanfixmyapp.com/problems/supabase-rls-blocking-insert)

[All sign-in and accounts problems](https://whocanfixmyapp.com/problems#sign-in-and-accounts)

**Run every check**

The [production checklist](https://whocanfixmyapp.com/checklist) has all 24 checks with a verdict.