whocanfixmyapp

Home / Problems / Question

Is my Lovable app safe?

Updated October 2026By

Quick answer

Only if the database access rules are right, and Lovable cannot tell you that on its own. Its scan checks that a rule exists on each table, not what the rule allows, so you or an engineer must test the app with two accounts before real users sign up.

Applies to
Lovable
Checks to run
DATA-01, DATA-02, DATA-03, DATA-04, PAY-01

A Lovable app has two halves. The screens are React code that Lovable writes. The data lives in Supabase, either a project you own or Lovable Cloud, which is Supabase run by Lovable. The browser talks to that database directly with a public key. That is normal. What keeps one customer out of another customer's records is a set of rules on each table called Row Level Security, or RLS. If a rule is missing or too loose, anyone can read the table. No hacking skill is needed.

This is not a rare mistake. In May 2025, a scan of 1,645 Lovable projects found 170 with open tables (CVE-2025-48757). In August 2026, a scan of 30,998 live AI-built apps found that 57% of the reachable Supabase-backed ones allowed unauthenticated table reads. Lovable now runs a Quick scan every time you publish. Its own docs say the scans cannot guarantee complete security and suggest an additional professional security review for sensitive apps. The researcher behind the CVE also noted the scanner checks whether a policy exists, not whether it is correct.

What to check on your own project:

  • Open the publish dialog and read the Quick scan results. Then run a Deep scan from the Security view. Fix every critical finding before you publish.
  • Open Database, Manage, Policies. Any policy that reads using (true) lets everyone through. A policy should compare the row owner to auth.uid().
  • Create two test accounts. Sign in as the first, then try to open a record that belongs to the second by changing the ID in the address bar or in a request. You should get nothing back.
  • On the live site, open the browser's developer tools and search the loaded code for sb_secret_ and service_role. Neither should appear. A publishable or anon key is fine.
  • If you take payments, confirm a server function receives the Stripe webhook and checks its signature before it unlocks anything.

Money and time. A one-off check of these points costs $49–$800 and takes a day to a week. Each fix after that is €99–$990 and about two days. If the app holds personal data and several tables are open, a cleanup that makes it safe to launch runs $1,500–$15,000 over one to eight weeks. See pricing.

Get help when a table with personal or payment data has no policy, when the two-account test shows another user's record, or when you cannot read a policy and say what it allows. Our Lovable guide and Supabase guide go deeper, and this page explains what to do if data has already leaked.

Check these

DATA-01Critical

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-02Critical

No secret keys reach the browser

Open your live app, then DevTools, Sources, and search the loaded JavaScript for sb_secret_, sk_live_, sk-proj- and sk-ant-. Older Supabase keys are long tokens starting with eyJ: decode the middle part of each on your own machine, and if it contains "role":"service_role", your secret key is public. A publishable or anon key in the browser is expected.

DATA-03Critical

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-04High

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.

PAY-01Critical

Paid accounts are unlocked by a verified payment webhook

Access should change only when your server receives a signed webhook from Stripe or your provider, not when the browser reaches a success page.

Top-rated companies for Lovable apps

Ranked by our score: published prices, scope of work, AI tools named, timing and a low-risk first step. How we score.

  • 1Afterbuild Labs10.0/10Best for: A check before launchFree first step · from $49
  • 2Redlab10.0/10Best for: A full rescue by one team that keeps buildingFree first step · from $490
  • 3Vibe Code Rescue (Lev Arakelyan)9.0/10Best for: A one-off check and a cleanupFrom $299

All 59 Lovable companies, ranked

Related questions

Lovable's security scan passed. Does that mean my app is safe?

It means no table is missing a rule. It does not mean the rules are right. A policy that allows every signed-in user passes the scan and still leaks data. Run the two-account test yourself.

Is it a problem that my Supabase key is visible in the browser?

Not if it is the publishable or anon key. Supabase designs that key to be public, and RLS does the protecting. The secret key, which starts with sb_secret_ or is a long token containing service_role, must never be in the browser.

Sources: Lovable docs: Security; Matt Palmer: Statement on CVE-2025-48757; VibeEval: Vibe coding security monthly, August 2026; Supabase docs: API keys.