Vibe Coding Security: The Real Risk Ranking From 26 Audits

Vibe coding security spans the same twelve trust boundaries any serious audit checks, they fail at wildly different rates, and the ones people worry about first, leaked keys, SQL injection, are rarely the ones that get you. I audited 26 real apps; the pillar ranking runs across the 21 third-party ones, denominators attached. Search “vibe coding security” and every result is written for someone else: enterprise application-security platforms, priced and worded for a security team with its own engineers and a queue to route findings into. None of them audits your specific app, or tells you what actually breaks first in something built by prompting instead of by a team with a security review built in.

What vibe coding security actually means

“Vibe coding” means building an app by prompting a tool like Lovable, Bolt, Replit, v0, or Base44, or directing an AI coding agent like Claude Code, Cursor, or Codex, instead of writing every line by hand. Security, for one of these apps, is narrower than it sounds. A protection can exist in the generated code and still fail the only test that matters: whether it holds once a real person tries to get past it. An AI generator is good at writing code that looks like a safeguard and inconsistent at writing the code that enforces one.

I audited 26 real apps built this way between June and July 2026 for the AxonBuild corpus, scored across twelve readiness pillars. The security-relevant slice of that data is the map this post walks through: which of the twelve actually breaks, how often, and what each looks like from a founder’s side of the screen. The full ledger sits in the vibe coded apps security statistics from all 26 audits, every denominator attached, including the four apps that came back with no confirmed critical. Larger scans point the same direction: Symbiotic Security scanned 1,072 vibe-coded apps built on Supabase backends in June 2026 and found 98 percent carried at least one flaw, more than nine in ten before a human verified anything.

Vibe coding security spans twelve trust boundaries that fail at very different rates: across 21 audited apps, the worst pillar averaged 31 out of 100, and the leaked-keys pillar everyone checks first averaged 84.

The vibe coding security risks, ranked

The vibe coding security risk ranking is nearly upside down from founder instinct: secrets, the pillar everyone hunts first, scored best of the twelve at 84.4 out of 100 across 21 audited apps, and the deepest damage sat in rows few founders think to name, reliability worst at 31.4. Three of the twelve pillars belong to other clusters (revenue, performance, and maintainability each get their own treatment elsewhere on this site); ranking the remaining nine, worst to best, across the 21 third-party apps in the corpus:

Four of the nine get real scanner coverage. The other five, reliability, deployment gates, authorization logic, AI-native abuse, and data integrity, are largely invisible to a tool built to match known patterns: each is a question about behavior over time, the kind no signature match can answer. The ranking doesn’t respect that split either: the worst pillar, reliability, sits outside scanner reach, while the second-worst, dependencies, is the one row a scanner fully owns and it still averaged 34.5.

The vendors ranking for this search also speak a different language than the one your app’s risk shows up in:

Who can get into what they shouldn’t

Authorization averaged 42.1 out of 100 across the corpus (14 apps scored). An AI generator gets this pillar wrong for a structural reason: the rule depends on facts the model was never given, namely who is asking and what they are allowed to touch. One food-delivery marketplace I audited kept each account’s type, customer, seller, or driver, in a single column on the user’s own row, and the update rule checked only that the person owned the row, never what value they wrote into it. One API call promoted a normal signup to seller or driver, and admin was a valid value in the same column, one step from a full takeover the day any admin feature shipped.

Authentication scores better, 53 across the corpus, and its failures tend to be quiet. A Q&A platform I audited had row-level security on every table, technically true, and one policy on the profiles table read USING (true). Any anonymous visitor could dump every registered user’s email address in a single request, using nothing more than the app’s own public key. A login test would have missed it entirely, because the login itself worked fine.

What is actually sitting in the open

One spam-classifier app I audited shipped its billing key to every visitor’s browser. View-source was enough to read it, no developer tools required, and it’s exactly the failure every founder pictures first when they hear “security.” It’s also the rare one: secrets is the best-scoring pillar in the corpus, 84 out of 100, because most vibe-coded apps really do keep their keys in environment variables. Six of the 21 third-party apps still exposed a real secret somewhere, three of them committed to git history, which keeps every key ever pushed no matter what gets deleted later.

Injection and abuse scores 62, the second-best pillar, because the classic patterns, SQL injection, cross-site scripting, are exactly what a generator’s training has seen the most and what a scanner is built to catch. Rate limiting is the exception here: 13 of 21 apps had none on their most expensive endpoint, so the first traffic spike, hostile or not, sets the bill.

What a stranger can make your AI feature do

AI-native risk applies only to the 14 audited apps with an AI feature, and it scores 38, near the bottom. Most of its failures come down to a missing limit: an endpoint with no check on how often it can be called. One incident-timeline tool I audited ran three separate endpoints against a paid GPT-4-class model with no login requirement on any of them, so anyone who found the URL could spend the owner’s provider budget indefinitely with nothing recording it. 12 of the 14 AI-featured apps had a confirmed version of that same gap, and 8 also had a path where user-supplied text could rewrite the model’s own instructions.

The engineering nobody counts as security

Reliability, dependencies, and deployment scored 31.4, 34.5, and 37.0, the worst three pillars in the corpus. Only the dependencies row intersects a vulnerability scan, and only halfway: the scan flags the CVE, and whether anyone ever runs the patch is what the pillar score measures. Reliability is whether a broken change gets caught before a customer hits it: at least 23 of the 26 audited apps had zero working automated tests. Dependencies is whether a known, patchable hole gets patched: 9 of 26 ran a framework version with a public, reachable RCE or auth-bypass flaw, most fixable with one version bump nobody ran. Deployment is whether anything stands between a push and production: at least 17 of 21 had no gate at all, and 17 of 21 recorded a failed request nowhere a human would see it.

Two of the three never appear in scanner output at all, and all three decide whether a real incident gets caught in an hour or found by a customer three weeks later, the gap “vibe coding security issues” actually means once you get past the leaked-key headline.

Why the usual security tools miss most of this

A platform scanner, or a generic AppSec tool pointed at this stack, is strong at exactly the pillars that scored well above: secrets, the classic injection patterns, an authentication flow’s existence. It has little to say about whether a caller owns the row they’re asking for, whether an AI endpoint has a spending cap, or whether last week’s deploy broke something nobody is watching. Why AI coding tools ship security holes by default covers why a generator produces this pattern in the first place: a scanner confirms a protection exists, and existence is a different claim from holding up once someone tries to get past it.

Closing that gap is the job of what a vibe coding security audit actually finds, where each candidate finding gets traced against the code before it counts.

A priority order if you have no security background

You don’t need to secure vibe coding output pillar by pillar in the order above; four checks catch the worst of it fastest, in the order the corpus says they matter:

1. 01 Create two accounts and try to read or edit the first one’s data from the second; if it works, that is your worst pillar showing up
2. 02 Grep the JavaScript your site actually serves for a live key or a service_role string; anything a browser downloads, a stranger already has
3. 03 Confirm every endpoint that calls an AI model rejects a logged-out request and carries a per-user limit
4. 04 Confirm a failed request lands somewhere a human will see it, and that a push can’t reach production with nothing checking it first

That order follows the corpus rather than a generic list: the first and last items sit on the two worst-scoring pillars, and the middle two are where failures are least common but most severe when they land.

The rest of the security series

This post is the map, and each piece of it has its own page underneath. What a vibe coding security audit checks, step by step is the method behind the numbers, the vibe coded apps security statistics in full is the ledger they came out of, and whether you need an AI app security audit is the decision once something real is on the line. Platform certification is a separate question from any of this, and what SOC 2 and GDPR actually cover for a Base44 app is the worked example. What eight of these apps looked like at the code level is the same corpus told app by app rather than as a rate. Two more are still being written: a step-by-step checklist for someone who can’t read the code, and a control-by-control guide to closing each hole. Until those are live, the four checks above are the compressed version. If revenue, performance, or maintainability is the more pressing question right now, whether your AI-built app is ready to launch covers what this post leaves out. The scorecard applies the same framework to your own answers rather than the corpus average, but it scores a different nine of the twelve pillars: it adds payments, speed, and handoff, and can’t measure dependencies, AI-feature risk, or injection from a questionnaire alone.

Common questions about vibe coding security

Is vibe coding a security risk?

Yes, and unevenly: across the corpus it concentrates in reliability, dependency hygiene, deployment gates, and AI-feature abuse, the four worst-scoring pillars, with authorization logic close behind. The leaked-key stereotype most people picture first, secrets, is actually the strongest-scoring pillar of the twelve.

What is vibe coding security?

Vibe coding security is whether the trust boundaries your AI tool generated actually hold under a real attempt to get past them; existing in the code is a separate, weaker claim. The nine-pillar ranking above is what that distinction looks like in practice, and it fails at very different rates depending on which pillar you ask about.

Which vibe coding security risk should I fix first?

Authorization: create two accounts and confirm one can’t read or edit the other’s data. It’s the pillar most likely to hide behind a working demo, because a demo only ever runs as one user.

Do platform scanners already cover this for me?

Partially. A scanner confirms a protection exists: a policy is attached, a check is present. Whether it holds when a real person tries to get past it takes two accounts and an actual attempt, something a scan alone can’t produce.