Does Lovable turn on row-level security by default?

Yes, as of 2026, along with a linter that catches missing RLS enablement after database migrations. Some pages on this topic still say otherwise; Lovable’s own founder’s guide is the better source. RLS being on by default is also not the same as your policies being right, which is why the 2026 incidents happened anyway.

I can't find my app's database in Supabase. Is something wrong?

Probably not — you’re most likely on Lovable Cloud, where the Supabase instance is provisioned and managed by Lovable and doesn’t appear in your own Supabase dashboard. See the backend section above for how to confirm it, and what it means for who holds your keys.

Lovable

Lovable scans every app you publish. Here's what the scan can't see.

Last updated 18 September 2026 · verified against each platform’s own documentation

Is my Lovable app safe for real customers? The short version

Since August 2026, Lovable runs a security scan on every app you publish, automatically and free. It's worth having. Lovable's own documentation is also direct about where it stops. Lovable plainly says that these tools "cannot guarantee complete security," and for apps handling sensitive data you should "consider an additional professional security review." The scan checks that your row-level security policies exist. Whether or not the policy is configured correctly, well that's on you.

That distinction is not menial. The Lovable-showcased app that exposed 18,697 student and staff records in February 2026 had passed the scan. The flaw happened because an authorization check wired backwards. In the words of the researcher who found it, "the guard blocks the people it should allow and allows the people it should block." While the included scanner doesn't catch that, a malicious actor will.

A Lovable audit reads the policies a scanner can only count, checks every edge function for a real ownership check, and tells you which of your tables a stranger holding your publishable key can actually read.

$499, one week.

What Lovable secures — and what Lovable says is yours

Let me get the good news out of the way first, because there is more of it than most pages on this topic will admit.

Lovable enables row-level security by default now, and ships a linter that catches missing RLS enablement after database migrations. Every project gets its own separate Supabase instance. Data is encrypted with AES-256 at rest and TLS 1.3 in transit. Four scanners run against your code. If you built on Lovable eighteen months ago and have been carrying around a vague dread about it since, a fair amount of what you were dreading has been fixed at the platform level.

Lovable is also unusually clear about where its responsibility ends. Their founder's guide draws the line in one sentence: "Everything above is what the platform provides. Here's what you, as a founder, are responsible for." Their security docs go further than any competing platform's I've read: "You are responsible for ensuring that your app meets the security requirements appropriate for its use case, especially if it handles sensitive data or performs critical functions."

That is Lovable telling you, in their own documentation, that the last mile is yours.

Your app passed the security scan. Here's what the scan checks

Lovable ships two scans. The Basic Scan is the one that runs automatically on every publish. Lovable describes it as "a fast configuration and dependency check". It lints your RLS policies, reviews your database schema, and audits your dependencies, and confirms that a policy exists on a table.

The Deep Scan is on demand. Lovable describes it as "a thorough agentic review," that will check access control and review that "detects overly permissive data-access rules and database functions that bypass row-level security," plus backend endpoint protection.

The scan that runs automatically is the shallow one, and the Deep Scan actually looks at your authorization logic only runs if you know to ask for it.

This criticism is not new and it is not mine. When Lovable shipped its first scanner in May 2025, Matt Palmer's assessment was that it "merely verified RLS policies existed rather than confirming their correctness" — which he called "a false sense of security." The product has improved a great deal since then. The gap he identified is still the gap.

The scan proves a policy is there but not that it is right. Everything that went wrong with Lovable apps in 2026 went wrong inside a policy that was there.

What happened to Lovable apps in 2026

There were two major incidents that Lovable has publicly acknowledged.

In February 2026 security researcher Taimur Khan examined an EdTech app that was featured on Lovable's own Discover page and found 16 vulnerabilities, 6 of them critical. Exposed: 18,697 records, 14,928 unique email addresses, 4,538 student accounts, 870 with full personal information, including staff at UC Berkeley and UC Davis. The Register covered it on February 27.

Lovable's CISO, Igor Andriushchenko, responded that "any project built with Lovable includes a free security scan before publishing. This scan checks for vulnerabilities and, if found, provides recommendations on actions to take to resolve before publishing."

The app that leaked 18,697 records is the app that passed the scan. The free check is worth every penny

In April 2026, Lovable published a post-mortem on an incident in its own platform. Between February 3 and April 20, 2026 "data within public Lovable projects could be accessed by any authenticated user." Chat histories and source code. Their own account of the cause: "a backend regression reintroduced access to chat histories on public projects — undoing protections we had deliberately put in place." Their own assessment of themselves: "we didn't go far enough or fast enough in building safeguards around visibility settings."

This vulnerability was exposed for 76 days. They fixed it within two hours of public disclosure and made all historical public projects private. Private projects and Lovable Cloud were never affected. I'm calling this out because several write-ups of this incident claim otherwise and are wrong.

Neither of these is here to argue Lovable is careless. The post-mortem is more candid than most companies manage. They're here because both happened on a platform that already had the defaults right, and both were failures of authorization logic rather than missing configuration. That is the category a scanner does not catch.

The infamous 2025 CVE, and why Lovable disputed it

You will find CVE-2025-48757 on most pages about Lovable security. Here is the version with the parts other pages leave out.

In spring 2025, researcher Matt Palmer found that Lovable apps were routinely shipping with row-level security off or misconfigured. He scanned about 1,645 live Lovable projects and found 170 of them (roughly 1 in 10) where remote unauthenticated attackers could read or write to arbitrary database tables. No login required. NVD rates it 9.3.

NVD tags the record disputed, and records Lovable's grounds verbatim: "each individual customer of the Lovable platform accepts a responsibility over protecting the data of their application." Lovable did not deny the technical finding so much as argue that the responsibility was the customer's. That is the answer to the question this page addresses stated by Lovable, in a federal vulnerability database.

One thing from the 2025 story does still apply. It is worth noting that somebody scanned 1,645 applications looking for a single vulnerability class. In August 2026 a passive scan covered 30,998 live apps in three days. The odds of an app with a known platform vulnerability sitting quietly unnoticed have gone down considerably.

Six things that go wrong in a Lovable app

When Lovable builds your feature, it's solving for the app working the way you described it in the happy path. It is not sitting there thinking about how a bad actor would target you, or how a bumbling user might break something by accident. Those are the unhappy paths, and they're where nearly everything we find lives.

So without further ado, the things that may go wrong with your Lovable build:

A policy that exists but is wrong. RLS is on, a policy is attached, the scanner is satisfied. The policy compares the wrong two values, or scopes to the wrong column, and a signed-in customer can read another customer's rows. This is the single most common finding.
RLS on, grants never revoked. A subtler version. Supabase’s own documentation puts it flatly: “a table protected only by policies still hands anon an insert path if you never revoke the grant.” So RLS is enabled, a policy is present, and an anonymous visitor can still write to the table. I have not seen another page in this niche mention it.
Edge functions with no authorization check. Your database is locked down and your serverless functions are not. The function takes a record ID, fetches the record, returns it, and never asks whether the caller is allowed to have it.
Authorization logic wired backwards. The February 2026 case: a check that runs, passes review, and does the opposite of what it should. “The guard blocks the people it should allow and allows the people it should block.”
Secrets that reached the browser. A key that belongs on the server ends up in client code. Your publishable key in the browser is fine and expected. A service role key is not.
Public when you thought it was private. Project visibility settings misread or left at a default, which is what the April 2026 platform incident amounted to at the customer level.

Check two of these yourself, in ten minutes

You can verify part of this today without hiring anyone. Two caveats before you start, and the second one matters more than it looks.

First, find out which backend you have.
Click the Cloud icon in the Lovable editor's top bar. If you see the Supabase icon and a link to the Supabase Dashboard, the project is yours. If you see tables and users managed inside Lovable, you are on Lovable Cloud — and step two below will not work for you. Skip to the next section.
Step one: look at what your app sends.
Open your app in a browser, right-click anywhere on the page, and choose Inspect. Click the tab labeled Network, then reload the page. A list of requests will load in; find one going to an address ending in supabase.co and click it. Sitting right there you'll see the URL and an anon key — Supabase now calls it a publishable key — both in plain view. That part is normal. It is not a leak by itself. Supabase's own documentation describes the publishable key as "safe to expose online: web page, mobile or desktop app, GitHub actions, CLIs, source code." What keeps it safe is what happens next.
Step two: check that the tables are guarded.
Log into your Supabase account and open each table that stores customer information. For every one of them, check whether Row Level Security is turned on. If it's off, then the address and key you just found in your browser — which every visitor to your app already has — are enough on their own to read or change that table directly.
If it's on, look at the policy. If it reads USING (true), you have a policy that grants everyone everything. Supabase says it plainly: that "grants every unauthenticated visitor read access to every row the role can already reach through grants. Use it only for data that is meant to be public."
If you got this far and everything looks right, that is genuinely good news. It is also exactly where the free tools stop. What we do next is read what the policies actually say.

The general version of this advice: do a quick search for known issues in every tool that makes up your app's architecture. Work with your favorite AI coder to build a test plan against them. Then find a way to actually run that plan before you release the app into the wild. You'll never fully know until you part the kimono and inspect the codebase, but you can close most of the distance yourself.

What a Lovable audit covers

We read the code, which is the part the scanners don't do.

Specifically: every RLS policy on every table that holds customer data, read for what it actually permits rather than whether it exists; grants on those tables, including the ones nobody revoked; every edge function, checked for a real ownership check on the caller; client code, for secrets that shouldn't be there; project and table visibility settings; and your auth flow end to end, including the unhappy paths.

You get a list of severity-ordered findings, each written so you can hand it to whoever does the fixing. Technical evidence sits in an appendix. Anything we couldn't reach — and on Lovable Cloud there is usually something — is stated up front rather than quietly skipped.

$499, one week.

Flat price, no discovery call required to get it, one week from the day you give us access.

If your app holds no customer data — no accounts, no records, nothing a stranger would want — the automatic scan plus a Deep Scan is a reasonable place to stop.

If you're pre-launch and still changing the data model weekly, audit later. You'd be paying us to review something that won't exist in a month.

If you have someone on the team who knows Postgres and has time to read every policy line by line, they'll find most of what we find. The reason to hire this out is usually that you don't have that person, or that you have them and they're the one who wrote it.

What a Lovable audit covers

Can the right people access the right parts of the app—and nobody else?
Is customer information kept private and separated correctly?
Are passwords, payment keys, and other sensitive information protected?
Could someone reach data or features they shouldn’t be able to?
What could break, expose customer information, or become costly as you grow?

You get a severity-ordered report, covering vulnerabilities as well as best-practices to help you speed up delivery, with a remediation roadmap to help you address any issues. Plus a breakdown of your architecture to help you understand your application.

$499 fixed price · 1 week

Book an Audit

Common questions

Is my Lovable app safe for real customers?: Safer than it would have been in 2025. Lovable’s automatic scan confirms your row-level security policies exist. It does not confirm they’re correct, and every significant Lovable-app failure in 2026 happened inside a policy that existed. If you hold customer data, the gap between "a policy is there" and "the policy is right" is the part you still need checked.
My app passed Lovable's security scan. Isn't that enough?: Lovable’s documentation answers this directly: the tools "cannot guarantee complete security," and for apps handling sensitive data you should "consider an additional professional security review." Also worth knowing: the scan that runs automatically is the Basic one. The Deep Scan, which is what reviews access control, only runs when you ask for it.
Does Lovable turn on row-level security by default?: Yes, as of 2026, along with a linter that catches missing RLS enablement after database migrations. Some pages on this topic still say otherwise; Lovable’s own founder’s guide is the better source. RLS being on by default is also not the same as your policies being right, which is why the 2026 incidents happened anyway.
I can't find my app's database in Supabase. Is something wrong?: Probably not — you’re most likely on Lovable Cloud, where the Supabase instance is provisioned and managed by Lovable and doesn’t appear in your own Supabase dashboard. See the backend section above for how to confirm it, and what it means for who holds your keys.