Vibe Code Audit Checklist: What We Check First

Short answer: when we audit an app built with an AI coding tool, we check eleven areas in a fixed order: secrets and config, auth and permissions, data access rules, payments and webhooks, input validation, dependencies, architecture and data model, error handling and logging, tests, CI/CD and environments, and backups and observability. The first four areas are where live users, money and data are most exposed, so they come first. This list is tool-neutral and works for any app, whoever or whatever wrote the code.

How do I use this checklist?

Go through the areas in order. For each item, answer one of three ways: yes, verified, no, or do not know. Do not tick an item because it "should" be true. Tick it because you or someone on your team looked.

If you find problems in areas 1 to 4, deal with those before adding features. If you want help, Vibe Code Rescue covers audit, hardening and takeover.

1. Are my secrets and configuration safe?

• No API keys, passwords or tokens are committed in the repository, including history.
• No secret is shipped in front-end code. Anything in the browser bundle is public.
• Every key that was ever pasted into a chat, prompt or screenshot has been rotated.
• Secrets live in environment variables or a secrets manager, per environment.
• Production and development use different keys, databases and payment accounts.
• A .env.example lists required variables without values.

2. Is login and permission logic correct?

• Authentication uses a proven library or provider, not hand-written password handling.
• Passwords are hashed by the provider or a modern algorithm, never stored or logged in plain text.
• Email verification and password reset work, and reset links expire.
• Authorisation is checked on the server for every request, not only by hiding buttons in the interface.
• A normal user cannot read or change another user's records by changing an ID in the URL or request.
• Admin functions are separated and need an admin role checked on the server.
• Sessions and tokens expire, and logout actually invalidates them.
• Rate limiting exists on login, sign-up and reset endpoints.

3. Do the data access rules actually enforce who sees what?

This applies whether you use database row-level security, a backend layer, or both.

• Every table with user data has an access rule. "No rule" must mean "no access", not "open".
• Rules are tested with two different users, not only with the owner account.
• Read, insert, update and delete are covered separately.
• The public (anonymous) role can access only what is meant to be public.
• Service or admin keys are used only on the server.
• File storage buckets are private unless a file is meant to be public, and URLs to private files expire.
• Multi-tenant data carries a tenant or owner ID that every query filters on.

4. Are payments and webhooks reliable?

• Payment status comes from the provider's confirmed event, not from the success page the user lands on.
• Webhook requests are signature-verified.
• Webhook handlers are idempotent: receiving the same event twice does not grant access twice, create two orders or send two emails.
• Webhook handling tolerates out-of-order and delayed events.
• Failed, refunded, disputed and cancelled states are handled, not only success.
• Subscriptions: renewal, failed renewal, cancellation and plan change all update access correctly.
• Prices and amounts are decided on the server, never taken from the client.
• Money is stored as integer minor units, with the currency, never as floating-point numbers.
• You can reconcile your database against the provider dashboard and find no mismatches.

We have seen this area cause the most damage. On Karbon Shortcuts the main problems we found were a wrong architecture and a broken, unstable Stripe integration. See the case.

5. Is input validated and output escaped?

• Every API endpoint validates type, length, format and allowed values on the server.
• Database queries are parameterised, with no string concatenation of user input.
• User-supplied content is escaped or sanitised before it is rendered as HTML.
• File uploads check type, size and content, and are stored outside the code path.
• Expensive operations (search, export, AI calls) have size and rate limits.
• Error messages do not reveal internals such as stack traces or query text.

6. Are my dependencies under control?

• A lockfile is committed and installs are reproducible.
• A dependency audit command has been run, and critical findings reviewed.
• Unused packages are removed. Generated code often adds more than it uses.
• You can name why each major package is there.

7. Is the architecture and data model sound?

• There is a clear separation between the interface, business logic and data access.
• Business rules live in one place, not copied across components.
• Each fact is stored once. If you see the same value in several places, ask which one is true.
• Tables have primary keys, foreign keys and constraints that the database enforces.
• Schema changes are made through versioned migrations, not by hand on production.
• Long or heavy work runs in background jobs, not inside a web request.
• You can draw the system on one page: what runs where and what talks to what.

8. Do errors get handled and logged?

• Failures show the user a clear message and do not leave half-saved data.
• Multi-step operations use transactions or are safe to retry.
• Calls to external services have timeouts and sensible retries.
• Errors are logged with enough context (what, who, when, request ID) to reproduce.
• Logs never contain passwords, tokens or full card data.
• Unhandled errors reach an error tracker or alert, not only a console.

9. Are there tests that protect the important paths?

• There is at least one automated test for sign-up and login.
• Payment and access-granting logic has tests, including repeated webhook events.
• Permission rules have tests proving that user A cannot read user B's data.
• Tests run with one command, locally and in CI.
• A failing test blocks merging.

10. Are CI/CD and environments set up safely?

• There is a separate staging environment with its own data and keys.
• Deploys are automated and repeatable, not manual file copying.
• CI runs lint, type checks and tests on every change.
• You can roll back to the previous version quickly.
• Production database changes run through migrations with a backup taken first.
• The main branch is protected, and changes go through review.
• Preview or generated environments do not point at the production database.

11. Do I have backups and observability?

• Automated database backups exist, and you know the retention period.
• You have restored a backup into a clean environment and checked the data.
• File storage is backed up or versioned.
• You know your recovery target: how much data you can lose and how long you can be down.
• Uptime monitoring checks the app from outside and alerts a human.
• Spend alerts exist on hosting, AI APIs, email and SMS.
• Someone knows the first three steps to take during an outage.

How do I read the results?

Count your no and do not know answers per area.

• Any "no" in areas 1 to 4 is urgent. Fix those before adding features.
• Many "do not know" answers mean you lack visibility. That alone is worth a short audit.
• Gaps in areas 5 to 8 are usually a hardening project of days or weeks, depending on size.
• Gaps in areas 9 to 11 decide whether every future change is safe or a gamble.

If you want a second opinion, we start with a free 30-minute intro call, and the price after it depends on what is needed. Book it on the Vibe Code Rescue page. For a worked example of the pattern, see how we took a Lovable design to a deployed product on ThePokeLlama. Our guide to the first 48 hours after something breaks is here, and the factors behind cost are explained in How much does it cost to fix a vibe-coded app?.