Vibe Coding Security Audit: Process, Evidence, and the Written Report

A vibe code audit, also called a vibe coding audit, a vibe audit or a vibe coding security audit, is a code-level review of an app built with tools like Lovable, Base44, Bolt, Replit, Cursor or Claude Code that tests whether its protections actually hold. Not whether a login screen exists, but whether a second customer can reach the first customer’s data, whether the server re-verifies a payment, and whether an unauthenticated caller can spend the owner’s AI budget. A dependency scan or a search for exposed keys can contribute evidence, but neither answers those questions alone.

Validated on 10 apps the engine had never seen, every reported finding survived human verification: zero false positives, recall 1.0 against human-verified ground truth. That is the number to demand from anyone whose report you are about to act on, me included.

AxonBuild’s fixed historical cohort provides a reproducible example of the candidate-to-verification distinction. The statistics page owns the selected cohort, denominators, score distribution, recurring-pattern counts, and limitations. This article owns the review process and the evidence a written report should preserve.

What is a vibe coding security audit?

In this article, a vibe coding security audit means a code-level review of an AI-built app that tests whether its protections hold across the workflows people actually use. It should distinguish a control that exists from one that is correctly connected, reachable findings from inactive package advisories, and a scanner candidate from a finding that survives verification.

A vibe coding security audit is a code-level review of an AI-built app that verifies which of its protections actually work, not just which ones exist, before real users, data, and money depend on it.

A vibe coded app audit is the same job under a different name. People reach for that phrasing when the app came out of a builder rather than a repository they wrote by hand, and the questions do not change: does a control exist, is it connected, and can a second person get past it?

The label does not define one universal service. Some providers sell automated scans, some perform penetration tests against a running target, and others review source code and business workflows. Before buying, check the named app, repository, environment, identities, and workflows; the evidence and access required; the exclusions; and what the written report contains. A security-focused query also differs from the broader question of whether an AI app needs an outside review, which that page owns.

What a review of a vibe-coded app checks, and what it leaves out

A security audit for vibe coded apps checks the boundaries a builder tends to generate loosely: identity, cross-account data access, payment confirmation, metered spend, and deletion. It leaves the running host, active exploitation, certification and the repair work to other services. That split matters more than the label on the service.

The 14 items below are the checked column in full, and the exclusions get their own section further down, with the reasoning for each one.

What a vibe code audit checks: the 14 items

Here is the whole list, in the order the review works through it. Each item names the vulnerability class first, then the shape it usually takes in an AI-built app.

1. Secret keys in the client bundle. A Supabase service_role key, a Stripe secret key, or a provider API key shipped inside browser JavaScript. Search the built output, not just the source folder.
2. Row level security enabled but permissive. RLS is on, so the dashboard reads green, while the policy itself resolves to true for any signed-in caller.
3. A missing ownership predicate on a record query (IDOR). The handler fetches by ID and never checks that the ID belongs to the caller. This is broken object level authorization, and it is the most common cross-tenant failure in AI-built apps.
4. Auth middleware that exists but is not attached. The file is there, the route list grew, and three routes never run it.
5. A backend that trusts a client-supplied user ID. The browser sends userId in the body or query string and the server uses it instead of the session.
6. A payment confirmed in the browser and never re-verified. Entitlement flips on the success redirect rather than on a provider event whose signature was verified against the raw request body.
7. An unmetered LLM endpoint. A route that calls a paid model with no auth check, no per-user quota, and no maximum token setting.
8. Missing rate limits on expensive endpoints. A rate-limit helper that is defined but not attached, or keyed to something the caller controls.
9. CORS open beyond the intended origins. A wildcard lets browser code from any origin read a non-credentialed response. A credentialed response must name an explicit origin, so the dangerous credentialed case is an untrusted origin that the server allows directly or reflects. Grade either configuration against whether the endpoint is meant to be public. MDN documents both browser rules.
10. SQL built by string concatenation. Classic SQL injection, usually in the one hand-written query that sits beside an otherwise parameterized ORM.
11. Storage rules and file paths that allow traversal. Uploads keyed by a predictable path, or a storage bucket rule that lets one account read another account’s files.
12. Broken authentication details. Plaintext password comparison, a weak or hardcoded JWT secret, tokens that expire in 30 days or never, and login errors that confirm which email addresses have accounts.
13. Dependency advisories checked for reachability, not counted. An npm audit total is a starting point. The question is whether the deployed app calls the affected code path, plus whether the lockfile pins what you think it pins and whether any package is typosquatted or abandoned.
14. Account deletion and data export that actually work. The button exists, but the rows survive in a related table, a storage bucket, or a third-party service.

AI cost controls

Item 7 is the check founders most often skip, because the endpoint works fine until someone finds it. A metered route needs four things together: an auth check, a per-user quota, a rate limit at the boundary, and a maximum token setting on the provider call. Any one alone leaves a path to an unbounded bill. The AI API cost guide owns the modeling side of that.

Account deletion and data export

Item 14 is a production-readiness check, not a legal opinion, and it fails in the same way almost every time: deletion removes the primary row and leaves copies in a join table, an uploads bucket, an analytics tool, or an email provider. Test it by deleting a real test account and then searching for it everywhere. The deletion-request guide and the data export guide own the process detail.

Run the free self-check first

Before you pay anyone, run this in Claude Code, Cursor, or Codex against your own repository. It costs nothing, it takes about ten minutes, and it settles the easy half of the list above.

Act as a security reviewer for this codebase. Do not change any code yet.

For each numbered item, answer PASS, FAIL, or CANNOT TELL, then give the
file and line you based the answer on. Do not guess.

1. Is any secret key reachable from browser-delivered code? Check the built
   output, not just the source folder.
2. For every table holding user data, is there a policy restricting rows to
   the owner, and is that policy anything other than "true"?
3. List every API route. For each, name the exact line that checks the
   caller's identity, or say there is none.
4. Does any handler read a user ID from the request body, query string, or
   header and trust it instead of the session?
5. Where is a payment or plan change confirmed? Is it confirmed on the
   server from the provider's own event, with the signature verified against
   the raw request body?
6. List every route that calls a paid API. For each, state the auth check,
   the rate limit, the per-user quota, and the max token setting.
7. Is CORS restricted to known origins, or set to a wildcard?
8. Is any SQL built by string concatenation with user input?
9. Can a file path or storage rule let one account read another account's
   files?
10. How are passwords compared, how is the JWT secret set, when do tokens
    expire, and do login errors reveal whether an email exists?

Finish with a list of everything you could not verify from the code alone.

That prompt gets you a long way. Three things it cannot settle:

• A second real identity. No prompt can sign in as another customer and try to read your rows. Cross-tenant access is proven with a second test account, not by reading policy files.
• Runtime reachability. The model reads source. It cannot tell you which routes actually run the middleware in the build you deployed, or whether the edge config in front of them changes the answer.
• The money and cost paths end to end. Whether a payment is re-verified server side, and whether a metered route holds under a caller who ignores the interface, is a behavioral test against a running app.

AI self-check versus a paid audit

The objection is fair: why not just ask the AI that wrote the app to review it?

Run the self-check first. Get outside eyes on the part a self-check structurally cannot reach.

What a vibe code audit costs and how long it takes

Prices are public across most of this market, so here are the bands.

Source ledger captured 17 August 2026. The addresses remain plain text because all three providers sell competing professional services. SecureVibing at audit.bllekholl.com published a $499 review. ThreatLoop at threatloop.app published $750 for 3 to 4 business days, $1,250 for 5 to 7 business days, and $2,500 for 7 to 10 business days. Afterbuild Labs at afterbuildlabs.com/services/security-audit published $499 with a stated 3-day turnaround.

The human-run row is a fixed sample of five published prices from SecureVibing, ThreatLoop, and Afterbuild Labs, checked on 17 August 2026. The listed prices were $499, $499, $750, $1,250, and $2,500. Providers change tiers often, so treat the range as a dated sample, not a market floor. Repair time is separate from review time in every case, and no honest provider quotes it before seeing the findings.

The audit process: what gets covered, traced, verified, and ranked

The review should expose how a result moved from a possible pattern to a decision:

Automation can inspect a large codebase consistently. Verification decides whether a candidate is true in this application, and the report should retain enough evidence for another person to challenge that decision.

What each priority band means in practice

A severity word is useless unless it converts into an action and a deadline:

Findings should arrive in two buckets, not one long list: pre-launch blockers and post-launch backlog. If the report cannot tell you which findings stop the launch, it has handed the prioritising back to you.

What evidence a verified finding should contain

Each reportable finding needs fields that make the conclusion inspectable:

Different findings require different proof. A secret key in a browser bundle may be confirmed with a build search. Cross-tenant access requires a second identity and an ownership test. An AI-cost path requires tracing authentication, rate limits, quotas, token caps, and provider-side limits together.

Why scanner output and verified findings diverge

The fixed cohort contains both sides of the scanner problem: groups of package advisories that became non-issues after source tracing, and published criticals whose affected path was reachable from the deployed application. The statistics owner carries the counts and denominators. The process lesson is that similar scanner output can lead to different decisions after version matching and reachability analysis.

An automated finding becomes useful when the report explains the mechanism, affected path, evidence, consequence, and the condition that would disprove it. A claim that survives that process may be described as verified. The underlying audit process still uses automation. This divergence is exactly what the 10-app validation in the intro measured: every reported finding held up under human checking, and none of them were advisory noise.

What the written report should contain

The report should make every stage of the review inspectable:

The output should separate confirmed findings, limited concerns, rejected candidates, and areas the review did not cover. It should state whether implementation, penetration testing, certification, or ongoing monitoring is included instead of leaving those assumptions inside the word “audit.”

To be plain about our own side: AxonBuild does not produce an audit report. The free 20-minute call checks whether a known blocker can be handled as one repair. If it can, we inspect the relevant code after agreeing to take the job, then show you the repair working before you pay.

What a code-level audit does not cover

Naming the exclusions is more useful than a broad promise. A code-level review does not cover:

• The live domain surface. DNS records, TLS configuration, exposed subdomains, open ports, and anything else reachable on the running host. Reading code does not look there, and this is the most common gap people point at when they argue code review is not enough. They are right about that specific gap.
• Active penetration testing. Attempting exploitation against a running target is a separate piece of work with its own authorization and rules.
• Compliance certification. A report is not a SOC 2 or ISO 27001 certificate, and no review can grant one.
• Remediation. Finding and fixing are different jobs, with the review checks, repair result, and prices agreed separately.
• Ongoing monitoring. A review is a snapshot of the code at one moment. The next deploy is not covered by it.

If your question is whether the stakes justify buying this work now, the AI app security audit decision guide owns that choice.

Common questions about vibe coding security audits

What should a vibe coding security audit report contain?

It should name the included app, repository, environment, identities, and workflows; list the exclusions; show the affected path and evidence for each confirmed finding; record how candidates were verified or rejected; explain consequence and priority; and distinguish review from implementation, penetration testing, certification, and monitoring.

How long does a vibe coding security audit take?

Published turnarounds run from 1 to 2 days at the fast end to 3 to 10 business days for a review whose app, repository, environment, identities, and workflows are agreed in advance, while formal penetration testing is usually scheduled weeks in advance. AxonBuild’s first repair is completed within three business days once access works. Larger repairs are quoted after the code has been reviewed and get their own delivery plan.

What access does an auditor need?

Read access to the repository, read access to the Supabase or Firebase project, the names of your environment variables rather than their values, a staging or preview URL, and a second test account so cross-account checks can actually be run. A review can start from the repository alone, but without a running environment and a second identity it cannot confirm that a control is reachable at runtime.

Can I audit my vibe coded app myself?

Yes, for a large part of it. Run a security review prompt against your own repository in Claude Code, Cursor, or Codex, search your built output for secret keys, and log in as a second test account to try to read the first account’s records. What a self-check cannot settle is whether a control is reachable in the deployed build, whether the model is grading code it wrote itself, and whether the payment and AI-cost paths re-verify on the server.

A copy-paste version of that prompt, with the ten questions to ask, is in the self-check section above.

Which AI coding tools and stacks does this cover?

Apps built with Lovable, Base44, Bolt, Replit, Cursor, Claude Code, v0, or Windsurf, on the stacks those tools generate: Next.js, React, Node, Supabase, Firebase, Postgres, Vercel, Netlify, and Stripe. The review reads code and configuration, so the builder that produced the app matters less than the boundaries in the deployed result.

Will you fix the issues you find?

Yes, and the fix is the part you pay for. A new client may pay $99 for one repair, available once for one agreed blocker in a working app. We complete it within three business days once access works, and you pay after seeing it work. Larger repairs are quoted after we review the code. Every confirmed finding names the mechanism, the affected path, and the priority, so you can also take it to your own developer or the AI tool that built the app.

Is a vibe code audit the same as a code review?

No. A code review judges quality, structure, and maintainability across a set of changes. A vibe code audit tests whether specific protections hold at named boundaries: identity, cross-account data access, payment confirmation, and metered spend. They overlap in the reading and answer different questions.

Do I need a vibe coding security audit before launch?

The decision depends on what the app controls and what you can already verify. The AI app security audit buyer guide owns the outside-review decision, while the launch-readiness owner page covers the broader launch verdict.

Can a security scanner replace an audit?

A scanner may be enough for a narrow question such as exposed secrets or known package advisories. It cannot establish a business-specific authorization rule merely by finding an auth file. In this historical cohort, three apps had 33 to 44 scanner advisories with zero traced as reachable, while other apps had cross-user access paths that required following identity and ownership across files.

How much does a vibe coding security audit cost?

Published prices vary: roughly $200 to $600 for self-serve tiered reviews, $499 to $2,500 across the five human-run fixed-price offerings sampled on 17 August 2026, and a quoted per-job price for formal penetration testing. AxonBuild has nothing in that list because it does not sell a standalone audit. Its only public service price is $99 for one repair, available once to a new client for one agreed blocker. Larger repairs are quoted after the code has been reviewed.

Is this kind of review a penetration test?

No. It reads one working AI-built app, its code, and the main business workflow. Active penetration testing is a separate piece of work and sits outside what a review covers. A review can identify security issues, but it does not certify that the app is secure or compliant.

A credible report should be able to say that a noisy area is clear. Otherwise the issue count is deciding the verdict before the code is opened.