Check Lovable App Security: How to Test If Your Lovable App Is Exposing Data Through Supabase, Step by Step

Researchers at Crissy Field GmbH scanned websites built with the AI app builder Lovable and found thousands that sent database records to anyone who loaded the page, with no login needed. If your company has launched a Lovable app that stores customer, staff or order data, you can check in about 15 minutes whether yours is one of them, and this guide walks you through it.

What the Lovable researchers found

Crissy Field published its analysis after the German business paper Handelsblatt reported the findings on Monday, November 2, 2026. The researchers say their report has more recent figures than the newspaper article. From their write-up:

• They sampled 159,041 Lovable projects found in Common Crawl data from December 2025 to September 2026.
• 34,545 of those used Supabase, the database service the researchers believe is the most common choice among Lovable projects.
• 24,664 websites "sent database records from Supabase as soon as they loaded, without requiring a login or any other interaction."
• 7,403 of those 24,664 sites (30%) included email addresses, across 10,560 tables.

The examples are serious. A German lifestyle forum exposed more than 80,000 profiles with names, email addresses, dates of birth and gender, and "more than 200,000 chat messages were also accessible." A service provider exposed "more than 1,000 records containing identity document details," including passport numbers, expiry dates and nationalities. Event organizers and restaurants exposed tens of thousands of records on ticket and food sales, including contact details, payment information and ticket codes.

What is confirmed and what is not

Confirmed by the researchers: the figures above, and the method. They checked what each site sent when it first loaded, then made further read-only requests "with the same API key" the site itself used. They say they pulled only parts of the datasets, not full copies.

Not known:

• Whether anyone else found or used this data. The report says plainly: "We could not establish whether any of it had been misused."
• Whether the affected site owners were told, or have fixed their apps. The report does not say.
• How Lovable responded. The report says only that Handelsblatt contacted Lovable with the findings.

One more caution from the researchers themselves: "The 30% figure should therefore not be read as a confirmed data leak rate." It describes a sample, not every Lovable app.

This is not new: CVE-2025-48757

The same weakness has a public record. CVE-2025-48757, published May 30, 2025, describes "an insufficient database Row-Level Security policy in Lovable through 2025-04-15" that let remote attackers with no login "read or write to arbitrary database tables of generated sites." It is scored 9.3, Critical.

Lovable disputes that CVE, on the grounds that "each individual customer of the Lovable platform accepts a responsibility over protecting the data of their application." Its current terms, last 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 "You are solely responsible for reviewing, validating, and using any AI Output." In plain English, if your Lovable app leaks, it is your company's problem.

Is it safe that my Supabase key is in the browser?

Usually, yes. Supabase has two kinds of keys:

Supabase's own docs say of the publishable key: "Anyone can read it, so it only reaches what Row Level Security allows." That is the whole point. The key is public; row level security (RLS) is the lock. If RLS is off on a table, or its rules say "anyone can read," the public key opens it. A secret or service_role key is worse: Supabase says it "bypasses every Row Level Security policy you have."

How to check if your Lovable app is exposing data

Only test apps your company owns.

Step 1: Find the key your site sends to the browser

1. Open your live app in Chrome, right-click, choose Inspect, then the Network tab.
2. Reload the page and type supabase in the filter box.
3. Click a request to a URL containing /rest/v1/. Under Headers, find apikey. Note the project URL and the key.
4. Press Ctrl+Shift+F (Cmd+Option+F on Mac) to search all page code for sb_secret_ and service_role.

If the key starts with sb_publishable_, or matches the anon key in your Supabase dashboard's API key settings, that is normal. If you find a secret or service_role key anywhere in the page, treat it as an emergency: rotate it in Supabase today and move that code to a server.

Step 2: Check which tables have row level security on

In the Supabase dashboard, open the SQL Editor and run:

select tablename, rowsecurity
from pg_tables
where schemaname = 'public';

Any table showing false has RLS off. Supabase's guidance is simple: "Enable RLS on every table in an exposed schema." To turn it on:

alter table public.YOUR_TABLE enable row level security;

With RLS on and no rules written yet, Supabase says "no data is accessible through the API when using a publishable key, until you create policies." That may break parts of your app until the right policies exist, so plan it with whoever built the app.

Step 3: Test with a logged-out request

This is the test that matters, because it asks your database exactly what a stranger would. From a terminal, using the project URL and public key from Step 1:

curl 'https://YOUR-PROJECT.supabase.co/rest/v1/YOUR_TABLE?select=*&limit=1' -H 'apikey: YOUR_PUBLISHABLE_KEY'

Repeat for each table. How to read the result:

• An empty list, []: no rows are visible to a logged-out visitor. Good.
• A permission error: the table is not reachable at all. Good.
• Real rows of data: anyone on the internet can read that table. Fix it now.

Step 4: Read the rules, not just the switch

RLS being on is not enough. A policy written as using (true) for the anon role lets everyone read every row, which is the same as having RLS off. Check that each table's policies limit people to their own rows, and check insert, update and delete rules too, since CVE-2025-48757 covered writing as well as reading. Then sign in as one test user and try to load another test user's records. If that works, accounts are not separated.

Step 5: Repeat after every change

The researchers recommend repeating these checks "after significant changes." Every new feature an AI builder adds can create a new table with its own rules.

What to do this week

Why this matters for a business

These apps often get built outside IT: a booking form, a client portal, an internal tool someone put together over a weekend. They hold the same customer data as your main systems but get none of the review. If a table holding names, emails or ID details is open, you may have privacy and notification duties depending on where you and your customers are, and Lovable's terms make clear that those duties sit with you. Our security hardening work starts with an inventory of exactly these apps. If you'd rather run the app and its database on infrastructure your team controls, see our self-hosting infrastructure page.

Lovable app security questions people are asking

Is my Lovable app exposed?

You can only tell by testing it. Run the logged-out request in Step 3 against each table. If it returns real rows, it is exposed.

How do I know if a Supabase table is public?

Run the pg_tables query to find tables with RLS off, then run a request using only the publishable key. Returned rows mean the table is public.

What is row level security in Supabase?

It is a set of database rules that decide which rows each visitor or signed-in user can see or change. Without it, the public key can reach the whole table.

Was the data in the Crissy Field report stolen?

Not confirmed. The researchers say they could not establish whether any of it had been misused.

Does Lovable secure my app for me?

No. Lovable's terms say you are responsible for the apps you build and deploy and for reviewing AI output.

Is a 30% breach rate confirmed?

No. 30% is the share of sampled sites sending data that included email addresses, and the researchers say it is not a leak rate.

The bigger lesson

AI can write code, but a human must review it before it ships. The tools make building fast; checking who can read the data is still a person's job, and it has to be done again every time the app changes.

Want a second set of eyes on your apps? See our security hardening service or request a free quote.

Get security alerts like this by email, plus our free checklist, at /security-alerts.

Sources: Crissy Field: Lovable research; CVE-2025-48757 record; Supabase: Row Level Security; Supabase: API keys; Lovable Terms.