Lovable users can see each other's data

As of October 10, 2026, when one signed-in user of a Lovable app can see another user's records, the usual cause is the database's access rules, not the screens. Either a table has no rule saying a user may only read their own rows (row-level security, RLS), or the rule only checks that someone is signed in. Less often, a server function or a storage bucket skips the check. The fix is to turn RLS on for every table, write rules that compare each row's owner with the signed-in user, and prove it with two test accounts. Hiding the data on screen is not a fix.

This guide is for founders who built their app in Lovable and have just seen, or been told, that one customer's data shows up for another. It covers the likely causes in plain English, how to confirm the problem yourself without making it worse, what to do first if real customer data was exposed, the fix, and how to keep it fixed. Platform facts come from Lovable, Supabase, the FTC and the US National Vulnerability Database, listed under Sources.

Why can one Lovable user see another user's data?

Your app's screens talk to its database straight from the browser. Lovable Cloud is built on Supabase, and a Supabase app ships a publishable key that any visitor can read. That is by design. What protects the data is a set of rules inside the database that decide which rows each request may touch. Supabase calls them row-level security policies. When they are missing or too loose, the screen is the only thing filtering the data, and anyone can get around a screen.

Lovable's documentation says it sets up these rules automatically when it builds features that store user data. A rule that exists is not the same as a rule that is right. These are the six usual causes:

The second cause is the one founders miss. Supabase's documentation explains that the authenticated role only means a user is signed in, while a check of auth.uid() against the row's user_id limits access to the row's owner. If anyone can sign up for your app, being signed in proves nothing. A competitor with a free account counts as signed in.

Server code has the same trap. Lovable's security guide says server-side code that uses the service role bypasses RLS, so that code must check permissions itself, and that a function running on the server is still callable by a client. Supabase's edge function guide gives the exact failure: a function that queries a shared table with the privileged client, without filtering by the caller's ID, returns every user's rows.

Supabase says its secret and service role keys are never safe to expose, because they bypass RLS. If one is in your code, follow our guide to an exposed Lovable API key. For files, anyone with the URL of a file in a public Supabase bucket can open it. Lovable Cloud keeps buckets private by default and blocks public ones unless a workspace owner or admin allows them.

This is a known pattern. CVE-2025-48757, scored critical at 9.3, describes insufficient RLS policies in Lovable-generated sites up to April 15, 2025. Lovable disputes it, saying each customer is responsible for their own app's data. The wider picture is in vibe coding security risks.

How can you check if your Lovable app is leaking data?

Use test accounts you create yourself. Never confirm a leak by browsing a real customer's records. Work through these steps in order:

1. 01Make two test accountsSign up as user A and user B with two email addresses you own. As A, create one of everything your app stores: a profile, an order, a note, an upload.
2. 02Look as user BSign in as B in a private browser window. Check every list, search box and dashboard. Then copy the address of one of A's record pages and open it in B's window. If B sees anything of A's, the leak is confirmed.
3. 03Do not trust a clean screenIf B sees nothing, the screens may simply be filtering. The database could still hand everything to anyone who asks it directly. The next checks look at the rules themselves.
4. 04Run Lovable's deep scanIn the editor, open More, then Security, and run a Deep scan. Lovable's docs say it reviews your code for issues specific to your app's logic, permissions and data, usually in 3 to 13 minutes, at no credit cost. Read every finding under access control and exposed personal data.
5. 05Read the rulesOn Lovable Cloud, open More, Cloud, Database, then RLS policies. Look for rules whose condition is true, or that never mention the user's id. On your own Supabase project, open the Table Editor, which shows a warning label on any table with RLS disabled. Then open the Security Advisor and look for rls_disabled_in_public, permissive_rls_policy and sensitive_columns_exposed.
6. 06Check file storageOn Lovable Cloud, More, Cloud, then Storage shows each bucket as Private or Public. Any bucket holding customer documents should be Private.

Lovable's quick scan on every publish checks database access rules and RLS. It catches a table with no rules, but cannot know that an invoice belongs only to the customer who paid it. Our guide to the Lovable security scan explains what it checks and what it leaves to you.

Real customer data was exposed. What should you do first?

Work in this order, and keep a record as you go.

1. Close the hole: fix the rule or make the bucket private, as described below. Unpublishing alone is not enough. It takes the live URL offline, but the database answers on its own address until the rules change.
2. Revoke any secret key that was exposed, at the provider, and replace it with one stored on the server.
3. Save the evidence. The FTC's breach response guide says not to destroy forensic evidence while you investigate and fix. Logs expire fast: Lovable Cloud's Logs view keeps up to 5 days, and Supabase keeps API and database logs for 1 day on Free, 7 on Pro, 28 on Team and 90 on Enterprise. Export or screenshot them now.
4. Work out what was exposed: which tables and columns, since when, and whether anyone outside your test accounts read them. Names and emails are serious. Health, financial or government ID data is more serious still.
5. Get advice before you notify. The FTC says all states, the District of Columbia, Puerto Rico and the Virgin Islands have laws requiring notification of security breaches involving personal information. Health data can also fall under the HIPAA Breach Notification Rule or the FTC's Health Breach Notification Rule. Which rules apply depends on the data and where your users live, so ask a lawyer with privacy experience. This guide is not legal advice.
6. Tell affected customers plainly: what happened, which data, what you have fixed and what they should do.

Our guides to which rules your product must meet and whether Lovable is HIPAA compliant cover the regulations in more depth. The glossary entry on incident response explains the wider process.

How do you fix it so each user sees only their own data?

Give every table a rule that compares the row's owner with the signed-in user. In Supabase's terms, the policy checks auth.uid() against the row's user_id column, not merely that the request comes from a signed-in user. Data a team shares needs a membership table your server controls. Admin access needs roles stored where users cannot edit them. Tested SQL for each pattern is in our Supabase RLS policy examples, and roles are covered in Lovable authentication and user roles.

Lovable writes policies and edits functions well. It cannot guess your business rules, such as whether a manager sees their staff's records, so state them in the prompt. It also cannot tell you whether anyone already read the data. That is what the logs are for.

Expect something to break after the fix. Supabase's advisor describes a table with RLS on and no policy as one where no data can be read or written through the API. An empty screen afterwards is the rule working. Add the narrowest policy that lets the feature work. Never fix it with a rule that is always true.

How do you keep it from coming back?

Every new table, function and prompt can reopen the hole. Keep it closed with tests:

• Write automated tests that sign in as user A, user B and an anonymous visitor, and try to read and change each other's rows through the database API, not the screens. Run them on every change. Our guide on how to test an AI-built app shows the setup.
• Rerun the two-account check by hand after any prompt that touches data, sign-in or roles. A prompt that makes an error go away can do it by widening access.
• Run Lovable's deep scan before each release and, on your own Supabase project, the Security Advisor after each database change.
• Keep the full list of checks in one place. Ours is the Lovable security checklist.

These are regression tests: they prove that something fixed once stays fixed. Where many customers share one database (multi-tenancy), they matter most.

When should you stop prompting and get help?

Prompting is fine for a prototype with test data. Get an engineer involved when any of these is true:

• Real customer data was exposed, or may have been, especially health, financial or children's data.
• Customers pay you, or teams share data inside your app.
• The same leak has come back after a fix, or you have prompted three times without a clean two-account test.
• You cannot tell which tables hold personal data, or who wrote the policies.
• An edge function uses the service role and you cannot read what it does.

Our vibe-coding rescue service is built for this moment: engineers find every path to the data, close it and add the tests that keep it closed. If you are not sure how exposed you are, start with the free production-readiness check.

Ongoing, a Plutonapps plan puts code review, security checks and tests on every change you prompt, so a new table never ships without its rules. Plans are on our pricing page.

Sources

All checked on October 10, 2026.

• Lovable documentation: Security overview, on the quick and deep scans and their limits (docs.lovable.dev/features/security).
• Lovable documentation: Project security view, on where to run a deep scan and how long it takes (docs.lovable.dev/features/security-view).
• Lovable documentation: Security best practices, on server code that uses the service role and server functions being callable by clients (docs.lovable.dev/tips-tricks/security-best-practices).
• Lovable documentation: Database, on RLS rules Lovable creates and the RLS policies view (docs.lovable.dev/features/database).
• Lovable documentation: Storage, on private and public buckets in Lovable Cloud (docs.lovable.dev/features/storage).
• Lovable documentation: Logs, on log types and the 5-day window (docs.lovable.dev/features/logs).
• Lovable documentation: Publish your Lovable project, on unpublishing (docs.lovable.dev/features/publish).
• Lovable documentation: Lovable Cloud, on Cloud being built on Supabase (docs.lovable.dev/features/cloud).
• Supabase documentation: Row Level Security, on the authenticated role, auth.uid() and the service role (supabase.com/docs/guides/database/postgres/row-level-security).
• Supabase documentation: Securing your data, on publishable, secret and service role keys (supabase.com/docs/guides/database/secure-data).
• Supabase documentation: API keys, on secret keys being refused in browsers (supabase.com/docs/guides/api/api-keys).
• Supabase documentation: Database advisors, on rls_disabled_in_public, permissive_rls_policy, rls_enabled_no_policy and sensitive_columns_exposed (supabase.com/docs/guides/database/database-advisors).
• Supabase documentation: Securing Edge Functions, on privileged clients returning every user's rows (supabase.com/docs/guides/functions/auth).
• Supabase documentation: Storage buckets, on public bucket access (supabase.com/docs/guides/storage/buckets/fundamentals).
• Supabase blog: Supabase Security Retro: 2025, on the Table Editor's warning label for tables with RLS disabled (supabase.com/blog/supabase-security-2025-retro).
• Supabase: Pricing, on log retention by plan (supabase.com/pricing).
• US National Vulnerability Database: CVE-2025-48757, on the description, score and supplier dispute (nvd.nist.gov/vuln/detail/CVE-2025-48757).
• Federal Trade Commission: Data Breach Response: A Guide for Business, on evidence, state notification laws and health breach rules (ftc.gov/business-guidance/resources/data-breach-response-guide-business).