Your Supabase key Is Probably Already Public Knowledge – Here’s How to Check in 5 Minutes

If you built your MVP on Lovable, Bolt, Cursor, or any “vibe coding” platform with a Supabase backend, there’s a chance a stranger on the internet could already access your users’ data. Not because you did anything unusually careless, but because it’s the single most common mistake in AI-generated app scaffolding right now, and most non-technical founders would have no obvious way of knowing it had happened.

The problem, in plain terms

When AI coding tools scaffold a Supabase-backed app, they typically ship with a public “anon” API key baked into the client-side code. It’s visible to anyone who opens the browser’s dev tools, and that’s by design. Supabase expects access to be controlled afterwards using Row Level Security (RLS) policies.

The catch: RLS isn’t switched on by default, and most people vibe-coding their way to an MVP don’t know it exists, let alone that they need to configure it.

The result is a database that’s technically “secured” by a login screen on the outside, while the raw data underneath is wide open to anyone who knows where to look.

This isn’t hypothetical. It’s a documented, recurring pattern.

• Escape.tech scanned 5,600 public vibe-coded apps and found 2,000+ vulnerabilities, more than 400 exposed secrets, and 175 instances of exposed personally identifiable information – the majority traceable to the same root cause: a public anon key with missing or misconfigured RLS. (Escape.tech methodology)
• CVE-2025-48757, disclosed in May 2025, described exactly this failure mode on the Lovable platform: 303 vulnerable endpoints across roughly 170 apps (about 10% of scanned Lovable-built projects), exposing personal data, financial records, API tokens, and even admin credentials to unauthenticated requests.
• Wiz Research documented the same pattern on “Moltbook,” a Lovable/Supabase-built app, which leaked 1.5 million API authentication tokens, 35,000+ email addresses, and 4,060 private messages.
• Base44, a vibe-coding platform later acquired by Wix, had an authentication-bypass flaw (also disclosed by Wiz Research) that exposed user accounts and session data.

None of these are edge cases from years ago. This pattern continues to recur because the tooling prioritises speed, while security configuration can easily be missed during a fast build. That’s exactly the kind of gap a non-technical founder may have no obvious way of seeing.

Three things to check this week

Whether you built the app yourself, used an AI coding tool, or worked with someone else, these are three checks worth making.

1. Open your browser’s dev tools on your live site, go to the Network tab, and search for “supabase” or “anon” in any request. If you can see a key, so can anyone else – that part is normal. The question is what that key can actually do.
2. Ask whoever built your backend one direct question: “Is Row Level Security switched on and correctly configured for every table?” If the honest answer is “not sure,” treat that as something that needs checking.
3. Check whether your signup/login page is the only thing standing between the public internet and your database. If RLS isn’t configured per-table, it usually is.

You don’t need to be able to read the code to ask these three questions. You just need to ask them and make sure you get a clear answer.

Why this matters at your stage

At pre-MVP to Seed/Series A, you’re moving quickly, often without a technical co-founder or senior technical lead checking this kind of thing as you go.

That speed is often necessary. But it’s also why gaps like this can make it into production unnoticed.

An investor doing even light technical due diligence, or a single curious user poking at your API, can find this in minutes. A breach notification you didn’t see coming is a much worse way to learn about it than a five-minute check this week.

This is exactly the kind of issue CYP’s Vibe Coding Audit (£99/founder/month +VAT) is designed to catch – a structured review of exactly this class of exposure, before it becomes an incident, a headline, or a due-diligence red flag.

You don’t need to become technical to fix this. You need someone checking for it who already knows what to look for.

Learn more about the Vibe Code Audit Here

Sources

– Escape.tech – “Methodology: 2k+ Vulnerabilities in Vibe-Coded Apps”: https://escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/

– Cloud Security Alliance – “Vibe Coding Security Debt: AI-Generated Vulnerabilities at Scale” (2026 research note): https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-codegen-vulnerability-debt-20260406-csa/

– SecurityOnline – CVE-2025-48757 coverage: “Lovable’s Row Level Security Breakdown Exposes Sensitive Data Across Hundreds of Projects” (May 2025), as cited by Cloud Security Alliance

– Wiz Research (July 2025), “Moltbook” disclosure, as cited by Cloud Security Alliance and Autonoma

– Wiz Research – Base44 authentication-bypass disclosure, as cited by Cloud Security Alliance

– ctoinyourpocket.com/pricing – re-verified live 10 Aug 2026 (Vibe Coding Audit £99/founder/month +VAT)

Editorial Note: Content on this site is initiated via AI automation and reviewed by our team. While we check our articles before publishing, we cannot guarantee absolute factual accuracy or completeness. Readers should verify critical information independently.