Lovable apps leaked user data: check your Supabase RLS

The most discussed developer story on Hacker News this weekend is a security report about apps built with Lovable, the AI app builder. Hamburg consultancy Crissy Field looked at 159,041 Lovable projects and found that thousands of them let anyone read their database without logging in. Exposed records included 80,000 forum profiles, more than 200,000 chat messages and more than 1,000 records with passport numbers.

Lovable was not breached. The failures sit inside the apps people built with it. The pattern is the same one that catches hand-written Supabase apps, so if you have shipped anything with Lovable, Bolt, v0 or Supabase directly, the checks at the end of this post are worth ten minutes today.

What the researchers found

The research report was produced "in collaboration with Handelsblatt", the German business paper, which reported the findings on 2 November. The English report says it has "more recent analysis and updated figures" than that article. Crissy Field sells security reviews, which is worth knowing when you read its conclusions, but the method is described in enough detail to judge on its own.

The researchers used Common Crawl, the open web archive, to find Lovable apps. They did not use it to collect the data itself. Then they narrowed the set down:

Step	Count
Lovable projects found, December 2025 to September 2026	159,041
Of those, using Supabase	34,545
Sent Supabase records on page load, with no login or interaction	24,664
Had records with email addresses reachable by further read-only requests	7,403 websites, 10,560 tables

The report is careful about what those numbers mean. A site that loads records without a login is, in its words, not a security issue by itself: "the data may be intended for public display." The 7,403 figure is 30% of the 24,664 sites examined more closely, and the report says "the 30% figure should therefore not be read as a confirmed data leak rate." The team also says it "retrieved only parts of the datasets", so the real exposure may be larger.

The examples are where it stops being abstract:

• A German lifestyle forum exposed more than 80,000 profiles with names, emails, dates of birth and gender, plus more than 200,000 chat messages.
• A service provider exposed more than 1,000 records with identity document details, including passport numbers, expiry dates and nationalities.
• Event organisers and restaurants exposed tens of thousands of ticket and food orders, including contact and payment details.
• A property manager exposed AI-generated summaries of internal emails about tenants and owners.
• In one case, 280,000 emails sent to a provider's customers were readable.

The report names no apps and says "we could not establish whether any of it had been misused."

What went wrong

The report itself only refers to "access control mistakes". Lovable named the cause. On Hacker News, Igor, Lovable's Head of Security, wrote: "The root cause in these apps was insufficent Row-Level Security, which is exactly what our scanning is built to catch."

If you have not used Supabase, here is the mechanism. A Supabase frontend talks to the database directly over an auto-generated REST API, authenticated with a publishable key (the older name is the anon key) that ships in the page's JavaScript. That key is meant to be public. Supabase's API keys guide says anyone can read it, "so it only reaches what Row Level Security allows."

Row Level Security (RLS) is the Postgres feature that decides which rows each request may see. Supabase's RLS guide is blunt about the two failure modes:

• No RLS at all. "A table in an exposed schema without RLS is readable and writable by any role with a grant on it." The guide also notes that on existing projects, "a new table in public starts with every privilege already granted" to the API roles. Writable matters too: the research only made read requests, but a table with no RLS takes inserts and updates as well.
• RLS on, policies too open. Once RLS is enabled, "no data is accessible through the API when using a publishable key, until you create policies." So a builder or a developer under pressure adds a policy. If that policy's condition is true, the table is public again.

There is a third case the report's examples suggest, which is my reading rather than something it states: a policy that only checks that the caller is logged in. If anyone can sign up, a policy that allows any authenticated user to read every row is barely better than no policy. A forum where every member can download every other member's chat messages is the typical result.

The author of the report, posting as neathack, said in the thread that "no advanced hacking techniques were used" and that anyone with a moderate understanding of the web could reproduce the results. The requests come straight from the browser, so the app's own frontend shows an attacker where to look.

How Lovable and the researchers handled it

Neathack wrote that Lovable "was informed weeks in advance", gave Handelsblatt an official statement confirming the findings, and never asked for a delay. The researchers shared site URLs, table names, record counts and a sensitivity score with Lovable's security team, not the records themselves, which they say were already deleted. Lovable's team said it would contact affected customers. The findings were not reported to data protection authorities.

On the product side, Lovable's reply points at its scanner. Its 10 November post says the most common issue it sees is "data access rules that are too open". It describes:

• a scan of database schemas and RLS policies on every publish,
• a deeper code scan that you can "run anytime, for free",
• an optional setting that blocks publishing when there are critical findings (opt-in, not on by default),
• scheduled scans for paid plans, listed under "What's coming this month", so announced rather than shipped.

In the thread, Igor added that "for many users it's the fear that the fix will break production" that stops them applying fixes, and that Lovable wants to turn auto-fix on by default "one day (soon!)".

The criticism in the thread is less about the bug than about who is expected to catch it. Neathack quoted Lovable's terms, which say AI output "should not be relied upon without independent review and testing", and set them against marketing that tells founders they don't need to know how to code. Both can be true at once. Either way, the person who has to act on it is whoever owns the app.

Check your own app

These checks apply to any app whose frontend talks to Supabase directly, whether Lovable, Bolt or v0 wrote it or you did.

1. Find tables with RLS off

In your project's SQL editor:

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

Any row with rowsecurity = false is a table the API can reach with the public key, for reads and writes, as long as the API roles have grants on it. Turn RLS on for each one. Supabase's own rule is to enable RLS on every table in an exposed schema:

alter table public.your_table enable row level security;

Expect parts of your app to stop working until you add policies. That is the point. Each error shows you a place where the app was relying on the table being open.

2. Find policies that let everyone in

select tablename, policyname, cmd, roles, qual, with_check
from pg_policies
where schemaname = 'public'
order by tablename;

Read every row. Pay attention to:

• qual or with_check that is just true. That means everyone the policy covers gets every row.
• roles containing anon (or public) on a table that holds anything personal.
• roles containing authenticated with no check against auth.uid(), on a table where users should only see their own rows.

A safer pattern for user-owned data ties each row to its owner:

create policy "Users read their own messages"
on public.messages for select
to authenticated
using ((select auth.uid()) = user_id);

3. Look at it the way the researchers did

Open your published app in a private window, without logging in, and watch the Network tab in DevTools for requests to /rest/v1/. Each one names a table. Then ask for a table directly with the publishable key from the page:

curl "https://YOUR-PROJECT.supabase.co/rest/v1/profiles?select=*&limit=5" \
  -H "apikey: YOUR_PUBLISHABLE_KEY"

If that returns rows you would not show a stranger, so will the same request from anyone else. Do this only against projects you own.

4. Use the tools you already have

If you build on Lovable, run its free deep scan now, don't wait for the next publish, and consider the option that blocks publishing on critical findings. Supabase's dashboard has its own Security Advisor, which flags tables without RLS. Neither replaces reading your policies yourself. A scanner can tell you a policy exists, but only you know which users are supposed to see which rows.

The short version

• What happened: Crissy Field found 7,403 Lovable-built websites whose Supabase tables served email addresses to anyone, with no login. Examples include 200,000 forum chat messages and more than 1,000 passport records.
• Why: missing or too-permissive Row Level Security, per Lovable's Head of Security. The public key in the page is not a secret. RLS is the only thing standing between it and your data.
• What Lovable did: confirmed the findings, says it is contacting affected customers, and points to free scans on every publish plus a deeper scan on demand.
• What to do: run the two SQL queries above, turn on RLS everywhere, replace true policies with ownership checks, and test your own app logged out.

If you are choosing between AI app builders, the security of the generated backend belongs on your list next to price and code export. Our v0 vs Bolt vs Lovable comparison covers how each one sets up its backend.

Frequently asked questions

Was Lovable itself hacked?

No. The research describes access control mistakes inside individual apps built with Lovable, not a breach of Lovable's own systems. Lovable's Head of Security said on Hacker News that the root cause was insufficient Row-Level Security in those apps' Supabase databases.

How many Lovable apps exposed data?

Crissy Field found records containing email addresses in 10,560 tables across 7,403 Lovable websites that could be read without logging in. The researchers say this is not a confirmed leak rate, because some of that data may be meant to be public and they only examined part of each dataset.

Is the Supabase publishable or anon key a secret?

No. Supabase says the publishable key is safe to expose in a web page, and that anyone who has it only reaches what Row Level Security allows. The key is not the problem. A table without RLS, or with a policy that allows everyone, is.

How do I check whether my Supabase tables have RLS enabled?

Run select tablename, rowsecurity from pg_tables where schemaname = 'public'; in the SQL editor. Any row where rowsecurity is false is a table that the API can read and write with the public key if the role has grants on it. Then review pg_policies for policies whose condition is simply true.