Vibe Coding Security: The Complete Guide

You described an app to an AI, watched it appear, and shipped it. It works. Real people are signing up. And now a quiet worry has set in: you never wrote the code, so you have no idea whether your users' data is safe. Maybe a scanner flagged something. Maybe a Reddit thread mentioned a breach. You're not even sure what you'd be looking for.

That worry is reasonable, and it's also fixable. The security gaps in AI-built apps are not random or mysterious. They cluster into a handful of recurring patterns, and most of them are checkable in an afternoon.

This is the complete guide to vibe coding security: what vibe coding is, why AI-built apps tend to ship with holes, the specific risk classes that matter, and exactly how to check your own app. It links out to deeper guides on each topic, so think of this as the map. By the end you'll know what to look for and what to ignore.

⚡ TL;DR

• AI builders optimize for "it works in the preview," not "it's secure." Independent research found 45% of AI-generated code samples failed security tests — so insecure-by-default is the norm, not bad luck.
• The gaps cluster: missing database access rules, leaked secret keys, open file storage, missing authentication, and missing web protections like CSRF and security headers.
• Some flags are false alarms. Your Supabase anon key and Firebase web config are public by design. Don't waste a day rotating a key that was never the problem.
• You can check your live app for all of this in minutes, and you should re-check on every deploy, because your AI ships new code (and new holes) each time you add a feature.

What "vibe coding" actually means

The term "vibe coding" was coined by Andrej Karpathy in February 2025. The idea: you describe what you want in plain language, an AI writes the code, and you steer by feel rather than by reading every line. Collins Dictionary named it the Word of the Year for 2025. Search interest surged roughly 6,700% between March and May 2025. It went from a tweet to a movement in a single quarter.

The reason it caught on is that it works. Tools like Lovable, Bolt, v0, Cursor, and Replit can turn a sentence into a running app with a database, login, and payments. And most of the people using them are not professional developers. Vercel's usage data puts non-developers at about 63% of vibe-coding users; Lovable separately reports around 60%.

That last fact is the whole reason security matters here. A traditional engineering team has someone who knows to lock the database before launch. A founder shipping their first app with an AI often does not — not because they're careless, but because the tool never told them there was a lock to check.

Why AI-built apps are systematically insecure

Here's the core problem, and it's worth understanding because it explains everything else.

When you ask an AI builder to "let users save their profiles," it optimizes for one outcome: the feature working in the preview window. A database table with its access rules switched off works perfectly in a demo. You can read rows, write rows, the app looks finished. The security hole is invisible until someone goes looking. The AI has no incentive to add protection you didn't ask for, and you didn't know to ask.

This isn't a hunch. The research is consistent and unflattering:

• The Veracode 2025 GenAI Code Security Report tested over 100 large language models across 80 coding tasks. 45% of the code samples failed security tests — they introduced vulnerabilities from the OWASP Top 10, the industry's standard list of common web flaws. Veracode CTO Jens Wessling put it plainly: "Our research reveals GenAI models make the wrong choices nearly half the time, and it's not improving."
• Carnegie Mellon's SusVibes benchmark found the same gap from another angle. The best AI setup it tested produced functionally correct code 61% of the time but secure code only 10.5% of the time — meaning over 80% of the solutions that worked were still vulnerable. Working and safe are not the same thing, and the AI optimizes for the first one.

So the model to hold in your head: an AI-built app that runs flawlessly tells you nothing about whether it's secure. The two are nearly independent. We unpack the research in 45% of AI-Generated Code Ships With a Vulnerability, and the underlying incentive in why AI optimizes for "it works," not "it's secure".

The main risk classes (and where to go deep)

Almost every real-world leak in an AI-built app falls into one of these categories. Each has its own deep-dive guide; this section is the overview so you know which ones apply to you.

1. Data exposure: missing database access rules

This is the big one. Most vibe-coded apps use Supabase as their backend — it's the default for Lovable, Bolt, v0, Replit, and Cursor templates. Supabase apps talk to the database directly from the browser, with no backend server in the middle to check "is this person allowed to see this?" The database itself is the gatekeeper, and the mechanism it uses is RLS (Row Level Security) — a rule that filters which rows each user can see, applied automatically to every query.

When RLS is off, or set to a policy that allows everyone, any visitor can pull every row from your tables. This is the single most common way AI-built apps leak data. Start with Supabase security for AI-built apps, the cornerstone for this whole topic.

2. Exposed secrets and API keys

AI builders sometimes place secret keys directly in the frontend code — the part of your app that ships to every visitor's browser. A secret database key, a payment processor's secret key, or an AI provider key sitting in your frontend can be extracted by anyone in minutes. The result ranges from someone reading your entire database to running up a five-figure bill on your account.

The nuance, which we'll keep returning to: not every key in your frontend is a problem — some are meant to be there. The full guide is exposed secrets and API keys in frontend code.

3. Open file storage

If your app lets users upload images, documents, or anything else, those files live in a storage bucket. On both Supabase and Firebase, buckets can be left publicly readable, which means anyone who can guess or find a file URL can download everything in the bucket — including other users' private uploads. This is exactly how the largest vibe-coding-adjacent breach of 2025 happened. See Supabase storage bucket security and open storage buckets on Firebase.

4. Firebase rules and the public web config

Firebase is the other common backend. Its access model runs on Security Rules — a small ruleset that decides who can read and write your data. AI tools frequently generate rules that are far too permissive, or leave the database in open test mode. As with Supabase, there's a public-by-design key here too. The full picture is in Firebase security for AI-built apps.

5. Missing authentication and auth bypass

Some endpoints forget to check whether the request is from a logged-in, authorized user. An AI may build a feature that looks gated in the interface but leaves the underlying API call open to anyone who sends it directly. This is how the Base44 incident worked, which we cover in is Base44 safe.

6. Web protections the AI never adds

This is the least visible class and one of the most consistent. Security firm Tenzai built apps across Cursor, Claude Code, Replit, Devin, and OpenAI Codex in December 2025 and found a stark pattern. Every single tool introduced SSRF — Server-Side Request Forgery, a flaw that lets an attacker trick your server into making requests it shouldn't, often to reach internal systems. Zero implemented CSRF protection — Cross-Site Request Forgery, which stops a malicious site from acting on a logged-in user's behalf. And zero set security headers, the standard HTTP settings that harden a site against common attacks. These aren't exotic. They're table stakes that AI builders skip by default.

Per-platform risk

The risks above show up differently depending on which tool you used. For the specifics on your stack, each platform has its own guide — for example, is Lovable safe, is Cursor safe, is Replit safe, and is Base44 safe. The same flaw classes recur across all of them, because they share the same defaults.

What these gaps have actually caused

The patterns above aren't theoretical. A short list of documented incidents from 2025 and early 2026:

• Enrichlead (March 2025) was built with Cursor and, in the founder's words, "zero hand-written code." Within about two days of attention, it had its paywall bypassed, its API keys maxed out, and garbage written into its database. The founder shut it down.
• The Tea app (July 2025) left a legacy Firebase storage bucket unsecured. Roughly 72,000 images were exposed, including about 13,000 selfies and government IDs; a second breach exposed over 1.1 million private messages. It's now consolidated class-action litigation in California.
• Base44 (July 2025) had an authentication bypass found by Wiz Research: a public app identifier plus some undocumented endpoints let anyone create a verified account inside any private app, bypassing single sign-on. Wix patched it in under 24 hours with no evidence of exploitation, but its ~20,000 users were exposed in the meantime.
• Moltbook (January 2026), a Supabase-backed AI social network with missing RLS, exposed roughly 1.5 million API keys and about 35,000 user emails. Some private messages even contained plaintext AI provider keys.

And the first published vulnerability for this whole category, CVE-2025-48757, was disclosed in May 2025: a scan of 1,645 Lovable-built apps found 170 of them — about 10% — leaking real user data through missing or permissive RLS. The full story, in order, is in the vibe-coding breach timeline.

The thread running through all of these: none required a sophisticated attack. They required someone to look.

How to check your own app

You don't need to be a developer to do a first pass. Here's a practical checklist, roughly in order of how much damage each gap can do.

1. Check your database access rules. If you're on Supabase, open the dashboard and confirm every table holding user data has RLS enabled — and that the policy actually restricts rows, not a "match everyone" rule. If you're on Firebase, review your Security Rules and make sure you're not in open test mode. This is the highest-priority item.
2. Look at your storage buckets. Confirm that user uploads aren't in a publicly readable bucket. Try opening a file URL in a private browser window — if it loads without a login, so will everyone else's.
3. Scan your frontend for secret keys. A secret key (as opposed to a publishable one) should never be in code that ships to the browser. We'll cover how to tell the difference in a moment.
4. Test an important action while logged out. Pick a feature that should require an account. Try to trigger its underlying request without being signed in. If it works, you have an auth gap.
5. Re-check after every deploy. This is the one most people skip. Your AI adds new tables, endpoints, and keys every time you build a feature — each one a fresh chance to introduce a gap. A check you ran last month doesn't cover code you shipped yesterday.

The part most scanners get wrong

There's a trap in security scanning that's worth knowing about, because falling into it wastes your time and trains you to ignore real warnings.

Many scanners flag things that are public by design and present them as emergencies. The three big ones:

• The Supabase anon key is meant to live in your browser. It is not a leak. Supabase built its entire permission model around the assumption that this key is visible to everyone. The real risk is missing or permissive RLS, not the key. Rotating the anon key changes nothing.
• The Firebase web config, including its apiKey field, is public by design too. It's an identifier, not a password. The real risk is permissive Security Rules and open buckets.
• A Stripe publishable key (it starts with pk_live_) is meant to ship in your frontend. The emergency is a secret key (sk_live_) in the same place.

🐺 Not a real problem

If a tool tells you to panic about your Supabase anon key, your Firebase web config, or a Stripe pk_live_ key, it's crying wolf. Those are public by design. Name the real root cause instead: missing access rules, permissive Security Rules, or a leaked secret key. A scanner that can't tell the difference will bury the one warning that matters under a pile of ones that don't.

This is the most useful instinct you can develop. A long list of red flags is not a list of real problems. Find the gaps that actually expose data, ignore the noise, and act when something really needs fixing. For the secret-versus-publishable distinction in detail, see exposed secrets and API keys in frontend code.

How to fix the common gaps

The fixes are usually short. A quick reference:

• Missing RLS (Supabase): enable Row Level Security on every table with user data, then add a policy tying each row to its owner — typically auth.uid() = user_id. Avoid the "match everyone" policy. Walkthrough in Supabase RLS explained.
• Permissive Security Rules (Firebase): replace open test-mode rules with rules that require authentication and scope access to the requesting user. See Firebase security for AI-built apps.
• Open buckets: make buckets private by default and serve files through signed, time-limited URLs.
• Exposed secret key: rotate it immediately, then audit what it touched, then add monitoring — in that order.
• Missing auth on an endpoint: add an authentication check server-side, never only in the interface.
• SSRF, missing CSRF, missing headers: these need server-side handling that the AI won't add on its own. A scan that tests your deployed app the way an attacker would is the most reliable way to surface them, since they don't show up by reading your dashboard.

A good prompt to give your AI builder for the database piece: "Enable Row Level Security on every table that stores user data and add policies so each user can only read and write rows where user_id equals their auth.uid(). Do not use a policy that matches every row."

FAQ

Is vibe coding safe?

Vibe coding is safe to build with. The apps it produces are not secure by default — that's the gap. The tool gets you a working product fast; it does not lock the doors for you. The good news is that the common gaps are well understood and checkable. Safe vibe coding is less about the tool you choose and more about doing a security pass before you launch and after each deploy.

Is "vibe coding" still a thing, or is the term going away?

The term may fade — even Andrej Karpathy, who coined it, has leaned toward "agentic engineering" as the more durable phrase. But the practice and the security concerns are here to stay. Whatever you call it, AI is writing the code, and the gaps it leaves — missing access rules, exposed keys, open buckets — are the same.

What's the single most important thing to check?

Your database access rules. For most vibe-coded apps that means Supabase RLS. It's the most common cause of real data leaks, it's the highest-impact, and it's checkable in a few minutes. Start there.

The bottom line

Vibe coding lets anyone ship a real app, and that's real power — but the AI optimizes for working, not for safe, and the research shows the two come apart almost half the time. The gaps cluster into a short list: database access rules, exposed secret keys, open storage, missing authentication, and missing web protections. Most are checkable in an afternoon, and some of the loudest warnings — the anon key, the Firebase config, the publishable Stripe key — are not problems at all. An attacker can find your real gaps in minutes, by looking. The job is to find them first, and to keep checking, because your AI ships new code and new holes on every deploy.