Your app works. People sign up, they pay, they log in. None of that tells you whether a stranger can read your users’ data, and you don’t want to end up as the next company listed on Have I Been Pwned.
In October 2025, Escape.tech scanned 5,600 publicly available vibe-coded apps and found more than 2,000 high-impact vulnerabilities, over 400 exposed secrets and 175 instances of exposed personal data, including medical records and bank account numbers. Their methodology post notes the scans ran passively, so the real figure is probably higher. Seven months later, RedAccess scanned roughly 380,000 apps built on Lovable, Replit, Base44 and Netlify and found about 5,000 holding sensitive corporate data.
However, this isn’t a Kafka novel, so there is some good news-ish: these apps all seem to break in the same few areas.
The key is sitting in your page
Lovable runs on Supabase, and so do most Bolt apps. By design, your app hands a public key to every browser that loads it. That’s fine as long as row-level security (RLS) is switched on for every table. RLS is the lock. The public key is the door handle everyone can see.
When a table has no policy, that key reads the whole table. Researcher Matt Palmer scanned 1,645 publicly listed Lovable apps and found 170 with missing or misconfigured RLS, leaking names, emails, phone numbers, home addresses, payment information, and third-party API keys. It became CVE-2025-48757. Lovable didn’t love this and argued against this, on the grounds that customers own the security of their own app data.
That sounds good for the legal department but gut wrenching news to learn after your first 500 signups.
October 30 changes the defaults, not what you’ve already shipped
New Supabase projects created after May 30, 2026 no longer expose new public tables to the Data API automatically, and on October 30, 2026 the same rule reaches every existing project.
Tables that are reachable today keep their current grants, so anything already live stays exactly as exposed as it is now. And after October 30, your AI tool will cheerfully create tables that return permission errors until somebody adds an explicit grant.
Find your build tool
| Build tool | Likely leak | Check first |
|---|---|---|
| Lovable / Bolt (Supabase) | Tables with RLS off, or a policy set to using (true) | The 60-second test below |
| Base44 | You inherit the platform’s auth layer, which had a platform-wide bypass in 2025 | Sign up with a fresh account, try to open a private app |
| Replit | Agents holding write access to live data | Confirm dev and prod are separate, then test a restore |
| v0 / Next.js | Secrets in NEXT_PUBLIC_ variables, shipped to every browser | Grep .env and your build output |
| Cursor / Claude Code / Codex | Authorization gaps between users; features that fetch any URL you hand them | Log in as user A, request user B’s records by ID |
| Firebase | Rules left in test mode or set to allow read, write: if true | Firebase console, Rules tab |
In December 2025, Tenzai had Cursor, Claude Code, Codex, Replit and Devin each build the same 3 apps and found 69 vulnerabilities across the 15 results. None had an exploitable SQL injection or cross-site scripting flaw. What they had instead was broken authorization and request forgery. Models handle the rules everyone agrees on and struggle with anything that depends on your unique app requirements.
The 60-second test
Grab your Supabase URL and anon key from DevTools, Network tab. Log out. Then run this against one of your own tables:
curl 'https://YOUR-PROJECT.supabase.co/rest/v1/profiles?select=*&limit=1' \
-H "apikey: YOUR_ANON_KEY" \
-H "Authorization: Bearer YOUR_ANON_KEY"If rows come back, stop reading and fix that first.
Own the parts
In July 2025, Replit’s agent deleted SaaStr founder Jason Lemkin’s production database during an explicit code freeze, then told him a rollback wasn’t possible. He recovered the data manually. At the time, Replit ran preview, testing, and production off the same database, and the company was actually marketing itself as the safest place for vibe coding. The CEO called the incident unacceptable and shipped dev/prod separation, one-click restore and a planning-only mode within days.
Platform bugs land the same way. Wiz found an authentication bypass in Base44 that let anyone create a verified account on a private app using a public app ID. Wix patched it within 24 hours; thankfully, or Twitter would be on fire. However, until they did, every app on the platform was wide open.
Production means you own the repo, the database project, the migrations, a separate staging database, and a backup you have restored at least once.
The score sheet
1 point per box you can tick honestly. “I think so” stays unticked.
Database
- 01RLS on for every table, Security Advisor clean
- 02No user-data policy uses
using (true) - 03User A can’t read or edit user B’s rows
- 04Storage buckets private unless meant to be public
Keys and secrets
- 05No
service_roleorsb_secret_key in frontend code - 06No Stripe, OpenAI or other private keys in frontend code
- 07Git history secret scan comes back clean
- 08Every key that touched git has been rotated
- 09
.envis in.gitignore
- 05No
Auth
- 10Permissions enforced in RLS or server code, not just hidden buttons
- 11Email verification on
- 12Login and reset endpoints rate limited
- 13Reset links expire and can’t be reused
Input and output
- 14User content never renders as raw HTML
- 15URL-fetching features restricted to allowed domains
- 16Error pages show no stack traces or SQL
Ownership
- 17Code in a GitHub repo you own
- 18Database project in an org you control
- 19Schema changes tracked as migrations, grants included
- 20Staging separate, backups on, restore tested
Where you land
- 0 – 8Rotate keys today, treat data as out.
- 8 – 13Pause new signups until 1–10 are ticked.
- 13 – 18Fix the gaps this month.
- 18 – 20Ship it, then book a real review.
Scored under 13, or unsure how to run half of these? Book a free audit call and bring your sheet like your school days, and we’ll help you decipher most of these hieroglyphics.
