Supabase Row Level Security Explained: The Setting Behind the Lovable App Leaks, and How to Check Yours This Week

Researchers in Germany found thousands of apps built with the AI app builder Lovable sending database records to anyone who opened the page. The records included more than 200,000 private chat messages and records with passport numbers. If your business runs a customer portal, booking tool or internal app built with AI on Supabase, one database setting decides whether that data stays private, and you can check it this week.

What happened with the Lovable apps

On November 2, 2026, the German business daily Handelsblatt published findings from Crissy Field, an application security firm in Hamburg. Crissy Field's own report says it analyzed 159,041 Lovable projects from December 2025 to September 2026, found through public Common Crawl data. Of those, 34,545 used Supabase as their database.

What the researchers confirmed:

• 24,664 of those sites sent Supabase database records as soon as the page loaded, with no login or other interaction.
• 10,560 tables on 7,403 of those sites contained email addresses.
• One German lifestyle forum exposed more than 80,000 user profiles and more than 200,000 chat messages.
• One service provider exposed more than 1,000 records with identity document details: passport numbers, expiry dates and nationalities.
• Other apps exposed invoices, contracts, payment information and tens of thousands of ticket and food sales records.

What is not known or not confirmed:

• Misuse. The researchers write that they "could not establish whether any of it had been misused."
• A breach rate. The 7,403 sites are about 30 percent of the 24,664. The researchers say that figure "should therefore not be read as a confirmed data leak rate." Their sample does not represent all Lovable apps.
• Full counts. They pulled only parts of each dataset, so the numbers are a minimum, not a total.
• Passport images. Some coverage mentions passport scans. The report describes passport numbers and related details, not scanned images.
• Lovable's own database. The study covered apps that use Supabase. It did not look at the database features Lovable added in late 2025.

The report says Handelsblatt contacted Lovable with the findings. It does not include a response.

This is not the first time: CVE-2025-48757

In May 2025, researcher Matt Palmer disclosed CVE-2025-48757. The CVE record describes "an insufficient database Row-Level Security policy in Lovable through 2025-04-15" that let unauthenticated attackers "read or write to arbitrary database tables of generated sites." It is scored 9.3, critical. Palmer's write-up lists exposed names, email addresses, API keys for other services and payment records.

Lovable disputes that CVE. The record gives its position: each customer "accepts a responsibility over protecting the data of their application." Its current terms, updated August 28, 2026, say the same thing: "You are responsible for your Customer Data and for the applications and projects you build, deploy, and make available." Put simply, if the app leaks, the leak is yours.

Supabase row level security explained without jargon

A traditional website has a server in the middle: the browser asks the server, and the server decides what to fetch from the database. Many Supabase apps skip the middle. The browser talks to the database directly, using a key built into the page.

That key is the publishable key (older projects call it the anon key), and it is meant to be public. Supabase's documentation calls it safe to expose in a web page or app. Anyone can open your site, find the key and send their own queries. So the key is not the lock.

The lock is row level security (RLS): rules inside the database that decide, row by row, who can read or change what. Supabase's guidance is direct: "Row Level Security decides what this client can reach, so enable it on every table before you deploy."

A table can be in one of three states:

• RLS off: anyone holding the public key can read it, and often change it.
• RLS on, no rules: the public key gets nothing. That is safe, but the app may stop showing data until you add rules.
• RLS on, with rules: each visitor sees only what the rules allow. A rule that says "allow everyone" leaves the table just as open as having RLS off.

The Crissy Field report does not say which state each app was in. It describes records that could be read without a login using the app's own key. In a Supabase app, RLS and its rules are what control that.

One more key matters. The secret key (older projects: the service_role key) skips every RLS rule. Supabase says never to put one "in a browser, a shipped application, or source control."

How to check your Supabase RLS this week

Only run these checks on apps you own or have permission to test.

If you find an open table with real customer data in it, turn RLS on (alter table public.your_table enable row level security;) and write rules for signed-in users. Rotate any secret key that was exposed, and ask your lawyer whether breach notification rules apply. Lovable's Quick scan does flag tables without row-level security, but Lovable's own documentation says its scans "do not replace a thorough security review."

Why this matters for a company website or app

With an AI builder, an operations manager or founder can ship a working portal in an afternoon. That is real value. But the app's privacy depends on database rules the builder may never have seen, and the platform's terms put the outcome on you.

For a business, that can mean customer records, invoices or staff chats one query away from anyone, with your company's name on the notification letter. The risk also grows with every new table or feature, because each one needs its own rules.

Our view, said once: AI can write code, but a human has to review it before it ships. We wrote more about that in AI can build your app, who is going to keep it running and the gap in app development nobody wants to talk about. If you would rather keep the database behind your own server than open to the internet, see self-hosting infrastructure.

Supabase row level security questions people are asking

Is an exposed Supabase anon key a problem?

Not by itself. The anon key and the newer publishable key are designed to be public. The real dangers are a table without RLS and a leaked secret or service_role key.

What is Supabase RLS in simple terms?

It is a set of rules inside the database that decides which rows each visitor can read or change. Without it, the public key can reach the whole table.

Will turning on RLS break my app?

It can. With RLS on and no rules, the public key gets no data. Add rules for signed-in users, then test.

Was data from the Lovable apps misused?

Nobody knows. The researchers say they could not establish whether any of it was misused.

Were passport scans leaked?

The report describes more than 1,000 records with passport numbers, expiry dates and nationalities. It does not describe scanned images.

Is Lovable responsible for the leak?

Lovable's terms make customers responsible for the apps they deploy. Lovable disputes CVE-2025-48757 on the same grounds.

Does Lovable check RLS for me?

Its Quick scan flags tables without row-level security. Its documentation says the scans do not replace a security review.

The bigger lesson

The tool that writes your app will not take responsibility for it. Fast tools are worth using, as long as someone who understands the database checks the locks before customers hand over their data, and checks them again after every change.

Want a second set of eyes on an AI-built app? See security hardening or request a free quote.

Get security alerts by email, with the free checklist, at security alerts.

Sources: Crissy Field: Lovable research; CVE-2025-48757 record; Matt Palmer: CVE-2025-48757; Supabase: Row Level Security; Supabase: API keys; Supabase: Database Advisors; Lovable Terms and Conditions; Lovable: Security overview.