Lovable app data leak checklist before launch

A Lovable app can feel ready because the generated flow works in preview. The risk is that preview success does not prove data isolation. The app may still expose private rows, files, API responses, old project links, debug data, or keys that let someone bypass the intended UI.

This checklist is written for founders who are asking practical launch questions: can users see each other's data, is my Supabase setup safe, did Lovable generate a public route, and do I need to block launch before real users arrive?

Why Lovable apps can leak data

Lovable is useful because it can generate the app quickly. That speed also means the app may contain assumptions that were never explicitly reviewed. The generated UI might hide data correctly while the underlying database policy, storage bucket, or API route is too open.

Common leak paths include:

• Old preview links connected to real services.
• Public pages that load private API responses.
• Supabase tables without the right RLS policies.
• Storage buckets that expose private uploads by URL.
• Generated API routes that return data before checking ownership.
• Service role keys or backend secrets exposed to browser code.

Step 1: Check old preview and public project links

Start by finding every public place where the app can be opened. Lovable projects often move through drafts, previews, shared links, custom domains, and redeployments. Any one of those can become a leak if it still points to live data.

Check:

• Current production domain.
• Lovable preview links shared with friends, clients, or testers.
• Old preview URLs in chat, email, GitHub, Notion, or Linear.
• Public demo links and staging deployments.
• Whether old links still use production Supabase, Stripe, or API keys.

If an old preview can reach real user data, treat it like production. Either secure it, disconnect it from production services, or remove it.

Step 2: Check logged-out access

Open the app in a private browser window with no session. Do not only click through the normal homepage. Try direct URLs and API calls.

1. Open dashboard, account, settings, billing, admin, and project URLs while logged out.
2. Refresh private pages after logout.
3. Use browser devtools to copy API route URLs and call them logged out.
4. Try file URLs, image URLs, generated report URLs, and export links.
5. Check whether the app returns private JSON before redirecting the page.

A safe app should deny the data request itself, not only redirect the interface after the data already loaded.

Step 3: Check User A / User B data isolation

This is the most important Lovable data leak test. Create two normal users. Add private records, files, messages, settings, payments, or reports for each user. Then try to cross the boundary deliberately.

1. Log in as User A and create private data.
2. Log in as User B in another browser.
3. Try to open User A's URLs while logged in as User B.
4. Change IDs in URLs, request bodies, and query parameters.
5. Try to list records and look for User A rows in the response.
6. Try to update or delete User A data as User B.

If User B can read, list, update, delete, download, or overwrite User A data, the app is not ready to launch.

Step 4: Check Supabase RLS and policies

Many Lovable apps use Supabase. The key question is not whether the UI looks scoped to the current user. The key question is whether Supabase enforces that scope when someone calls the API directly.

Check which public tables have RLS enabled:

select
  c.relname as table_name,
  c.relrowsecurity as rls_enabled
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where c.relkind = 'r'
  and n.nspname = 'public'
order by c.relname;

Then inspect the policies:

select
  tablename,
  policyname,
  cmd,
  roles,
  qual,
  with_check
from pg_policies
where schemaname = 'public'
order by tablename, policyname;

For private tables, be suspicious of broad policies like USING (true), missing auth.uid() checks, missing workspace checks, or update policies without WITH CHECK.

For a deeper walkthrough, use the Supabase RLS checker for Lovable and Cursor apps.

Step 5: Check storage buckets and file URLs

Files are a separate leak surface. Even if table rows are protected, private uploads may still be public if storage policies or signed URL behavior are wrong.

Test these paths:

• User A uploads a private image, PDF, CSV, audio file, or generated report.
• User B tries to open the file URL directly.
• User B tries to list the bucket or folder.
• User B tries to overwrite or delete the file.
• A logged-out visitor tries the same URL.
• Signed URLs expire and are not reused as permanent public links.

Do not assume "unlisted" means private. If a file URL works for the wrong user, it is a leak.

Step 6: Check exposed service role keys

A Lovable app should not expose backend secrets to browser code. Supabase publishable keys can appear in frontend apps when RLS is correct. Service role and secret keys cannot.

Search for:

• service_role
• SUPABASE_SERVICE_ROLE
• sb_secret_
• STRIPE_SECRET_KEY
• OPENAI_API_KEY or other paid provider keys
• Secrets inside NEXT_PUBLIC_, VITE_, or PUBLIC_ variables

Search source files, deployed JavaScript, source maps, logs, Git history, screenshots, and prompts pasted into project docs. If an elevated key was exposed, rotate it and verify what it could access.

Step 7: Check API routes generated to make the app work

AI tools often add API routes, Edge Functions, server actions, or RPC functions to make a feature work quickly. Those routes can accidentally bypass the stricter checks in your UI.

For each route that reads or writes private data, ask:

• Does it verify the user is logged in?
• Does it verify ownership of the record, file, workspace, or organization?
• Does it verify the user's role before admin-like actions?
• Does it validate IDs from the request body instead of trusting them?
• Does it use a service role key only after doing its own authorization check?
• Does it avoid returning more rows than the UI needs?

Any route using elevated access should be treated as a high-risk review target.

Step 8: Check forms and hidden fields

Do not trust hidden form fields, disabled fields, dropdown values, or the fact that the Lovable UI only shows valid options. A user can edit requests in devtools.

Try to submit:

• Another user's user_id.
• Another workspace or organization ID.
• An admin role, paid plan, extra credits, or elevated permission.
• HTML, scripts, very long text, empty fields, and invalid enum values.
• Duplicate requests and old deleted IDs.

The server should reject forged ownership and role changes even if the frontend never offered those options.

Step 9: Check billing and paid-feature data

Data leaks are not only about profile rows and files. Billing state can leak too. A user might see another customer's plan, invoice metadata, usage, workspace seats, or paid outputs if Stripe and Supabase state are linked incorrectly.

Test:

• User B cannot see User A invoices, plan state, or billing email.
• A canceled user cannot keep accessing paid-only records.
• Failed-payment state does not expose paid features permanently.
• Webhook replay does not duplicate credits or grant access to the wrong workspace.
• Plan limits are checked server-side before private or expensive data is returned.

Lovable app data leak checklist

1. Every public and old preview URL is known and either secured or disconnected from production data.
2. Logged-out visitors cannot load private pages, API responses, files, reports, or exports.
3. User B cannot read, list, update, delete, download, or overwrite User A data.
4. Supabase private tables have RLS enabled and policies match user or workspace ownership.
5. Storage buckets and file URLs are tested separately from table RLS.
6. Service role keys and backend secrets are not in frontend code, public env vars, source maps, logs, or Git history.
7. API routes, RPC functions, Edge Functions, and server actions enforce authorization before using elevated access.
8. Forms reject forged ownership, roles, plan values, and workspace IDs server-side.
9. Billing, invoices, paid features, and usage data are scoped to the correct user or workspace.

Launch verdict

Block ship if the wrong user can access private data, storage files are public, RLS is missing on private tables, or a service role key is exposed.

Ship with fixes if User A / User B table isolation passes, but old previews, file access, API routes, or billing edge cases are still unverified.

Clear to ship when logged-out access, User A / User B isolation, Supabase RLS, storage, secrets, API routes, forms, and billing data all pass.