Lovable apps with emails readable without login: what to check on yours

Short answer: turn on Row Level Security for every table with personal data, replace open policies with owner-only ones, and check that a signed-out visitor using your public key gets nothing back. For your own sites and projects, run a free SniffPup scan to see which keys and files your live site gives away. Use the checks below for your tables and policies.

Home › Guides › Lovable emails readable without login · Last updated November 4, 2026 · By Ember, SniffPup

1. What the research found

Crissy Field GmbH's research (also covered by Techzine) looked at 159,041 Lovable projects found in Common Crawl data from December 2025 to September 2026. Of those, 34,545 used Supabase.

• 24,664 sites returned Supabase records on load without login. That alone is not a leak: some of that data may be meant to be public.
• Further read-only requests found email-containing records in 10,560 tables across 7,403 of those 24,664 sites (30%).
• Examples they list include passport records (1,000+) and chat messages (about 200,000 in one forum case).

Crissy Field says the 30% is not a confirmed leak rate. Some emails may be public on purpose or test data, and the sample is not representative. These are their numbers, not SniffPup's: SniffPup did not scan these apps.

2. The cause is RLS, not a Lovable hack

The research points to missing or loose Row Level Security on each project's Supabase tables, not a break-in at Lovable. A Lovable app talks to Supabase from the browser with a public anon (or publishable) key, so whatever RLS allows, anyone with that key can read. Lovable's terms place responsibility for the app's data on the customer, so checking your tables is your job.

3. Enable RLS and use owner policies

Start with Supabase Security Advisor, which flags tables without RLS (the Supabase security audit guide walks through every finding). Or find tables in the public schema with RLS off yourself:

select tablename from pg_tables
where schemaname = 'public' and rowsecurity = false;

Turn it on and add a policy that only lets each user read their own rows. Replace profiles and user_id with your table and owner column:

alter table public.profiles enable row level security;

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

Then drop leftover open policies. Permissive policies are combined with OR, so one using (true) policy keeps the table open even after you add an owner policy:

select tablename, policyname, roles, cmd from pg_policies
where schemaname = 'public' and (qual = 'true' or with_check = 'true');

drop policy "Enable read access for all users" on public.profiles;

More patterns are in Supabase RLS policy examples and why a table stays open after an owner policy.

4. Test logged out with your public key

On sites and projects you own, open the app in a private window without signing in and watch what loads. Then request each table that holds personal data with only the anon or publishable key from your site's JavaScript:

curl -i "https://YOUR-PROJECT.supabase.co/rest/v1/profiles?select=*&limit=1" \
  -H "apikey: YOUR_ANON_KEY" \
  -H "Authorization: Bearer YOUR_ANON_KEY"

For private tables you want [] or a permission error. Real rows mean the policy still lets strangers in. Repeat for every table with emails, names, messages or documents, then sign in as two different users and check that neither can read the other's rows. The SQL editor runs as postgres and bypasses RLS, so it is not a valid test.

5. UI filters are not security

Hiding rows in the page, filtering by user in the frontend query, or putting a page behind a login screen does not stop anyone from calling the Supabase API directly with your public key. Only RLS and grants in the database decide what comes back.

6. If real personal data was public

• Fix the policies first, and confirm with the signed-out test above.
• Rotate any secret keys that were stored in readable tables or shipped to the browser. Removing them from the code is not enough. See what to do after leaking an API key.
• Check your logs where you can, and notify affected users if your obligations require it.

7. Where SniffPup fits

SniffPup's free scan is a passive check of a site you own: it looks at what your live URL sends every visitor, such as secret keys in the JavaScript and open files like /.env or source maps. It does not read your RLS policies and it cannot prove a site is safe. The steps above are how you check your tables. SniffPup did not scan the 159,041 projects in this research.

FAQ

Source: Crissy Field GmbH, Lovable research (also covered by Techzine). Checked November 4, 2026.