7 Things a Code Audit Checks in a Vibe-Coded App

What Does a Real Code Audit Actually Check on a Vibe-Coded App?

A real code audit checks seven fixed categories: hardcoded secrets, access control, input validation, error handling, database integrity, dependencies, and session management, following the same structured methodology OWASP defines for any codebase. For most vibe-coded apps, this is the first time a human has actually read the code line by line.

The OWASP Code Review Guide frames code review as a structured methodology, not a five-minute skim: understand the architecture first, identify the critical areas, then work through a fixed set of control categories. That is the model a professional audit of a vibe-coded app follows too, whether the code came from a human, an AI, or both.

Joylo's own AI Confidence Score runs a security, scalability, reliability, integrations, and code quality check on every build and every plan, and it flags uncertain code automatically. A human code audit goes further: an engineer reads the flagged areas and the rest of the codebase by hand, checking for the seven categories below in the order they most commonly turn up broken.

Yes, this is usually the first thing an audit finds in a vibe-coded app: API keys, database passwords, or third-party tokens written directly into the source code, often visible in the client-side bundle anyone can open in browser dev tools. The OWASP Secure Code Review Cheat Sheet lists secrets and cryptography handling as a core review category.

The auditor greps the entire codebase, including client-side bundles and git history, for API keys, database credentials, and access tokens that were pasted directly into the code instead of stored in environment variables or a secrets manager. AI coding tools frequently generate working code this way because it is the fastest path to a demo that runs.

It ranks first because it is the fastest, cheapest fix to find and the most damaging to skip. A leaked key can be scraped and abused within hours of a repo going public, long before slower issues like a missing database index ever surface. Joylo's AI Confidence Score flags this pattern automatically before a build ships, though catching a leaked key already committed to history still needs a human to rotate it.

What it is: The auditor greps the entire codebase, including client-side bundles and git history, for API keys, database credentials, and access tokens that were pasted directly into the code instead of stored in environment variables or a secrets manager.

Why it ranks here: It ranks first because it is the fastest, cheapest fix to find and the most damaging to skip. A leaked key can be abused within hours of a repo going public, long before slower issues like a missing database index ever surface.

Best for: Any team shipping a vibe-coded app that connects to a real database, payment processor, or third-party API.

Implementation reality: Same-day for the scan itself. 1 engineer, a few hours to grep and rotate keys. Ongoing maintenance means adding secret-scanning to the CI pipeline.

Limitations: - A manual grep can miss secrets embedded in minified or obfuscated client bundles. - Rotating a leaked key does not undo any data already accessed with it. - Secrets pasted into a third-party AI tool's own logs are outside the audit's reach.

Choose this if: - The app has ever connected to a real payment processor or user database. - The repository has been public, shared with a contractor, or pasted into an AI tool at any point. - No environment variable file or secrets manager exists in the project.

No, an audit never assumes access control works because a button is hidden in the UI. It tests whether the backend rejects the request when someone without permission calls the endpoint directly. OWASP's Secure Code Review Cheat Sheet treats access control as a required category for this reason.

The auditor tries calling protected endpoints and API routes directly, bypassing the UI entirely, using a lower-privileged or unauthenticated account. If the request succeeds when it should have been rejected, that is a finding, regardless of what the interface shows.

It sits second because vibe-coded apps frequently build the visual permission layer, hiding an admin tab, without wiring the matching backend check, since the AI optimizes for what the demo shows on screen, not what a curious user could type into the URL bar. This is one of the checks included whenever an engineer runs Joylo's Expert Assist review on an existing app.

What it is: The auditor calls protected endpoints and API routes directly, bypassing the UI, using a lower-privileged or unauthenticated account, to confirm the backend rejects requests it should reject.

Why it ranks here: Vibe-coded apps frequently build the visual permission layer without wiring the matching backend check, since the AI optimizes for what the demo shows, not what a curious user could type into a URL bar.

Best for: Apps with more than one user role - admin vs. member, free vs. paid, owner vs. guest.

Implementation reality: 2-4 days to test every role and endpoint combination. 1 engineer plus test accounts for each role. Re-test any time a new role or endpoint is added.

Limitations: - Testing every role and endpoint combination by hand does not scale past a few dozen routes without automation. - Access control bugs inside third-party integrations sit outside what the audit can fix directly. - A passing test today does not guarantee the next AI-generated feature keeps the same checks.

Choose this if: - The app has 2 or more user roles with different permissions. - Any admin or internal feature was added without a matching backend permission check. - No one has tested what happens when a non-admin account calls an admin route directly.

Yes, and an audit checks it at every entry point, not just the obvious login form, since any field, URL parameter, or file upload the app accepts is a potential injection path. Input validation and output encoding are named, required categories in the OWASP Secure Code Review Cheat Sheet.

The auditor traces every input field through the app to see whether it is validated on the server, not just the browser, and whether output is properly encoded before it is rendered or stored, which is what prevents injection attacks and stored malicious scripts.

It follows access control because both are about trust boundaries: access control decides who can call an endpoint, input validation decides whether what they send can be trusted once they are already allowed in.

What it is: The auditor traces every input field to confirm it is validated server-side and that output is encoded before it is rendered or stored, preventing injection and stored script attacks.

Why it ranks here: Access control decides who can call an endpoint; input validation decides whether what they send once inside can be trusted, which is why it follows access control directly.

Best for: Apps that accept any user input - forms, search bars, file uploads, API payloads.

Implementation reality: 3-5 days depending on the number of input surfaces. 1 engineer working through each form, endpoint, and upload path. Re-check any new input field added after launch.

Limitations: - Client-side validation alone gives a false sense of security since it is trivial to bypass. - File upload checks need to validate content, not just the file extension. - Third-party form widgets and embeds sit outside the audit's direct control.

Choose this if: - The app accepts free-text input anywhere - search, comments, profile fields, chat. - Users can upload files of any kind. - The app renders user-submitted content back to other users.

No, most vibe-coded apps handle errors by showing a generic crash screen or, worse, a raw stack trace that reveals internal file paths and database structure to anyone who trips it. A professional audit checks that errors are caught, logged internally, and never exposed to the end user.

The auditor forces errors deliberately, bad input, a dropped connection, a timed-out API call, to see what the app shows the user, what it writes to a log, and whether repeated failed requests get throttled by a rate limiter instead of hammering the backend.

It ranks fourth because these gaps rarely break a demo. They show up once a stranger, not the founder, is the one triggering the error, which is exactly the moment a vibe-coded app usually has not been tested yet. Joylo's Co-Build plans include an engineer setting up this kind of production error handling and monitoring as part of the included architect hours.

What it is: The auditor forces errors deliberately to see what the app shows the user, what it writes to a log, and whether repeated failed requests get throttled instead of hammering the backend.

Why it ranks here: These gaps rarely break a demo. They surface once a stranger, not the founder, triggers the error, which is exactly the moment a vibe-coded app has usually never been tested.

Best for: Apps heading toward real users where uptime and debugging speed both matter.

Implementation reality: 1-2 weeks to add structured logging and rate limiting where missing. 1 engineer, more if logging needs to be added across the whole app. Review logs weekly once live.

Limitations: - Adding logging after the fact means early errors before launch were never captured. - Rate limiting configured too aggressively can lock out legitimate users during traffic spikes. - A raw stack trace already indexed by a search engine cannot be fully un-exposed.

Choose this if: - Error messages currently show a stack trace, file path, or database detail to the user. - There is no central log of what errors happen in production. - No endpoint has a rate limit, so a single user could call it thousands of times a minute.

No, a database that runs fine in a demo with 10 test records is not the same as one holding up under 10,000 real rows and concurrent users. An audit checks for N+1 queries, missing indexes, and unclear data relationships before that gap shows up as a slow app. NIST's SSDF calls for catching this before release.

The auditor reviews the schema and query patterns for N+1 queries, one query per row instead of one query for all rows, missing indexes on frequently searched columns, and any place data integrity depends on the app remembering to do something instead of the database enforcing it.

It follows the request-handling checks because a database problem is invisible until volume arrives. A vibe-coded demo with a handful of test rows never surfaces a missing index the way 10,000 real rows immediately will. A database schema review like this is one of the deliverables included on Joylo's Co-Build plans.

What it is: The auditor reviews the schema and query patterns for N+1 queries, missing indexes on frequently searched columns, and places where data integrity depends on the app remembering to enforce it instead of the database.

Why it ranks here: A database problem stays invisible until volume arrives. A demo running on a handful of test rows never surfaces a missing index the way 10,000 real rows immediately will.

Best for: Apps expecting real growth - a launch, a marketing push, or paying customers.

Implementation reality: 1-2 weeks for a schema and query review on a mid-size app. 1 engineer with database access and query logs. Re-review the schema after any major new feature.

Limitations: - Query performance issues are often invisible until the dataset is large enough to expose them. - Fixing a missing index on a live table can require a maintenance window. - Schema changes made after audit findings need their own follow-up review.

Choose this if: - The app currently runs on test or seed data rather than a realistic data volume. - Pages that list or search records have started loading noticeably slower. - No one has checked which database columns are indexed.

No, an AI coding tool pulls in whatever package solves the immediate problem without checking its version, maintenance status, or known vulnerabilities, so an audit runs a dependency scan against every package the app installed. NIST SP 800-218 recommends combining this kind of automated scan with manual review rather than relying on either alone.

The auditor runs an automated vulnerability scan against every dependency in the project, then manually checks the results that matter: is the package actively maintained, does the vulnerable code path actually get used, and is there a safe upgrade available.

It comes second to last because dependency risk is usually inherited, not written by the AI directly, which makes it easy to overlook when everyone is focused on the app's own code. Auditing AI-generated code applies the same static analysis, dynamic testing, and manual review controls used for any codebase, the AI origin changes where findings concentrate, not the methodology itself.

What it is: The auditor runs an automated vulnerability scan against every dependency, then manually checks whether the package is actively maintained, whether the vulnerable code path is actually used, and whether a safe upgrade exists.

Why it ranks here: Dependency risk is usually inherited, not written by the AI directly, which makes it easy to overlook when everyone is focused on reviewing the app's own code.

Best for: Any app built by prompting an AI tool that auto-installed its own package list.

Implementation reality: 1-3 days for the scan and triage. 1 engineer to run the scan and review flagged packages. Automated scanning on every deploy going forward.

Limitations: - A scan flags known vulnerabilities, not unknown ones, so it is a floor, not a guarantee. - Upgrading a flagged package can break other functionality that depended on the old version. - Some vulnerable packages have no patched version yet, only a workaround.

Choose this if: - No one has run a dependency vulnerability scan since the app was first built. - The package list was never reviewed by a human, only auto-installed by the AI tool. - The app has not upgraded its dependencies in the last few months.

No, this is usually the last category checked because it requires understanding the whole app first, but a weak session, a token that never expires, a password stored in plain text, can undo every other fix. CSA research on AI-generated code ties this pattern, alongside secrets and access control, to concentrated vulnerability debt in AI-built apps.

The auditor checks how sessions are created, how long tokens last before they expire, whether passwords are hashed instead of stored in plain text, and whether logging out actually invalidates the session instead of just clearing it from the browser.

It closes the list because it is the category most likely to combine with an earlier finding. A hardcoded secret plus weak session handling is a worse combination than either problem alone, which is why an auditor checks it last, with full context of everything else found. Session and credential handling is exactly the kind of finding Joylo's engineers close out during a rescue engagement.

What it is: The auditor checks how sessions are created, how long tokens last, whether passwords are hashed instead of stored in plain text, and whether logging out actually invalidates the session server-side.

Why it ranks here: It is the category most likely to combine with an earlier finding, a hardcoded secret plus weak session handling is worse than either problem alone, so it is checked last with full context.

Best for: Apps with user logins, especially anything handling payments or personal data.

Implementation reality: 3-5 days to review and harden session and credential handling. 1 engineer, more if authentication is rebuilt rather than patched. Review after any change to login or password logic.

Limitations: - Migrating existing users to a stronger session or hashing scheme can require forcing a password reset. - Third-party login providers move some of this risk outside the app's own code. - A fixed session bug does not retroactively invalidate tokens issued before the fix.

Choose this if: - Passwords are stored anywhere in plain text, including in logs or test data. - Session tokens do not have an expiration. - No one has confirmed that logging out actually invalidates the session server-side.

What Happens After the Audit Finds Something?

Findings get triaged and logged in an issue tracker, then fixed in priority order, starting with anything touching secrets, access control, or live user data. NIST's Secure Software Development Framework treats this triage step as part of the practice, not an optional follow-up, so a real audit always ends with a written list, not just a conversation.

In the production hardening passes run on rescued apps, the same handful of findings surface almost every time: a secret in the client bundle, an admin route with no server-side check, and a database with no index on the field everyone searches by. None of these are exotic. They are what happens when speed, not survival, was the only thing being optimized for.

Joylo's Expert Assist connects a named in-house engineer, already working inside HST Solutions, an 18-year Dublin engineering firm, within 24 hours to run this exact audit and fix what it finds, for a fixed $500 for 10 architect hours. Expert Assist is a strong fit for a team that just got audit findings and needs them fixed, not just listed - it connects a named engineer within 24 hours, runs on a fixed price, and hands back a deployment-ready app with the code owned by the customer. Teams that need this review built into every release, not just once, typically move to a Co-Build plan, where the same kind of engineer hours are included every month instead of purchased on demand.

A written finding does not fix itself. What separates a real audit from a checklist a founder reads and forgets is whether every item gets tracked to closed, the same discipline NIST's framework expects from any team shipping production software, AI-assisted or not.

If your vibe-coded app needs this audit run by a real engineer, Expert Assist connects one within 24 hours. See Expert Assist