Lovable the company is about as safe as the other builders in its class, and it has had a rough year. It is ISO 27001 certified, says its controls are aligned with SOC 2, encrypts data at rest and in transit, and gives every project its own separate database. It has also had three public incidents in thirteen months, and one was its own fault. Apps built on Lovable are a different question. Nearly all of the exposed data in those stories came from apps where a rule that keeps one person’s rows away from the next was never switched on. Nobody broke in. So the platform is reasonably safe and getting safer under pressure, and your app is exactly as safe as what you asked for and then checked.
What actually happened, in three incidents
The first was in March 2025, when a researcher named Matt Palmer sampled 1,645 published Lovable apps and found 170 with their database readable without a login: usernames, emails, phone numbers, payment status, sometimes API keys. It became CVE-2025-48757, a public flaw record. The cause was a missing ownership rule on the database tables, which the builder had not added because nobody asked for it.
The second was in February 2026. An entrepreneur named Taimur Khan took apart a Lovable-hosted exam and grades app that Lovable was featuring on its Discover page: sixteen flaws, six critical, 18,697 user records exposed, thousands of them student accounts, login logic wired backwards in places, no ownership rule on the database. Lovable’s security chief answered that every project gets a free scan before publishing and that acting on it “is at the discretion of the user.” Again the app, not the platform.
The third, in April 2026, was the platform. By Lovable’s own account, between February 3 and April 20 the chat history and source code of public Lovable projects could be read by any signed-in Lovable user, and chat history is where people paste keys and sample records. A researcher reported it through Lovable’s bug bounty on March 3. It was fixed for new projects only, follow-up reports were closed as duplicates, and the hole stayed open for 48 days until the researcher went public. Lovable then shipped a fix within two hours, switched every public project to private, emailed the people affected, and rebuilt its triage process. Private projects were not affected, it says.
“Lovable hacked” often points to a fourth story that is not about your app. In August 2025 the security firm Proofpoint reported tens of thousands of lovable.app links used in phishing emails, and Lovable added real-time detection of malicious sites. For you it means an email filter may distrust a lovable.app link, one more reason to use your own domain.
What Lovable changed since
A basic scan now runs on its own before every publish, checking the ownership rules on your tables and the third-party code your app depends on. A deeper scan, run on request, reads the code itself for access-control mistakes. Lovable can fix eligible findings on its own, a few for free and then for credits, and a Security view per project lists every finding. The builder now notices when you paste an API key into the chat and steers you to store it as a secret instead.
None of this turns a scan into a guarantee. Lovable’s own docs say you are responsible for making sure your app meets the security requirements of its use case, and that the scanning tools do not replace a thorough review.
What stays yours, and why the builder cannot do it for you
Your app’s pages run in the visitor’s browser and ask a separate database for data directly, using a public key built into the page on purpose. What keeps strangers out is a rule on each table called row level security: hand each person only the rows that belong to them. Supabase, the database Lovable apps use, says a new table does not have that rule on by default, and a table without it can be read and written by anyone holding the public key.
A builder does what your prompt describes. “Let people save their orders” produces a table and a save button, not a rule about whose orders are whose, and the app works either way while you are its only user. A login screen does not close the gap on its own, because login proves who someone is and says nothing about whose rows they may read. And a key pasted into a page can be read by anyone who opens the page’s source, so a leaked key has to be replaced at the service that issued it before anything else.
The five-minute check for your own app, four things to look at with no code, is the companion guide. This page is about the platform. That one is about you.
Is Base44 safe? Is Base44 legit?
Base44 is a real company, bought by Wix in June 2025 and run as its own product. Its security page lists SOC 2 Type II, ISO 27001 and GDPR. In July 2025, researchers at Wiz found that anyone could create a verified account on a private Base44 app using only the app’s public id, bypassing its corporate login. Wix patched it within 24 hours and found no sign that anyone had used it.
The builder’s half looks the same as on Lovable. Each app has a visibility setting, public, private by invitation, or workspace only, and private needs a paid plan. Each kind of data has its own access rules, and the docs warn that a rule set to “All users” on read or update hands the data to anyone. A “Permission risks detected” banner and a Run Security Scan button do what Lovable’s scan does. Base44’s docs say it in one line: “You are responsible for your app’s security settings. Base44 provides the tools, but always review your permissions and run a security scan before you publish.”
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 your project’s Security view, run the scan, and read every finding rather than pressing fix on all of them. If your project was public before April 2026, assume its chat history was readable and replace any key you ever pasted into it. Then open your published app in a private window and see what a stranger sees, the only opinion on safety that counts.