You can find out in about five minutes with a private browser window, your app’s address bar, and the dashboard where your app’s data lives. Four checks, below. If all four pass, your app is not leaking in the ways Lovable apps most often leak. If one fails, you will know exactly which door is open, and the fix is a rule and a scan, not a rewrite.
This is worth doing today rather than someday. In 2025 a researcher named Matt Palmer found more than 170 published Lovable apps whose databases could be read by anyone, no password needed. The exposed data included emails, phone numbers, payment records and API keys. In February 2026 an exam question platform built on Lovable exposed 18,697 user records. None of those apps were hacked in the movie sense. A rule was missing, and nobody checked.
Why a Lovable app can leak without anyone breaking in
Your app has two halves. The pages people see run in their browser. The data lives in a database, a separate service that stores one row per saved item. When someone opens your app, the page asks the database for data directly, using a public key that is built into the page on purpose. Lovable apps connected to Supabase work this way, and there is nothing wrong with it.
What keeps strangers out is a rule on each table called row level security. In plain words: hand each person only the rows that belong to them. When that rule is on, the public key can only fetch your own rows. When it is off, the same key fetches the whole table, and the key is sitting in the page for anyone to copy. That is what happened to the 170 apps.
Lovable’s own docs say to make sure every table has this rule before going live and to verify it in the Supabase dashboard, because missing rules are the most common way app data gets exposed. Lovable also runs a security scan when you publish, but the scan is advice: about the exam platform, Lovable’s security chief said that acting on it “is at the discretion of the user.” You have to ask for the walls, and then check them yourself.
The five-minute check
Do these in order. Each takes about a minute. Keep a note of which ones fail.
Check 1, the private window. Open a private or incognito window, where you are logged out of everything. Paste the address of a page in your app that shows one person’s private data: a profile, an order, a saved item, a dashboard. If the data shows up without a login, that page is public. If your app has no login at all, everything in it is public by definition, and the first question is whether it should have one.
Check 2, the changed number. Log in as yourself and open something you saved. Look at the address bar. Many apps end the address with a number or a short code that identifies that one item. Change it: 42 becomes 41, or the last letter becomes another letter. If you now see someone else’s item, your app trusts the address instead of the login. Anyone who can count can read every record.
Check 3, the page source. On your published app, press Ctrl+U on Windows or Cmd+Option+U on a Mac. A page of code opens. Find a line with a link that ends in .js and click it. A wall of text appears. Press Ctrl+F and search, one at a time, for these strings: sk-, sk_live, sk_test, AIza, sb_secret. A real hit is followed by a long run of random letters and numbers, thirty characters or more. Any such hit means a secret key is sitting in public. Two things you may find that are fine: a long string starting with eyJ, or one starting with sb_publishable, is the public database key and is supposed to be there. It is only safe if check 4 passes.
Check 4, the red badge. If your app uses your own Supabase project, open supabase.com, open the project, and click Table Editor. Look at the list of tables. Any table with a red Unrestricted badge next to its name has the ownership rule off, and anyone with the public key can read it. If your app uses Lovable Cloud instead, open your project’s settings in Lovable, find the Security view, and run a scan. It lists every table that is missing the rule.
That is the whole check. Four things to look at, one place each.
What a failed check means, and what kind of fix it needs
If check 1, 2 or 4 failed, the open door is at the database, not on the pages. A login screen alone does not close it, because login only proves who someone is, and hiding buttons does not close it, because a hidden page can still be reached by its address. The fix is the row level security rule itself, turned on for every table and written so that a signed-in person gets only rows they own and a logged-out visitor gets only what is meant to be public. You ask for it in plain words, then repeat checks 1, 2 and 4 yourself, because the builder’s “done” is not evidence. Lovable’s publish scan can fix some of what it finds on its own. Treat it as a second opinion, and the private window as the first.
If check 3 failed, replace the key at the service that issued it before you do anything else, because anyone who copied the old key can keep using it until it is dead. Then have the builder move the new key out of the page and into a server-side secret, a locked place the browser never sees.
A builder reads your prompt and does what it describes. “Let people save their orders” produces a table and a save button, not a rule about whose orders are whose, because you did not say that, and the app works either way while you are its only user.
You can learn more, and get the full prompts and the decision tables, in our course: Lesson 3, The Secret Leak. The first lesson is free, no card.
In the next ten minutes: open a private window and run the four checks on your published app. Write down what failed. If a key showed up in check 3, replace it now, before anything else. Then tell Lovable, in plain words, which door is open, let the publish scan run, and run the private window check one more time when it comes back clean, because that is the only opinion that counts.