By Get an engineer for this one. Needs correct policies on every table, then testing.
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
- 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.
- 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, nevertrue. - 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.uidto the record's owner. - Ask the agent to add a
user_idcolumn to every table that lacks one, fill it for existing rows, and write select, insert, update, and delete policies for each table. - Repeat step 1 after every change, and also test as a logged-out visitor.
- If customer data was exposed, write down what and when. Privacy law may require telling affected users (see do I need a privacy policy).
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 and 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.
- 1Redlab10.0/10Best for: A full rescue by one team that keeps buildingFree first step · from $490
- 2Vibe Code Rescue (Lev Arakelyan)9.0/10Best for: A one-off check and a cleanupFrom $299
- 3LazyCodeLab9.0/10Best for: A one-off check and a cleanupFrom $399
Check these
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.
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.
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.
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.
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; Firebase: Basic Security Rules; Statement on CVE-2025-48757; vibe-eval: Vibe coding security monthly, Aug 2026.