Lovable app readable without login? A 5-minute check

In early November 2026, German researchers at Crissy Field shared what they found after looking at 159,041 public Lovable projects. Of the 34,545 that used Supabase, 24,664 returned database records without a login. On 7,403 of those sites, they found tables with email addresses. Coverage also appeared in Handelsblatt, Techzine, and Cybernews.

The researchers are careful about what that means. The 7,403 figure is not a confirmed breach rate, and the sample is not every Lovable app. Emails might be public contact addresses or test data in some cases. Still, if you shipped a Lovable (or other vibe-coded) app on Supabase, five minutes of owner checks is cheap insurance.

This guide is for your own app. It does not explain how to look at someone else's database.

1. Open your app signed out in a private window

Sign out completely. Open a private or incognito window. Visit your live URL the way a stranger would.

Ask yourself: do names, emails, orders, chats, uploads, or admin-looking rows appear before you log in? If yes, the screen is not the lock. The data is already reaching the browser.

Also try pages you think are "members only." A hidden menu is not the same as a protected query.

2. Check Supabase for tables with RLS off

Open your Supabase project dashboard.

• In Table Editor, look at each table in the public schema.
• Confirm Row Level Security is enabled on every table that holds user or business data.
• Open Advisors (Security) and fix every warning about missing RLS or overly broad policies.

RLS is the rule layer that decides which rows each role can see. If it is off, a role that can reach the table can often read far more than you intended.

3. Write policies that match real users

Turning RLS on without policies can lock everyone out, or (depending on setup) still leave gaps. For each table, write policies that answer: who can select, insert, update, or delete, and under what condition?

Typical pattern for user-owned rows: only the signed-in user whose auth.uid() matches the row's user_id can read or change that row. Public marketing content is different: it may need a deliberate public-read policy. Private customer data should not.

After you save policies, repeat the private-window test.

4. Why the anon key is public (and why that is fine)

Lovable apps and most Supabase client apps put the anon key in the browser on purpose. That key is not a secret. It is a public client credential.

What protects private data is not hiding the anon key. It is:

1. Postgres grants (can this role touch the table at all?)
2. Row Level Security and policies (which rows can that role see?)

If someone tells you to "hide the anon key" as the main fix, that is the wrong mental model. Fix grants and RLS.

5. The Oct 30, 2026 Supabase change: new tables need explicit grants

Supabase published a breaking change: tables in the public schema are no longer exposed to the Data API automatically. On October 30, 2026, that behavior rolled out to existing projects. New tables need an explicit Postgres GRANT before anon or authenticated can reach them through the API. Existing tables keep their current grants. Source: https://supabase.com/changelog/45329

Treat these as a unit when you create a table you actually want the client to use:

1. Grant only the privileges each role needs (for example GRANT SELECT to anon only if public read is intentional).
2. Enable RLS.
3. Create the policies.

Never use GRANT ALL as a shortcut to silence a permission error. That is how private tables become wide open again. Grant the minimum. Prefer the specific privilege the role needs. If your AI coding tool suggests GRANT ALL to make a form work, stop and narrow it.

6. If emails (or other personal data) were exposed

This is general hygiene, not legal advice. If your own signed-out test or Security Advisor shows private emails, phone numbers, payments, or identity data were readable:

1. Tighten access now: enable RLS, fix policies, revoke overly broad grants.
2. Rotate any exposed secrets (service_role keys, API keys, webhook secrets). The browser anon key being public is normal; a service_role key in client code is not.
3. Review logs in Supabase and your host for unusual read patterns.
4. Consider notifying affected users if personal data was exposed. Rules vary by place and data type; when in doubt, talk to counsel.
5. Recheck after every prompt that adds a table, form, or upload. AI tools can create a new table without a matching rule.

7. A free outside, read-only second opinion

After you fix your own project, it still helps to see what a stranger's browser can observe from the outside. VibePatrol is a passive, read-only check for vibe-coded apps. Paste your live URL. No signup. It looks at what is already public in the page and the site's own scripts (leaked keys, open files, security headers, and related outside-in signals). It is not a pentest, it does not log in, and it does not teach anyone how to query your database.

Run the free check:

https://vibepatrol.dev/lovable-apps-readable-without-login?utm_source=devto&utm_medium=article&utm_campaign=lovable-7403

Sources

• https://www.techzine.eu/news/security/145550/thousands-of-lovable-apps-are-leaking-personal-data/
• https://cybernews.com/security/lovable-ai-apps-expose-personal-information/
• https://supabase.com/changelog/45329
• https://supabase.com/docs/guides/database/postgres/row-level-security

Originally published at vibepatrol.dev.