Vibe-Coded App Security: What 24 Audits Found (2026)

Short answer: AI-built apps fail in the same few places, and they fail there most of the time. In the last twelve months we delivered 35+ code security audits; 24 of the codebases were written mostly by Cursor, Lovable, Bolt, Replit, v0, Copilot or ChatGPT. Across those audits we found missing or broken authorization in 18, database rules open to every logged-in user in 16, no rate limiting on login or payment endpoints in 19, and no automated tests at all in 23. The average audit turned up 0.7 Critical and 2.8 High findings, and fixing them took 12–30 engineering hours. Four codebases could not be fixed and were rebuilt. None of this is exotic. It is the same three mistakes, made by a tool that does not know it is making them.

Where these numbers come from

This is not a lab study. Our engineers compiled the counts below from the audit reports we delivered between September 2025 and September 2026. A finding is counted once per audit if it appeared at least once, so "18 audits" means eighteen separate products, not eighteen bugs. Counts are what the team tallied from the reports; treat them as a track record, not a controlled sample.

What was in scope:

• 35+ audits, of which 24 were mostly AI-generated — the founder or team had used an AI builder or coding assistant for the bulk of the code.
• Codebase size: 15,000–80,000 lines, 100–600 files, one to four repositories.
• Stacks: Next.js and React on the front, Node.js/Express, Python/FastAPI and Laravel/PHP on the back, with Supabase/PostgreSQL, Firebase and MongoDB underneath. This is the standard AI-builder stack in 2026, which is part of why the failures repeat.
• How we test: the same way an attacker would. Every route gets called without a session, with the wrong user's session, and with tampered IDs and prices. Secrets are searched for in code, config, git history and the shipped client bundle. Dependencies are checked against known CVEs and for packages that do not exist. Then a senior engineer reads the authorization and payment paths by hand.

Public research points the same way. Veracode's 2026 GenAI Code Security Report puts the security pass rate of AI-generated code at 56 percent, unchanged from the year before, across more than 100 models. Apiiro's analysis of Fortune 50 repositories found AI-assisted developers shipped three to four times more code and ten times more security findings, with a 322 percent rise in privilege-escalation paths. A Stanford user study found that developers with an AI assistant wrote less secure code and were more confident it was secure. Our numbers are what that looks like on one product at a time.

The findings, ranked by how often they showed up

Finding	Audits with at least one	Share of 35	Typical severity
No automated tests at all	23	66%	Medium (it is why everything else survives)
Vulnerable or abandoned dependencies	21	60%	High
No rate limiting on login, signup, reset or paid endpoints	19	54%	High
Broken or missing authorization (IDOR, no role checks)	18	51%	Critical
Database rules too open (Supabase RLS off, public Firebase rules)	16	46%	Critical
Sensitive data logged in plain text	12	34%	High
Secrets or API keys exposed in code, config or client bundle	11	31%	Critical
XSS / unsafe HTML rendering	10	29%	High
Payment or billing bypass (unverified webhooks, client-side prices)	9	26%	Critical
SQL / NoSQL injection	6	17%	Critical

Recurring in more than two audits but below the table: insecure file uploads, over-broad API permissions, missing server-side validation, permissive CORS, weak session and token handling, and debug endpoints left enabled in production.

Two things stand out. First, the Critical rows — authorization, database rules, secrets, payments, injection — are all design failures, not typos. The code does what it was asked to do; nobody asked for the check. Second, the top two rows (no tests, stale dependencies) are not vulnerabilities themselves. They are the reason the vulnerabilities are still there six months later.

Three mistakes explain most of the table

Authorization lives in the wrong layer

Eighteen audits had a route that returned or modified another user's data. Sixteen had database rules that let any authenticated user query any row. These overlap heavily, and they have one cause: the AI put the access check in the UI. The dashboard only shows your records, so it looks correct in a demo. The API behind it, and the database behind that, will hand over anyone's records to anyone who asks with a valid session and a different ID.

This is the pattern behind CVE-2025-48757, where researchers found 170+ production Lovable apps whose Supabase tables had row-level security disabled, exposing emails, payment records and stored API keys to anyone holding the public anon key. Supabase ships with RLS off on new tables; the builders generated schemas without turning it on. In our audits the RLS-off and Firebase-rules-open variants were the single most common Critical finding.

How to check tonight: log in as user A, copy any request that fetches your own record, change the ID to a value you do not own, replay it. If you get data back, you have this bug. For Supabase, open the dashboard: any table without the RLS shield icon is readable with the anon key from your JavaScript bundle.

The server trusts the client

Nine audits had a payment or billing path where the price, quantity, discount or plan came from the browser. Change the number in the request and the server charges that number. The related failure is a payment-provider webhook that upgrades an account without verifying its signature, so anyone who can find the endpoint can grant themselves a paid plan. The same habit shows up as missing server-side validation, over-broad API permissions and file uploads that accept anything.

The tool is not being careless; it is being literal. "Add a checkout button that charges the cart total" produces exactly that, with the total computed where the cart lives. Nothing in the prompt said the total must be recomputed from the database.

How to check tonight: open the network tab, find the request that creates the order or subscription, and look at the body. If a price, amount, plan name or role is in it, the server has to be recalculating it from scratch. If you cannot prove it does, assume it does not.

Nothing catches a regression

Twenty-three of 35 codebases had no tests. Twenty-one had dependencies with known CVEs or packages that had not been updated in years. Twelve logged tokens, passwords or personal data to plain-text logs. These are the boring findings, and they are why the exciting ones persist: a product with no tests cannot be refactored safely, so the founder stops touching the scary parts, so the scary parts stay.

Dependencies deserve a separate note. Beyond the usual outdated packages, AI tools sometimes import packages that do not exist — a hallucinated name that resolves to nothing, or worse, to a package someone registered to catch exactly that mistake. We check every import against the registry for this reason.

How to check tonight: run npm audit or pip-audit. Then grep your logs for token, password, Authorization and email addresses. Then look for a tests folder. Most AI-built repos have a folder and no tests inside it.

Severity and what it costs to fix

Across the 35+ audits:

• Average Critical findings per audit: 0.7. A Critical is something an outside party could use to read or change data they should not, or to take money. About two in three audits had at least one.
• Average High findings per audit: 2.8. Highs are exploitable but need a precondition — a logged-in account, a specific role, a leaked ID.
• Fix effort for the Critical and High items: 12–30 engineering hours. That range covers most audits. It does not include the rebuilds.
• Rebuilt instead of fixed: 4 of 35. In each case the architecture put business logic and access control on the client so thoroughly that patching it meant rewriting the backend anyway.

The worst single finding of the year was unremarkable in every way except impact: a production application let any authenticated user read and modify any other customer's records by changing an object ID in the request.

The 12–30 hour range is worth pausing on. That is two to four days of a senior engineer. A product that took a founder six weeks to build with an AI tool usually needs less than a week to make defensible. The expensive outcome is not the audit; it is finding out from a customer.

Three cases, anonymised

The SaaS that only looked authorized. A B2B product generated largely with an AI builder, functional in every demo. Authorization was enforced in the frontend: the UI hid other accounts' data, the API did not. Any user could edit a request and read or change records belonging to other companies. We moved every access check to the server, rewrote the database policies around ownership, and added tests that try each route as the wrong user. A Critical closed in under a week.

The marketplace that let buyers set the price. Pricing and payment values came from the client. A buyer could change the amount in the request and pay whatever they typed. We redesigned the payment flow so the server computes and verifies every amount from its own records, and the payment provider's webhook signatures are validated independently before anything changes account state.

The Firebase app with open rules. A production app whose database rules allowed any signed-in user to query data meant for one user. We rewrote the rules around explicit ownership and roles, then wrote a permissions test suite that runs the rules against every collection as an outsider, an ordinary user and an admin, so the next schema change cannot quietly reopen it.

The 30-minute self-check

If your app was built mostly with AI, do these before you do anything else. Each takes a few minutes and needs no security background.

Swap an ID. Log in, fetch your own record, change the ID, replay. Repeat for two more object types.

Look at the checkout request. Any price, plan, quantity or role in the request body is a red flag.

Open your database dashboard. Supabase: every table needs RLS enabled and a policy. Firebase: rules that contain allow read, write: if request.auth != null are open to every user.

Search the client bundle for keys. View source, search for sk_, service_role, AKIA, AIza. Anything that is not the public anon key should not be there.

Try logging in wrong ten times fast. If nothing slows you down, there is no rate limit on the most attacked endpoint you have.

Run npm audit (or the equivalent). Count the Critical and High lines.

Read your logs for one hour of traffic. Tokens, passwords, or full request bodies with personal data mean you are storing what you promised not to.

Find the tests. If there are none, every fix from here on is a guess.

If you pass all eight, you are in better shape than most of the 35. If you fail three or more, stop adding features until they are fixed.

When to fix, when to rebuild, when to get an audit

Fix it yourself if you failed one or two checks, you understand the code, and the failures are in one place. Authorization and RLS fixes are well documented for every stack in the table.

Get an audit if you are about to take on paying customers, raise a round, sign an enterprise deal, or hand the code to a new team. Every one of those triggers someone asking "has this been reviewed?", and "yes, here is the report" is a very different answer from "we used a good AI tool". Our AI code security audit is fixed-price and takes five business days: the checks above done properly across every route, plus secrets, injection, dependencies, API abuse paths and AI-specific risks like prompt injection, ending in a severity-ranked report and a fix roadmap in plain language. It covers exactly the stacks in this article.

Plan a rebuild if business logic and access control are in the client across the whole app, there are no tests, and the original builder is gone. Four of 35 landed here. The tell is that every fix you attempt breaks something else, because nothing was ever designed to be changed.

Taking over a codebase you did not write

Fourteen of the year's engagements were takeovers: a founder's AI-built product, or a previous developer's, that needed a team to own it. The time from handover to "we can ship safely" was two to six weeks, almost all of it spent on the same list — put authorization on the server, fix the database design, move business logic out of the client, add error handling, write the tests that should have existed, and document what the code actually does.

The reasons the previous build failed, in the order we hear them: AI-generated architecture that nobody reviewed for security, missing backend authorization, inconsistent database design, business logic on the client, poor error handling, undocumented code, dependency problems, and no tests. That list is also the order we fix things in. It is the same list as this article, which is the point: the failure modes are predictable, so the recovery is too. Our maintenance and support retainers exist for exactly this handover.

What the data does not say

It does not say AI tools write worse code than people. Twenty-three of the 35 audits had no tests; plenty of human-written startups do not either. The Stanford study's most useful finding was not that AI-assisted code was less secure but that its authors were more confident. The tool removes the moment of doubt where a developer would normally ask "wait, who is allowed to call this?" That question is the whole job. Put it back — in a review, in a test, in an audit — and AI-built products are as defensible as any other.

We have more on what the public datasets show in the state of AI-generated code security in 2026 and what to audit first when your team uses AI coding tools.

---

Built it with AI and about to put real users on it? Run the eight checks above. If you want a second pair of eyes, our AI code security audit is fixed-price, five business days, and ends with a report you can hand to a customer or an investor. If the honest answer is "you are fine, ship it", we will say so.

Sources: Veracode, 2026 GenAI Code Security Report; Apiiro, 4x Velocity, 10x Vulnerabilities (via The Register); Perry, Srivastava, Kumar and Boneh, Do Users Write More Insecure Code with AI Assistants? (ACM CCS 2023); CVE-2025-48757 postmortem. Entalogics figures compiled by our engineering team from audit reports delivered September 2025 – September 2026; client details withheld.