Skip to content
vibecodershq.
Submit a tool

14 Oct 2026

The production checklist for a vibe-coded app

A vibe coding security checklist: secrets, auth, database rules, inputs, dependencies, logging, tests, backups and rollback, plus prompts for your agent.

This vibe coding security checklist is for the moment just before real users arrive. Your app works in the demo. The question now is whether it's safe and recoverable when something goes wrong. Below are nine steps. Each has tool-specific checks and a prompt you can paste into Claude Code, Codex or Cursor. The agent does the digging, and you check what it reports. In our view, it's best to work through them in order and commit after each step.

A general rule before you start: ask the agent for a report first and fixes second. Then review every diff yourself.

1. Secrets and environment variables

  • Keep keys out of the repo and out of client code. OWASP recommends storing secrets centrally, rotating them, and never hardcoding them (OWASP Secrets Management).
  • Next.js: any variable prefixed NEXT_PUBLIC_ is inlined into the browser bundle (Next.js env vars). A secret with that prefix is public. Vite's VITE_ prefix works the same way (Vite env).
  • Turn on secret scanning for your repo (GitHub secret scanning). Assume any key that was ever committed is leaked, and rotate it.

Prompt: "List every secret, API key or token in this repo and its git history. For each one, say whether it can reach client code (check NEXT_PUBLIC_/VITE_ prefixes and imports). Don't change anything yet."

2. Auth and access rules

  • Check permissions on the server for every request. Hiding a button is not access control. OWASP recommends denying by default and checking permission on every request (OWASP Authorization).
  • Run the cross-user test: log in as user A and request user B's record by changing its ID. It should fail.
  • Supabase: the docs say to "enable RLS on every table in an exposed schema" and write a policy for each operation (Supabase RLS). Never ship the service role key to the client (same source).

Prompt: "For every API route and server action, show how it checks who the user is and whether they own the resource. Flag any route that trusts an ID from the client without checking ownership. List any Supabase tables without RLS."

3. Input validation

  • Validate every input on the server against an allowlist of expected types, lengths and formats (OWASP Input Validation). Client-side checks are for user experience, not security (same source).
  • Injection is still in the OWASP Top 10. Use parameterized queries or your ORM, and never build SQL from strings.
  • Stripe: verify webhook signatures before you trust a payment event (Stripe webhooks).

Prompt: "Find every place user input enters the server (forms, query params, uploads, webhooks). For each one, show the validation or note that there's none. Propose a schema (for example zod) for the unvalidated ones."

4. Dependency audit

  • Run npm audit to report known vulnerabilities in your dependency tree (npm audit docs).
  • Delete packages the agent added but no longer uses. In our view, fewer dependencies means less to patch.
  • Check that every package actually exists and is the one you meant to install. Agents sometimes suggest names that look right but aren't.

Prompt: "Run npm audit and list high and critical findings with the fix for each. Then list dependencies in package.json that are never imported."

5. Error handling and logging

  • Show users a generic error and keep stack traces in your logs. Leaking error details helps attackers (OWASP Error Handling).
  • Log security events such as logins, failed logins and access denials. Don't log passwords, tokens or session IDs (OWASP Logging).

Prompt: "Find places where raw errors or stack traces reach the client, and places where we log secrets or personal data. Propose a single error handler."

6. Tests on critical paths

  • You don't need full coverage. Write tests for the paths that would hurt if they broke: sign-up, login, payment, and anything that deletes data. Add the cross-user test from step 2.
  • Claude Code's docs give "write tests for the auth module, run them, and fix any failures" as an example task (Claude Code overview).

Prompt: "Write tests for signup, login, checkout and delete-account, including one that proves user A can't read user B's data. Run them and report failures. Don't change app code to make a test pass without asking me."

7. Performance basics

  • Measure before you tune. Core Web Vitals (LCP, INP, CLS) are a reasonable set of user-facing targets (web.dev Web Vitals).
  • Look for N+1 queries, missing database indexes on columns you filter by, and unbounded list endpoints. Add pagination.

Prompt: "Find database queries inside loops, list endpoints without pagination, and filtered columns without an index. Rank them by likely impact."

8. Backups

  • Know what your host backs up, how often, and how you restore. Supabase documents its backup options and how they differ by plan (Supabase backups).
  • Do one test restore into a scratch project. In our view, a backup you haven't restored is an assumption, not a backup.

9. Rollback plan

  • Write down how you undo a bad deploy before you need to. Vercel lets you instantly roll back to an earlier production deployment (Vercel Instant Rollback).
  • Database migrations don't roll back with the deploy. Keep migrations reversible, or ship them separately.
  • Keep a short runbook: who to call, how to roll back, and how to rotate keys.

Prompt: "Write ROLLBACK.md for this app: how to roll back the frontend deploy, how to reverse the last three migrations, and how to rotate each secret from step 1."

When to hire a human reviewer

If you take payments, store health or financial data, or have users beyond friends and family, a human security review is worth paying for, in our view. OWASP's ASVS gives a reviewer a shared standard to check your app against.

Sources