How to secure a Lovable app before your first customers

Before real customers arrive, a Lovable app needs four checks: an access rule on every database table, no secret key in the browser, a backup you have already restored once, and the knowledge that on Lovable Cloud, since 23 October 2026, your experiments run on the same database as your customers. Lovable's built-in checks help, but its own documentation says they cannot guarantee complete security. Most of the checks in this guide need no coding.

Why does a Lovable app need checking before launch?

A Lovable app is a web application that keeps its data in Supabase, a hosted Postgres database. That database is either your own Supabase project or Lovable Cloud, which is built on the same technology (Lovable documentation). Your visitors' browsers talk directly to this database, using a public key that anyone can read in the page's code. What decides what that key allows is the database's access rules, called RLS (Row Level Security). They say, row by row, who may read or change what.

What protects your data in a Lovable app

1. BrowserThe visitor can read the public key
2. Public keyOpens access to the database API
3. RLS rulesDecide row by row
4. Supabase tablesYour customers' data

Supabase puts it this way: once RLS is enabled, no data is accessible through the API with a publishable key until you create policies (Supabase documentation). Lovable's documentation for Supabase-connected projects agrees: missing RLS policies are the most common way app data gets exposed (Lovable documentation).

The risk is not theoretical. In March 2025, a researcher analysed 1,645 Lovable projects and found 170 with inadequate access rules, about 10.3% (Matt Palmer's statement). The issue was assigned CVE-2025-48757. Lovable disputes that classification: according to the record, each customer of the platform is responsible for protecting their application's data (CVE record). Whether you call it a platform flaw or an oversight by the app's creator, the outcome for your customers is the same.

Lovable projects analysed and projects with inadequate access rules

• Projects analysed1,645 projects
• Inadequate access rules170 projects

05001,0001,5002,000projects

Step 1: an access rule on every table

Open your Supabase project, go to Advisors, then Security Advisor. This tool flags security problems in the database. Three alerts matter first (Supabase documentation):

• Table publicly accessible (error level): a table in the public schema has no RLS.
• Security policy allows unrestricted access (warning level): a rule exists but lets everyone through.
• Security policy relies on user-editable data (error level): the rule depends on a field the user can change themselves.

You can also check by hand in the SQL Editor. This query should return true on every row:

select tablename, rowsecurity from pg_tables where schemaname = 'public';

Then list the rules themselves:

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

A rule whose condition is simply true lets everyone through. On a private table, the condition should tie the row to the user, for example auth.uid() = user_id. A table with RLS enabled but no rule at all is closed to the app: that is safe, but check that the app does not need it.

Two traps come up often:

• Views. Supabase states that views bypass RLS by default, because they are usually created with the postgres user. On Postgres 15 or later, the security_invoker = true option makes them follow the tables' rules. Ask a developer to check it.
• Roles stored in user_metadata. The signed-in user can edit that field. The documentation recommends raw_app_meta_data (or a role table protected by RLS) for anything that concerns permissions.

On the Lovable side, a Quick scan runs automatically when you open the publish dialog. Among other things, it checks the database access rules. The Deep scan, which reviews the code, does not run on its own: you start it from the Security view. Lovable states that these tools help identify common security issues but cannot guarantee complete security, and it suggests a professional review for apps that handle sensitive data (Lovable documentation).

Step 2: the two-account test

Active rules are not enough if they let everything through. This test needs no coding:

1. Create two accounts with two test email addresses, A and B.
2. Signed in as A, create one item of each important type: a profile, an order, a document.
3. Note the address of each detail page: it often contains an identifier.
4. In a private browsing window, sign in as B and look for A's data (lists, search, exports), then paste the addresses you noted.
5. Repeat without being signed in at all.

If B sees anything of A's, stop everything else: this is the top priority.

Step 3: no secret key in the browser

Anything the browser downloads can be read by any visitor. Supabase distinguishes two families of keys (Supabase documentation):

• the publishable key (sb_publishable_…) may be exposed in a web page or an app;
• the secret key (sb_secret_…) bypasses RLS and must never be placed in a browser, a shipped app or a code repository.

The older anon key (the equivalent of the publishable one) and service_role key (the equivalent of the secret one) remain valid until you disable them, but Supabase says it is deprecating them by the end of 2026. If your project is old, now is the time to check which ones it uses.

To look for a secret key, open your app in Chrome, press F12, then Ctrl+Shift+F (Cmd+Option+F on Mac) to search every loaded file. Search for sb_secret_, service_role, sk_live_ (Stripe) and sk-proj- (OpenAI). In code, a variable whose name starts with VITE_ is sent to the browser by design: no secret key should carry that prefix.

Lovable provides a Secrets area for sensitive keys, and says its apps generally place API calls in server-side code so credentials stay out of the browser (Lovable documentation). If you find a secret key, removing it from the code is not enough: it stays in the GitHub history. Create a new one with the provider, store it in the secrets, redeploy, then disable the old one.

Private files (invoices, ID documents) deserve the same care. Supabase says storage buckets are private by default, but that anyone who has the file's address can open a file in a public bucket (Supabase documentation). Open the address of a private document in a private browsing window: it should not display.

Step 4: a backup you have already restored

Backup rules depend on where your database lives.

Backups depending on where your database lives

Where the database is	Automatic backups	What is not covered
Lovable Cloud	One per day, kept for about 14 days	Storage files
Supabase, Pro plan	Daily, 7 days (PITR optional)	Storage files
Supabase, Team plan	Daily, 14 days (PITR optional)	Storage files
Supabase, free plan	Not specified: export it yourself	Anything you do not export

On Lovable Cloud, Lovable backs up the database every day and keeps about 14 days of backups. You find them under More, Database, Manage, Backups. Three points from the documentation matter: restoring rolls the database back to that point, structure and data, and anything created afterwards is lost; a restore cannot be undone; and the app's code may no longer match the restored database if the structure changed in the meantime (Lovable documentation). You can also export the database (More, Database, Manage, Settings), for databases up to 15 GB, once every 24 hours. Backups and exports cover the database only: files are downloaded separately.

If you connected your own Supabase project, the backup does not come from Lovable: Lovable states that you manage backups in Supabase. Supabase keeps daily backups for 7 days on the Pro plan, 14 days on Team and up to 30 days on Enterprise, with point-in-time recovery (PITR) as an option. For the free plan, the documentation recommends exporting your data regularly with the supabase db dump command and keeping copies outside Supabase. Its backups do not include files stored through the Storage API, and the project is inaccessible during a restore (Supabase documentation).

Run a real test, once before your first paying customers:

1. Restore a backup next to production, never on top of it. On Supabase, restoring to a new project is limited to paid plans.
2. Watch out for scheduled jobs: according to Supabase, pg_cron and pg_net jobs start as soon as the restore completes, with no way to pause them. A copy must not send real emails (Supabase documentation).
3. Compare the row counts of the main tables with production, then sign in with a test account.
4. Write down the duration and the obstacles in a one-page procedure.

Step 5: do not mix up test and production

This is the point that changed most recently. Lovable retired its separation between a test database and a production database (Test and Live) on 23 October 2026. Every project on the built-in backend now runs on a single database, and Lovable states that nothing was deleted on 23 October and that apps were not taken offline (Lovable documentation).

The end of Test and Live on Lovable

1. 14 Sept 2026NoticeAffected owners receive an email.
2. 23 Oct 2026One databaseTest and Live are retired, Test databases are detached.
3. 1 Dec 2026DeletionTest databases are deleted and can no longer be restored.

What this means in practice:

• Drafts do not give you a second database: they use the same database as the published app. If you edit or delete an existing record, it changes for the published app too (Lovable documentation).
• Publishing copies the structure (schema, RLS policies, functions) but not the data. Lovable asks you not to rely on it to migrate data.
• According to Lovable, Test databases are permanently deleted on 1 December 2026. If useful data was still in there, recover it before that date: a restore request remains possible until then.

As long as you stay on the built-in database, run your experiments with test accounts, never customer accounts, and export the database before every major change. For a real separation, you need a second database: one Supabase project of your own for production, another for tests. Lovable states that it does not move a project from the built-in backend to your own Supabase in one step: you export the database, move the files, then set up authentication, secrets and external services again. That is a job for a developer.

On a Supabase-connected project, Lovable saves structure changes in the repository's supabase/migrations/ folder. Check that it exists: that history is what lets you rebuild the database identically for a test.

In what order should you do these checks?

Before your first paying customer

• RLS on every tableSecurity Advisor with no error, no rule that is simply true.
• Two-account testB sees nothing of A's, and neither does a visitor without an account.
• No visible secret keySearch in the browser, then replace keys if needed.
• Private files closedA private document's link does not open without signing in.
• Backup restoredA test next to production, dated and written down.
• Test database or careful testingTest accounts only, export before every big change.

The first three lines concern your customers' data: handle them before any launch. Backups come next, because data lost without a backup cannot be recovered. Separating test from production can follow, with a developer.

My view as a CTO

I launched BabyCheck in 14 days, so I will not tell you that fast tools are a problem. Lovable is a good way to validate an idea, and Techvisor builds MVPs and SaaS products with Next.js, Supabase and Flutter. The real work starts when real users arrive: a screen that works says nothing about what the database lets through. I co-founded Welco in 2019 and I am its CTO: the app has more than 150,000 sign-ups, and at that scale each user's data is the first thing to protect. So I always follow the same order: access rules and keys first, backups second, separating test from production last. A check built into the tool is a good first filter, not an independent opinion.

Frequently asked questions

Is Lovable's security scan enough?

Not on its own. Lovable states that its scans help identify common issues but cannot guarantee complete security, and that you remain responsible for your app's security requirements. Run them, fix what they flag, then do the two-account test as well.

My app uses Lovable Cloud: do the same checks apply?

Yes. Lovable Cloud is built on Supabase's technology, so access rules, secrets and functions are checked the same way. What differs is the backup: Lovable provides it (one per day, about 14 days kept) instead of Supabase.

Do I need to leave Lovable to secure my app?

No. Lovable syncs the project with a GitHub repository, and hosts such as Vercel or Netlify can deploy the app from that repository (Lovable documentation). You can also keep evolving the app in Lovable while protecting what matters on the database side. Moving the database to your own Supabase is a separate project, to do with a developer.

How much does an outside review of my app cost?

At Techvisor, the express diagnostic costs €1,200 excl. VAT for about 3 working days, and the full audit with a costed roadmap costs €2,400 excl. VAT for about 5 working days. These durations are estimates. Access is read-only and removed at the end.

When should I do these checks?

Before the first customer who leaves personal data or pays, then after every change that touches the database. Also check your keys before the end of 2026 if your project still uses the old anon and service_role keys.

Next step

To run these checks in order on your app, the playbook « Reprendre une app créée avec Lovable, Bolt ou Replit » (in French) details each step: how to check, what good looks like, and what needs a developer. The app takeover page summarises Lovable's points of attention.

If you prefer an outside view of your database and code, the app audit gives a green, amber or red light for each point, with examples from your app and a plan. To find out whether it fits your situation, book a 15-minute call. The call costs nothing and comes with no commitment.

Sources

• Lovable, Security, Lovable Cloud, Supabase integration, Back up, restore and export your database, End of Test and Live environments, Drafts, Deploying and hosting outside Lovable (documentation checked on 13 November 2026)
• Supabase, Row Level Security, Advisors, API keys, backups, restoring to a new project, Storage buckets (documentation checked on 13 November 2026)
• CVE, CVE-2025-48757 record (Lovable disputes the classification as a vulnerability)
• Matt Palmer, statement on CVE-2025-48757 (source of the 1,645 projects analysed and the 170 affected)