Is Your Vibe-Coded App Leaking Data? The 7 Gaps in Every AI-Built App
Worried your vibe-coded app is leaking data? Here are the 7 security gaps that show up in nearly every AI-built app — and how to check each one yourself.
You shipped an app you didn't fully write, and now you can't shake the question: is it quietly leaking my users' data right now? You're not being paranoid. The gaps that cause leaks in vibe-coded apps are not random. The same seven show up again and again, across every AI builder, because they all share the same defaults.
The reassuring part is that a short, finite list means you can actually go through it. This post walks each of the seven gaps in plain terms: what it is, what's at stake, and where to go to check and fix it.
⚡ TL;DR
- Vibe-coded app security failures cluster into seven recurring gaps — missing database rules, exposed secret keys, open storage, missing auth, SSRF, missing CSRF and headers, and published source maps.
- Most are checkable by a non-developer in an afternoon, and each one below links to a focused guide.
- Ignore the false alarms: your Supabase anon key and Firebase web config are public by design. Spend your time on the gaps that actually expose data.
Why the same gaps keep appearing
Before the list, the why. AI builders optimize for one thing: a feature that works in the preview. A database with its access rules off, a bucket left public, an endpoint with no auth check — all of these work fine in a demo. The hole is invisible until someone looks for it. Independent testing backs this up: the Veracode 2025 GenAI Code Security Report found 45% of AI-generated code samples failed security tests. So these gaps aren't bad luck. They're the default.
That's also why the list is short and predictable. Same defaults, same gaps. Here they are.
Gap 1: Missing or "match everyone" database rules
This is the most common and the most damaging. Most vibe-coded apps use Supabase, where the browser talks straight to the database. The thing standing between a visitor and your data is RLS (Row Level Security) — a rule that decides which rows each user can see.
Two ways this goes wrong: RLS is switched off entirely, or it's enabled with a policy of USING (true), which means "match every row" — protection that looks present but lets everyone through. Either way, any visitor can pull every row from your tables. This is exactly the flaw behind CVE-2025-48757, where 170 of 1,645 scanned Lovable apps leaked real user data.
The stake: your entire user table, readable by anyone. Check and fix it: Supabase RLS explained.
Gap 2: Exposed secret keys
AI builders sometimes drop secret keys straight into your frontend — the code that ships to every visitor's browser. A secret key is different from a publishable one. Publishable keys are meant to be public; secret keys are passwords to your backend services.
A leaked secret database key can mean someone reads or wipes your whole database. A leaked AI provider key means someone runs up a bill on your account — Moltbook (January 2026) exposed roughly 1.5 million API keys, some of them plaintext AI keys sitting in private messages.
🐺 Not a real problem
A Stripe
pk_live_key, a Supabase anon key, and a Firebase web config are all meant to ship in the browser. They are not the gap. The emergency is a secret key —sk_live_, a service key, an AI provider key — in your frontend.
The stake: someone else's bill, or your whole database, on your account. Check and fix it: exposed secrets and API keys in frontend code.
Gap 3: Open storage buckets
If users upload anything — profile photos, documents, ID images — those files live in a storage bucket. On both Supabase and Firebase, buckets can be left publicly readable. That means anyone who finds or guesses a file URL can download everything, including other people's private uploads.
This is not hypothetical. The Tea app breach (July 2025) came from an unsecured Firebase storage bucket: roughly 72,000 images exposed, including about 13,000 selfies and government IDs, followed by a second breach of over 1.1 million private messages.
The stake: every file your users uploaded, downloadable by strangers. Check and fix it: Supabase storage bucket security and open storage buckets on Firebase.
Gap 4: No auth, or auth you can bypass
Some endpoints forget to check whether the request comes from a logged-in, authorized user. The feature may look locked in the interface — a button that's hidden, a page that redirects — while the underlying request stays wide open to anyone who sends it directly.
That's exactly how the Base44 incident worked: a public app identifier plus some undocumented endpoints let anyone create a verified account inside any private app, bypassing single sign-on entirely. Around 20,000 users were exposed before Wix patched it.
The stake: strangers acting as authorized users, reading or changing data they shouldn't reach. Check and fix it: is Base44 safe.
Gap 5: SSRF (Server-Side Request Forgery)
SSRF is when an attacker tricks your server into making a request on their behalf — often to reach internal systems that aren't supposed to be accessible from the outside. Any feature where your app fetches a URL the user provides (importing from a link, generating a preview, calling a webhook) is a candidate.
This one is striking because of how consistent it is. When security firm Tenzai built 15 apps across Cursor, Claude Code, Replit, Devin, and OpenAI Codex in December 2025, every single tool introduced SSRF. Not most. All of them.
The stake: your server reaching into your own internal network for an attacker. Learn more: the complete guide to vibe coding security covers the full risk map, and your platform guide covers tool-specific notes.
Gap 6: Missing CSRF protection and security headers
Two related gaps that AI builders almost never add on their own.
CSRF (Cross-Site Request Forgery) is an attack where a malicious site causes a logged-in user's browser to perform an action on your app without their intent — like changing their email or making a purchase. CSRF protection stops that. Security headers are standard HTTP settings that harden a site against a range of common attacks.
In the same Tenzai testing, zero of the tools implemented CSRF protection, and zero set security headers. These are baseline web protections, and the AI skips them by default across the board.
The stake: actions taken on your users' behalf without their consent, and a site missing its basic armor. Learn more: the complete guide explains how to surface these, since they don't show up in your dashboard.
Gap 7: Source maps publishing your source code
When an AI builder deploys your app, it often publishes source maps — files that map the compressed, shipped code back to your original, readable source. They're a debugging convenience. The problem is they let anyone reconstruct your full source code, including comments, internal logic, and sometimes hardcoded secrets that you assumed were hidden.
This turns several of the gaps above into easy targets: an attacker reading your source map can spot exactly which endpoints lack auth and which keys are where.
The stake: your private source code, readable by anyone, handing attackers a map. Check and fix it: your source maps are publishing your source code.
How to check your own app
You can make a real dent in an afternoon. Roughly in priority order:
- Database rules first. Confirm RLS is enabled and actually restricts rows (not
USING (true)) on every Supabase table with user data. On Firebase, make sure you're out of open test mode. - Hunt for secret keys in your frontend —
sk_live_, service keys, AI provider keys. Ignore publishable and anon keys. - Open a file URL logged out. If a user upload loads without a login, your bucket is public.
- Trigger a gated action while signed out. If it works, you have an auth gap.
- Check whether source maps are published on your live site.
The last three of the seven — SSRF, CSRF and headers, and to some degree source maps — are hardest to verify by hand because they don't appear in any dashboard. That's where a scan of your deployed app earns its keep: it tests the live site the way an attacker would.
Want all seven checked at once?
Run a free, read-only scan of your live app — no install, results in under a minute.
Scan my app free →Don't let the false alarms eat your time
A quick word on what not to chase. Plenty of scanners will flag your Supabase anon key, your Firebase web config, or a Stripe pk_live_ key and present them as urgent. They're not. All three are public by design — identifiers meant to live in the browser, not passwords. A scanner that can't tell a publishable key from a secret one will bury the gaps that matter under a pile of ones that don't.
So as you work the list, hold this rule: a long list of red flags is not a list of real problems. The seven gaps above are the real problems. Most of the loud warnings about public keys are noise.
FAQ
How do I know if my vibe-coded app is leaking data right now?
The fastest honest test is to act like an outsider: query your app's data endpoints without logging in, open a user-upload URL in a private window, and check your frontend for secret keys. If any of those return data they shouldn't, you have a live leak. The seven gaps above are where to look, in priority order.
Which of the seven gaps is most urgent?
Missing or USING (true) database rules (Gap 1). It's the most common cause of real leaks in AI-built apps, it exposes the most — often your entire user table — and it's checkable in minutes. Fix that first, then work down the list.
Do all of these apply to every AI builder?
The flaw classes recur across all of them because they share defaults — the Tenzai testing found SSRF, missing CSRF, and missing headers across Cursor, Claude Code, Replit, Devin, and Codex alike. Which gaps you actually have depends on your specific app and stack, but this list is the right place to start regardless of the tool.
The bottom line
A vibe-coded app doesn't leak in mysterious ways. It leaks through seven recurring gaps: missing database rules, exposed secret keys, open storage, missing auth, SSRF, missing CSRF and headers, and published source maps. Each is checkable, most by a non-developer, and the loudest warnings about public keys are usually noise. An attacker can find these in minutes by looking. Find them first — and re-check on every deploy, because your AI ships new code and new gaps each time you add a feature.
Find your gaps before an attacker does.
Is My Site Hackable? scans your deployed app for the exact issues in this article — exposed keys, missing RLS, open buckets — and tells you what's real and what's a false alarm.
Run a free scan →