Vibe Coding Security Risks: The Data Behind the Exposure Gap

One in five organizations building on vibe-coding platforms has inadvertently exposed themselves to security risk through common misconfigurations, according to Wiz Research. That’s not a projection or a vendor sales pitch — it’s an observed pattern from real deployments. The vibe coding security risks that matter most aren’t exotic zero-days or sophisticated supply chain attacks. They’re the boring, predictable defaults that AI tools ship with: public storage buckets, client-side authentication, hardcoded secrets, and unprotected API routes. And the people building these apps can’t see them.

Here’s the tension that shapes everything I’m about to walk through: the data attributes massive security catastrophe to vibe-coded apps in the wild, yet professional developers largely avoid vibe coding for production. Per Axis Intelligence’s analysis of Stack Overflow’s 2025 survey, 77% of professional developers do not vibe code for production work — 72% said it wasn’t part of their workflow, and 5% said “emphatically not.” The catastrophic exposure comes from non-professionals deploying to production unnoticed, while the broader discourse frames it as a general software development risk. It isn’t. It’s a governance gap created by a specific class of builder using a specific class of tool.

The Velocity Exposure Gap: Why Speed Is the Vulnerability

The core problem isn’t that AI writes bad code. It’s that vibe-coded applications are deployed to production by non-engineers at a velocity that outruns both traditional governance cycles and the builders’ ability to perceive security gaps. This creates what I’d call a velocity exposure gap — a continuous exposure window rather than a one-time vulnerability.

Consider the cadence. A traditional penetration test happens once a year. A vibe-coded app can change more in a single week than a traditional codebase changed across that whole year. When features land in hours and the builder never reads the diffs, there’s no checkpoint where a human catches a misconfiguration. The app ships, serves real users, and accumulates risk with every iteration.

The Teyrex audit of 35 vibe-coded apps quantifies this brutally:

• 100% had no rate limiting — open doors for abuse, scraping, and runaway API bills
• 100% had no automated tests — every change was a gamble against silent regressions
• 95% had SQL injection vulnerabilities — the oldest web vulnerability, reintroduced at scale
• 85% had unprotected API routes — anyone who found the URL could call it
• 80% had hardcoded secrets and config — credentials committed straight into the codebase
• 80% had junk and dead code — noise that hides real bugs and slows every future change

A typical app carried 15-30 distinct issues across these categories. Let that sink in. Not one app in the sample had rate limiting. Not one had meaningful tests. The issue isn’t that AI occasionally produces a vulnerability — it’s that the entire workflow has no quality gate between the AI output and the public internet.

Who’s Actually Building These Apps (and Why That Matters)

The data reveals a paradox that most coverage misses. Pure vibe coding remains a non-developer and prototyping phenomenon. The people shipping these apps aren’t engineers who chose to skip code review — they’re people who have never performed a code review and don’t know what one looks like.

RedAccess researchers analyzed thousands of applications created on platforms like Lovable, Replit, Base44, and Netlify. They identified more than 5,000 applications with little or no security controls or authentication. Nearly 40% exposed sensitive information — medical records, financial data, internal business documents, and customer conversation histories.

The issue wasn’t malicious intent. It was software being deployed faster than it could be secured. When a marketer builds an internal tool in an afternoon and it starts collecting customer data, nobody flags the transition from “personal prototype” to “business system handling regulated information.” The builder doesn’t know to ask, and the platform doesn’t tell them.

This is why the AI coding security checklist we published matters here: traditional security controls were designed around the assumption that a skilled engineer operated within a structured development lifecycle. Architecture reviews, code reviews, security testing, deployment approvals — all of these assumed a human who could interpret the output. Remove that human and the entire governance model breaks.

The AI’s Path-of-Least-Resistance Defaults

Here’s the contrarian take: the most severe vulnerabilities in vibe-coded apps aren’t from missing engineer skill. They’re from the AI’s path-of-least-resistance defaults — choices the model makes because they’re easy, not because they’re correct. And non-technical builders can’t recognize them.

A Thoughtworks case study documents a vibe-coded video-assembly prototype built with Gemini, Replit AI, and Claude AI, intended for 10,000 employees. The AI recommended making a cloud storage bucket public — “anyone with the link.” When challenged, it justified the choice by saying every company does it. Only a firm rejection produced a secure alternative. In the same project, the AI assigned a service account the Access Token Creator role, far beyond what the task needed.

These aren’t bugs. They’re defaults. The AI optimizes for “works in demo” and the builder has no way to distinguish that from “secure in production.” The same speed that creates the app prevents the builder from ever perceiving the gap.

Wiz Research found a common pattern: applications handling the entire authentication process on the client side, with passwords embedded directly in JavaScript files visible to anyone who inspects the source. The browser downloads all the code meant to “protect” the app. The password is right there in the bundle.

Bob Starr, a project manager, launched a vibe-coded website called “Boomberg” and realized months later it had a hidden SQL injection risk that could let an attacker read or alter data. “It was just a glaring oversight on my part,” he said. “It was a complete blindspot in my state of learning this new technology.” He’s being too hard on himself. The blindspot isn’t his — it’s structural. The tool didn’t warn him because the tool doesn’t know to.

The Overengineering Problem Nobody Talks About

The stereotype says AI-generated apps are too simple. The data says the opposite. The Teyrex audit found most apps were overengineered — layers of abstraction, premature infrastructure, and dependencies far beyond what the product needed. Several clients came to Teyrex because simple applications were generating outsized infrastructure bills.

This matters for security because overengineering creates auditability problems. Junk code, dead code, unused components shipped to production — all of it creates noise that hides real bugs. When 80% of audited apps had significant volumes of code that no execution path reaches, you’re not maintaining an application. You’re maintaining a pile of code that nobody can fully understand, including the AI that generated it.

The tradeoff here is sharp: ship speed versus maintainability. Features land in hours, but the codebase grows beyond anyone’s comprehension. Silent swallowed errors — failures that never surface anywhere a human would see — make features look like they work when they don’t. One Teyrex audit found that simply enabling the linter reported over 1,000 errors that had been silently swallowed across the application.

If you’re tracking the cost side of this equation, our analysis of vibe coding’s real cost curve covers how free tiers collapse and infrastructure bills balloon. The security cost is the other half of the same problem: you’re paying for complexity you don’t need and can’t audit.

What the Tooling Landscape Actually Covers

Security tooling is rapidly productizing for vibe-coded apps, but the audited reality shows these apps change daily and carry overwhelming issue density that scheduled tests may not outpace. Here’s what’s available and where the gaps remain:

Tool	Pricing	Key Capability	Target Audience
Lovable + Aikido	$100/test per Lovable	Built-in pentesting, SOC 2/ISO 27001 support	Non-technical founders on Lovable platform
VibeZero	—	Continuous daily pentesting against live app	Vibe-coded apps that change daily
VibeDoctor	—	Production readiness checks, live site analysis	Solo founders and non-technical builders

Lovable’s built-in pentesting at $100 per test is a genuine step forward compared to the $5,000–$50,000 that traditional engagements cost. But here’s the math problem: based on the Teyrex audit data, a team running 10 vibe-coded production apps with typical issue density (15-30 issues per app) would spend $1,000 for 10 single-test runs (10 apps × $100 = $1,000). That covers one test per app. Remediation of the 150-300 distinct issues across those apps is not included. And if the apps change daily — which they do — a single test is a snapshot that goes stale within a week.

VibeZero positions continuous pentesting as the answer, running daily tests against the live application from the public internet. The logic is sound: shrink the window between a vulnerability shipping and someone noticing it from a year down to a day. But the question remains whether daily testing can keep pace with apps that accumulate 15-30 distinct issues per build cycle.

VibeDoctor targets the non-technical founder with simple readiness checks — closer to what the actual user base needs, but still early.

The deeper problem is that none of these tools address the root cause: the builder cannot and will not read the diffs. You can test after the fact, but you’re always catching up.

The Real Risk: Elimination of the Human Comprehension Checkpoint

Veracode’s 2025 GenAI Code Security Report tested more than 100 LLMs across 80 coding tasks and found AI introduced security vulnerabilities in 45% of cases. Aikido’s 2026 survey of 450 developers found 1 in 5 organizations reported a serious security incident linked to AI-generated code.

Those numbers are significant, but they understate the problem. The real risk isn’t vulnerable code — it’s the elimination of the human comprehension checkpoint. When a developer writes code, even with AI assistance, they review the output. They catch the public bucket. They question the client-side auth. They notice the hardcoded secret. Pure vibe coding removes that human by design. The builder hits “Accept All” and the code grows beyond their comprehension.

This is why the solution can’t be “teach builders to code” or “add more scanning.” The builder won’t read the diffs. The AI’s secure-by-default behavior can’t be assumed. Apps must be governed by continuous external testing and interface-level controls — sandbox boundaries, agent permissions, automated security gates that run before deployment, not after.

The MCP security risks we’ve documented elsewhere follow the same pattern: tools that execute with legitimate credentials, no alert triggers, and no human in the loop. The agent config poisoning problem is the same architectural gap at a different layer. When the agent runs with your credentials and no one reviews what it did, the attack surface is everything the agent can touch.

A Decision Framework for Teams Facing This

If you’re an engineering leader or security professional dealing with vibe-coded apps in your environment, here’s how I’d think about the tradeoffs:

If you’re a non-technical builder shipping production apps: You need external validation before every deploy. Not after. Not once a year. Continuous pentesting or at minimum automated security scanning before each release is non-negotiable. Budget for it the same way you budget for hosting. A $100 pentest is cheap; a data breach involving medical records or financial data is not.

If you’re an engineering team with vibe-coded apps in your environment: Find them first. The RedAccess data suggests there are likely more than you think — 5,000+ apps with no auth across just four platforms. Inventory what’s running, who built it, and what data it touches. Then apply the same security controls you’d apply to any production system: rate limiting, auth, secrets management, dependency scanning.

If you’re evaluating vibe coding tools for production use: The tool that wins isn’t the one with the best code generation. It’s the one that integrates transparently into existing security workflows — CI/CD gates, SAST scanning, secrets detection, dependency validation. The Teyrex data found that by the time an app reaches audit, the question isn’t which tool wrote it, but whether anyone ever reviewed what was written. Nothing in the data suggests one tool produces meaningfully safer unreviewed output than another.

The open question I’ll leave you with: if 100% of audited vibe-coded apps lacked rate limiting and automated tests, and the builders by definition cannot read the code they’re shipping, who is responsible for the gap between “works in demo” and “secure in production”? The platform that generated the code? The builder who deployed it? The security team that didn’t know it existed? Until that accountability question gets answered, the velocity exposure gap will keep widening — and the 20% exposure rate from the Wiz data will climb.