In the first three months of 2026, researchers at Georgia Tech logged more security vulnerabilities traceable to AI coding tools than in all of 2025 combined. Their Vibe Security Radar counted 6 new CVEs in January, 15 in February, and 35 in March, and the team believes the real number across open source is five to ten times higher. The AI coding tools got faster. Apps can be shipped in one afternoon. But sadly security did not keep up.
Most articles about vibe coding security stop at that statistic and sell you a scanner. This one goes further, because the harder question is not whether AI-generated code has holes. It is why the platform you built on won’t close them for you. When you spin up an app on Lovable, Replit, Bolt, or Base44, the builder hands you working software and the security liability in the same package, and only one of those two things is visible on screen.
The app that runs and the app that is safe to ship are not the same app, and vibe coding makes it dangerously easy to confuse them. If you have already shipped one, our vibe code cleanup services exist to close exactly this gap.
Why vibe-coded apps fail security even when they work?
An AI agent prioritizes one thing above all: making the feature work. Security is a non-functional requirement, so the model treats it as secondary, which means a vibe-coded app can look finished long before it is safe. The demo passes, the buttons respond, the data saves. None of that tells you whether a stranger can read that data too. This is the blind spot at the center of every vibe coding security problem.
The “it compiles, so it’s safe” illusion
The evidence on vibe coding security is not reassuring. Veracode tested over 100 large language models across 80 coding tasks and found that 45% of AI-generated samples introduced an OWASP Top 10 vulnerability, a failure rate that did not improve across testing cycles from 2025 into 2026. Cross-site scripting defenses failed in 86% of relevant samples. A separate benchmark paper, Is Vibe Coding Safe?, found that while 61% of solutions from a leading coding agent were functionally correct, only 10.5% were secure. Adding vulnerability hints to the prompt did not fix it.
The reason sits deeper than any single bug. As one security trainer put it in a recent talk, an LLM operates on syntax, not semantics, following the rules for producing code that looks right the way the person in the Chinese Room thought experiment follows rules for arranging characters they cannot read. The output is fluent. The understanding is absent. So the model happily writes a login flow that authenticates users and, in the same breath, one that never checks whether the logged-in user is allowed to see the record they just requested.
The trust model collapses on shared platforms
When Wiz disclosed the Base44 vulnerability in 2025, the structural point mattered more than the specific flaw. On an end-to-end builder, you cannot inspect the authentication implementation, the storage configuration, the access controls, or the routing rules. You trust the platform to get all of them right, and when it gets any one of them wrong by default, every app built on top inherits the failure.
That is not a hypothetical. In early May 2026, the firm RedAccess scanned roughly 380,000 applications built on vibe-coding platforms and found about 5,000 leaking sensitive data, from medical records to internal bank financials. The default-public setting alone produced thousands of confirmed leaks before anyone counted a single platform-side bug. You did not write that default, and you cannot see it, but you are still responsible for it.
What the AI builders don’t protect you from?
The failures repeat. An academic study of real vibe-coded applications identified the same recurring patterns across the board: placeholder logic left in place, unfiltered input, and exposed secrets. Those patterns map almost directly onto the OWASP Top 10 for LLM Applications 2025, where sensitive information disclosure sits at number two. Here are the four vibe coding security risks that show up most often, and what each one costs.
Misconfigured row-level security
Row-level security is the filter that lets your app talk directly to the database while still limiting each user to their own rows. On Supabase and Firebase it is the single most important control, and it is the single most common thing to get wrong.
In March 2025, a Replit engineer removed one authorization header from a request to a Lovable-built app and got back what looked like the entire user database. He and a colleague ran the same check against 1,645 apps Lovable was showcasing, and 170 of them, roughly one in ten, leaked user data through the identical flaw. The vulnerability became CVE-2025-48757. An earlier sample found around 70% of Lovable apps had row-level security switched off entirely.
There is a subtler trap that even careful builders fall into. You can configure RLS perfectly, restricting every user to reading and writing only their own data, and still lose if you store the wrong fields on that table. One developer stored subscription status and API rate limits on the same user row that users were allowed to edit. The RLS was technically correct, yet it let any user flip themselves to premium and lift their own usage caps. The lesson is uncomfortable: correct access control on the wrong data model is still a breach waiting to happen.
- Ask the specific question, not the general one like”Check my RLS” catches little. Instead ask “Can a user modify their own subscription status or rate limits? Can they read another user’s row?” it catches the real flaws.
- Keep editable and privileged data on separate tables – anything a user should never change does not belong on a row they can write to.
- Audit the config directly – point the tool at the platform’s own configuration through its MCP integration rather than pasting screenshots or SQL dumps.
Secrets and keys exposed in the frontend
There is a persistent myth that an API key is safe once it sits in an environment variable. On a frontend, it is not. Environment variables are only private on a backend, and anything shipped to the browser or bundled into a mobile app can be extracted. The Moltbook incident is the clean example.
The AI-agent social network was, by its creator’s own account, built without a single hand-written line of code. Wiz researchers browsed it like a normal user, found a Supabase key sitting in client-side JavaScript, and within three minutes had read-write access to the entire production database: 1.5 million API tokens, 35,000 email addresses, and private messages.
Apiiro’s research found a 40% jump in exposed secrets in AI-generated code, because the model hardcodes credentials based on the patterns it learned in training.
The fix is architectural, not cosmetic. Sensitive calls to payment processors, email services, cloud storage, and AI providers belong on a backend the user cannot reach, never on the client. This is precisely the gap that Supabase Functions and Firebase Functions were built to fill.
No rate limits and denial-of-wallet
Frontend rate limits are theater. Anyone can find your backend endpoint in the network tab, and the same applies to mobile apps even without a visible network tab. Once an attacker hits the endpoint directly, any limit you enforced in the interface is gone. When that endpoint calls a metered service, an AI provider, a cloud function, a usage-billed database, the result is what the security community now calls denial of wallet – your normal $10 a day becomes a $10,000 bill overnight. The stories are real and repeated, including developers who woke up to five-figure charges after a leaked key was used to run machine-learning training on their account.
Two controls stop most of it. Enforce per-user rate limits on the backend, stored somewhere the user cannot edit, and add IP-based limits on top so a flood of throwaway accounts still hits a ceiling. Then set a hard budget cap on every provider that offers one, and an alert on every provider that does not. An app that goes dark for an hour is a far better outcome than a bill you have to argue your way out of.
Dependency bloat and slopsquatting
AI agents are notorious for pulling in a whole library to use one function from it. Every added dependency widens your attack surface, and vibe-coded projects accumulate them fast. Worse, a new class of supply-chain attack has grown up around this habit. Attackers watch which package names LLMs tend to hallucinate, then register those exact names on npm or PyPI and fill them with malware, a technique known as slopsquatting. The model confidently imports a package that did not exist until an attacker created it to catch exactly this mistake. Review what the agent wants to install, remove anything used only once, and keep the remaining dependencies pinned and current.
What secure vibe coding actually looks like?
Here is the fair part, and both the practitioners I studied for this piece agree on it: vibe coding is not inherently insecure. Used with a human who knows what the code is doing, it can produce safer software than a tired developer writing everything by hand, because the model does not get fatigued and can reason through edge cases at 2 a.m. that a person would miss. The problem is never the vibe coding. The problem is unreviewed deployment. Good vibe coding security is a set of habits, not a tool you buy.
Threat model before you prompt
The highest-value habit costs nothing and happens before you write a line. Answer four questions: what are we building, what can go wrong, what are we going to do about it, and did it work. That is a working threat model. Do it when you plan a feature, keep it in a file the coding agent updates as it goes, and you have already caught the class of flaw that static scanners find last. Treat the AI as something that augments your judgment, not something you outsource it to.
The pre-ship security checklist
Before an app that stores real data or touches real money goes live, walk this list. None of it requires you to be a security specialist, and all of it catches the failures above.
- Audit RLS by scenario, not in general. Test the specific bypasses: subscription status, rate limits, one user reading another’s data.
- Move every sensitive call to the backend. Payment, email, storage, and AI-provider calls never run from the client.
- Confirm no secrets ship to the frontend. Keys live on the backend or in a secret store, never in client code or a mobile bundle.
- Enforce backend rate limits plus IP limits. Store the counters where users cannot edit them.
- Set budget caps and alerts on every metered provider. Assume a key will leak and cap the damage in advance.
- Review and prune dependencies. Drop single-use libraries, pin versions, watch for hallucinated package names.
- Connect the platform’s own audit tooling. Give the coding agent direct access to the Supabase or Firebase configuration rather than pasted dumps.
When to bring in engineers?
There is a ceiling to what self-auditing catches, and it is worth being honest about where it sits. Asking the model to review its own code is genuinely useful for the common misconfigurations. It reliably misses the architectural and business-logic flaws, the ones where the code is technically correct but the underlying design lets someone abuse it, because catching those needs a view of the whole system that a context window does not hold. That is the point at which a vibe-coded project stops being a solo effort and needs people who audit systems for a living. Fingoweb’s cleanup work on vibe-coded projects starts exactly here: a full audit of the AI-generated codebase, then the remediation that makes it safe to ship and safe to grow. If your app already has users, that audit is not premature. It is overdue.
FAQ about vibe coding security
Is vibe coding safe for production apps?
Vibe coding is safe for production only when a human reviews the output before it ships. The code an AI agent generates is functional far more often than it is secure, with independent testing putting the secure rate near 10% on real-world tasks. For a prototype or internal tool the risk is low. The moment the app stores real user data or handles money, it needs an explicit security review, because the platform will not run one for you.
What are the most common vibe coding security risks?
The four that appear most often are misconfigured row-level security that exposes other users' data, API keys and secrets left in frontend code, missing backend rate limits that enable denial-of-wallet attacks, and bloated or hallucinated dependencies that widen the attack surface. All four share a root cause: the AI aims for a working feature and treats security as an afterthought.
Can I just ask the AI to audit its own code?
Partly, and it is worth doing, but do not stop there. AI code review is effective at catching the common, well-documented misconfigurations. It is unreliable on the harder cases:
- Business-logic flaws where the code is correct but the data model lets a user escalate their own privileges.
- Architectural issues that only appear when you see how endpoints interact across the whole system.
- Cost-abuse paths where a technically valid request can be replayed to run up a bill.
Use it as a first pass, then have a person, or a firm that does this professionally, check what it missed.
Which vibe coding platform is most secure?
No platform is secure by default in a way that removes your responsibility. Lovable, Base44, Replit, and their peers have all had documented incidents, and the shared-infrastructure model means a single platform-side default can expose thousands of apps at once. Security depends far more on how you configure access controls, secrets, and rate limits than on which builder you picked. Treat every platform as a starting point that still needs hardening.
How do I know if my vibe-coded app has already been breached?
You often cannot tell from the app itself, because a data leak through misconfigured access control leaves the app working normally. Check for unexpected spikes in database reads or API costs, review your provider logs for requests from unfamiliar sources, and test whether removing an authorization header from a request still returns data it should not. If any of that is inconclusive and the app handles sensitive information, a professional audit is the reliable way to find out before an attacker does.
