Is my Lovable app safe to launch for customers?

It can be, but "it works" is not the same as "it's ready". Before customers sign up, check four things: who can open the app, whether one customer can see another customer's data, whether anything secret is in the code visitors download, and what Lovable's own security scan says. All of it fits into an hour in a browser. Where something needs changing inside the app, ask Lovable with the ready-made message below.

Why a working app can still be unsafe

When you build with Lovable, you describe what you want and the AI writes the app. It is very good at making features work. It is not watching for the ways a feature can work for the wrong person.

Most Lovable apps have two halves. The part people see runs in each visitor's browser. The data (accounts, orders, messages) lives in a database. That's either your own Supabase project or Lovable's built-in backend, which Lovable calls Cloud and which is built on Supabase. The database has rules about who may read what. Lovable writes those rules for you. According to Lovable's database documentation, it sets them up automatically when a feature stores user data.

The risk is in the details of those rules. The same page warns that a rule which only checks "is this person logged in?" gives every signed-in user the same access. So customer A can read customer B's orders, as long as A has an account. Nothing breaks, nothing shows an error, and you won't notice, because you only ever use the app as yourself.

That's why the checks below are done from a customer's side, not yours.

Check it yourself before the first customer

Do this on your own app only. You need about an hour, two email addresses and a private browser window (in Chrome it's called Incognito: a window that doesn't share your logins).

1. Open the published address, not the preview. The link you share with customers is the published app, either on a lovable.app address or your own domain. Check that it shows a padlock next to the address. Lovable sets up https (the encrypted connection the padlock stands for) for both, as its publishing guide explains.
2. See who can open it. In Lovable, open the Publish dialog and look at "Who can view your site?". "Public" means anyone with the link. On the Free and Pro plans you can choose "Invite only" for up to 10 people. That's a good setting for a small first group of testers.
3. Remember that preview links are different. Lovable's guide notes that anyone with an active preview link can open the unfinished version, whatever you chose for the published app. Don't send preview links to customers.
4. Check whether others can copy your app. In Project settings, under Sharing, look for public remixing. If it's on, anyone with the project link can make their own copy and see the source code, per Lovable's visibility settings. Turn it off unless you meant it.
5. Make two test customers. Sign up as Customer A in a normal window and as Customer B in a private window. As A, create something private: an order, a note, a profile, an upload.
6. Try to see A's things as B. Copy the address of A's private page and open it as B. Then open it while logged out. You should get a login page or "not found", never A's data. If the address has a number in it, like /orders/12, try 11 and 13 as B.
7. Look for secrets in the page. Open your live app, right-click, choose "View page source" and search (Ctrl+F or Cmd+F) for service_role, sb_secret_, sk_live and sk-. These are the starts of secret keys, which work like passwords for paid services. They should never be there. A clean result here is a good sign, not a full check: keys often hide in separate script files.
8. Run Lovable's deep scan. Open More, then Security, and start a deep scan. The security documentation explains that the quick scan runs every time you publish, while the deep scan reads all of your app's code and only runs when you start it. It usually takes a few minutes.

Write down anything that failed. Step 6 is the most important one. If B could see A's data, fix that before anyone else signs up.

What the scan results mean for you

Lovable's scan shows findings by how serious they are. Treat every Critical one as a reason to wait with the launch.

Don't rely on the publish button to stop you. Lovable's guide says findings don't block publishing by default, and the setting that blocks it is off unless you turn it on (Enterprise workspaces are the exception). The app will go live with open problems if you let it.

Also, don't press "fix all" and move on. Fix the serious ones one at a time, and after each fix redo step 6. The fix works when B stops seeing A's data, not when the AI says "Done".

For a longer, more technical list for whoever does the fixing, see the Lovable app security checklist. If you want the general version of the two-account test for any app, it's in how to check your app for security holes.

What to ask Lovable

You don't need to know how database rules are written. Paste this into the Lovable chat. It asks for a report first, so you can see what's wrong before anything changes.

Before my first customers sign up, review this app for safety and
report back in plain language. Don't change anything yet.

1. Database rules: for every table, can a signed-in customer read or
   change only their own rows? List any table where any logged-in user,
   or a logged-out visitor, can read other people's data.
2. Secret keys: is any secret key (payments, AI, email, the database
   admin key) in code that runs in the visitor's browser? Name the file.
3. Server functions: list any that work without logging in or don't
   check who is calling.
4. Admin pages: is "admin only" checked on the server, or only by
   hiding a button?
5. Leftovers: test accounts, sample data, demo keys, debug pages.

Then fix the serious ones one at a time. After each fix, tell me what
to click to check it worked.

When the answers come back, run steps 6 to 8 again.

When "safe enough" needs more than this

These checks catch the common mistakes. They're not a full security review. Lovable's own documentation says that apps handling sensitive data should get an extra professional review. Do that if you store health or financial data, take card payments yourself instead of through a service like Stripe Checkout, or a business customer asks you for a security report.

Two smaller things before launch:

• A privacy policy. If customers give you their email or anything else about themselves, they should be able to read what you do with it. This is a reminder, not legal advice.
• One owner account. Make sure the Lovable and Supabase accounts are in your name, with two-step login on, not only in the freelancer's or friend's who helped.

Keep it safe after launch

Every new prompt to Lovable can change the app, and a fixed problem can come back with a new feature. Checking once at launch isn't enough.

ScanYourSite checks your live Lovable app from the outside, the way a visitor's browser sees it. It never logs in, fills in forms or guesses passwords. The free check takes about a minute: open https://scanyoursite.app/?check=yourdomain.com with your own address in it. It looks for secret keys in the code your app sends to visitors and names the file, tells you which Supabase project the app talks to, and checks https, security headers (instructions your site sends the browser about what to block), trackers and the privacy policy link. The three most important findings come explained in plain words, with a message to paste into Lovable. Free also checks the site once a week and sends you a summary.

Pro ($19 a month, three sites) checks daily and within minutes of every update, and writes the moment something new is wrong. On Pro, after you verify the domain, it also counts how many rows of each Supabase table a stranger could read with the app's public key, without reading what's in them, and checks for files that should never be public, like .env.

What it can't do is step 6: testing as two different customers is something only you can do. Repeat it whenever you add a feature that stores something per customer.