Is Lovable Secure? What Lovable Covers, What Your App Still Owes, and a 10-Minute Check (2026)

TL;DR: Lovable the company is reasonably secure. It says it has been SOC 2 Type 2 compliant since August 13, 2025, and it scans every app you publish for free. Your app is a different question. On November 2, 2026, researchers reported that of 24,664 Lovable sites they checked, 7,403 handed out database records containing email addresses to anyone, no login needed. As of November 2026, every big Lovable security story has come from the same gap: database access rules the builder never set. You can check yours in 10 minutes, and the steps are below.

I've shipped 50+ products and I was CTO at an AI startup, so I read every one of these stories the same way: what did the platform do, and what did the app owner skip? Two founders asked me this exact question recently, one of them with a live Lovable site. Here's the answer I gave them, with every number from the original source.

What happened this week: a 159,041-project scan and a CrowdStrike deal

Two pieces of Lovable security news landed back to back.

November 2: the Crissy Field study. Crissy Field, an application security firm in Hamburg, worked with the German business paper Handelsblatt and pulled 159,041 Lovable projects from the public Common Crawl web archive (December 2025 to September 2026). 34,545 used Supabase, the database most Lovable apps run on. 24,664 of those sites sent database records the moment the page loaded, with no login. By making more read-only requests with the same public key, the researchers found records with email addresses in 10,560 tables across 7,403 sites, or 30%.

The examples are the part that should make you open your own app: a lifestyle forum with more than 80,000 profiles and more than 200,000 chat messages readable, event and restaurant sales records with phone numbers and payment information, and one service provider exposing more than 1,000 records with passport numbers. The researchers are careful to say the 30% is not a confirmed leak rate. Some of those emails are public contact addresses or test data, and a Common Crawl sample isn't every Lovable app. I'd still treat it as the best look anyone has published at what real Lovable apps leave open.

November 3: CrowdStrike. CrowdStrike announced that Lovable workspaces now plug into its Falcon Shield product, so a company's security team can see which Lovable apps are public, which store secrets, which have unresolved scan findings, and who has access. The same release says people have built over 60 million projects on Lovable since its November 2024 launch. This is good news if you work at a big company with a security team. If you're a founder building alone, it changes nothing about your app this week.

How Lovable security works: the platform is audited, your database rules aren't

A Lovable app has two layers. The first is Lovable itself: the editor, the hosting, your account. That's what the SOC 2 Type 2 report covers, and it's Lovable's job. The second is your app's own backend, usually a Supabase database, where every table either has row level security (RLS) turned on or it doesn't. RLS is a rule on each table that says which rows a visitor is allowed to read or change. Without it, anyone holding your app's public key can read and write every row. That key ships inside your app's code by design. Supabase's docs are blunt: the Table Editor turns RLS on for you, but a table created with SQL (which is how AI builders often create them) needs it turned on by hand.

Lovable's security docs describe the safety net. The Quick scan runs on every publish and checks a fixed set of things in seconds: missing RLS, rules that let everyone through, vulnerable npm packages, and an MCP server open without login. The Deep scan reads your actual code for access control, injection, leaked secrets, payment and login bugs. But you have to run it yourself, auto-fix "does not apply fixes for Deep scan findings," and the docs say the tools "cannot guarantee complete security."

Lovable has said this split out loud. When a researcher found holes in a Lovable app in February, Lovable's CISO told The Register that applying its security recommendations is "at the discretion of the user."

Every Lovable security story so far came from the same gap

Line the incidents up and the pattern is hard to miss.

One of those four was Lovable's own sharing settings. The other three came down to the same thing: an app's database or login rules letting the wrong person in. If your app runs on Supabase, is Supabase secure walks through how RLS works and how to check yours.

Broken access control, in plain words

Security people call the most common bug in these apps "broken access control," and you'll also see "IDOR." Both mean the same simple thing: your app checks that someone is logged in, but not that the thing they're asking for is theirs. User 41 opens their invoice at a link ending in 41. They change it to 42 and see someone else's invoice. The page looked locked. It wasn't.

AI builders are good at the first check (show a login screen) and much worse at the second (only return rows that belong to this person), because the second depends on your business. Is a coach allowed to see a client's notes? Can a team member see the whole team's billing? Lovable can't know that unless you tell it, and the Quick scan can't see it at all. The Deep scan tries. A person who knows what your app is supposed to do is still the most reliable check.

Will a Lovable app hold up as users grow?

This is the other half of what both founders asked me, and the honest answer is: the hosting usually isn't the first thing to break. The code is. Here's what I look at when someone asks if their Lovable app is production ready:

• Database indexes. An index is the table of contents for a database table. Without one, every search reads every row. That's invisible with 50 rows and painful with 50,000. Supabase's free Performance Advisor flags missing ones (it calls them "unindexed foreign keys").
• Loading everything at once. Generated pages often fetch a whole table and filter it in the browser. Fine in a demo, slow and expensive with real data, and a privacy problem if the rows shouldn't all be visible anyway.
• No safe place to test. If every change goes straight to the live app, one bad prompt can break checkout for everyone. A separate test copy of the app is cheap insurance.
• No error handling. When a payment provider or an AI API times out, many generated apps show a blank screen. Users don't report that. They leave.
• Payments that trust the browser. If your app marks an order paid because the browser said so, instead of because Stripe confirmed it, you'll eventually give product away.

None of these mean you need to rebuild. Most of the apps I see need targeted fixes in a handful of places, not a rewrite. But they need to be fixed before the launch, the press mention or the ad spend, not after. Since October 30, 2026, Supabase also stopped exposing newly created tables to the public API by default on every project, which helps new tables. Tables you already have keep the access they had, so the check below still matters.

The 10-minute check you can run today

You don't need to read code for this. Open your project and do these five things:

1. Run the Deep scan. In your project's Security view, click Run deep scan. It's free. Read every Critical finding, even the ones that sound boring.
2. Check every table's rules. In Lovable, go to More, then Database, then Manage, then Policies. Every table that holds anything about a person should have RLS on and at least one policy. If you use your own Supabase project, open the Security Advisor there: a table flagged "RLS disabled in public" is readable by anyone.
3. Log out and look. Open your app in a private browser window, logged out, and click everything. Anything that shows a person's data is a problem.
4. Search for the dangerous key. Search your code for service_role and sb_secret_. Those are the Supabase keys that skip every RLS rule. They should never appear in anything the browser loads.
5. Turn on the publish block. If you're a workspace admin, go to Workspace settings, then Security, then Privacy and security, and turn on Block publishing with critical issues. It's off unless you're on a new Enterprise workspace.

If you want the full version, I wrote a free 20-point vibe coding security checklist that covers these plus Stripe webhooks, rate limiting and the environment-variable mistakes AI builders make. If you found a key in step 4 and aren't sure which one it is, Supabase anon key vs service role key explains which is safe in your frontend.

When a scan isn't enough

The Crissy Field researchers end their report with a line I agree with: automated checks are no substitute for a professional review once real customer data is involved. Lovable's own docs say the same thing. If your app has paying customers, stores anything sensitive, or is about to get a lot of new users, have someone who reads code check the access rules against what your business actually allows.

That's what Vibe Code Rescue is for. It starts with a free repo audit: I look at your code and send you a short video plus a written summary of what I'd fix first. My longer take on what Lovable is good and bad at is in my Lovable review.

Sources

• Crissy Field, Lovable research report: 159,041 projects, 7,403 sites, limitations, examples. Published November 2, 2026, read November 3, 2026.
• CrowdStrike press release: Falcon Shield integration, 60 million projects. November 3, 2026.
• Lovable docs, Security: Quick scan, Deep scan, auto-fix limits, publish block, Aikido. Read November 3, 2026.
• Lovable blog, security: SOC 2 Type 2 as of August 13, 2025.
• Matt Palmer, statement on CVE-2025-48757: 170 of 1,645 projects, 303 endpoints.
• The Register, February 27, 2026 and The Register, April 21, 2026.
• Supabase docs, Tables, API keys, Database Advisors and the October 30, 2026 Data API change. Read November 3, 2026.