Pre-launch security checklist for vibe-coded apps

Vibe-coded apps ship fast, and the gaps are rarely in the clever parts. They are in the boring defaults the agent never asked about: who can read this row, where is this key stored, what happens if someone sends nonsense. This checklist is the pass to do before real users arrive. It takes an afternoon, and it is far cheaper than an incident.

Be honest about scope. This is a practical pre-launch review, not a penetration test. If you handle payments, health data or children's data, get a professional review.

1. Secrets

• Search the repo and its git history for API keys, tokens and passwords. If one was ever committed, rotate it. Deleting the line is not enough.
• Confirm .env files are in .gitignore and an .env.example with fake values exists.
• Check that no server-only key is exposed to the browser. In Next.js, anything prefixed NEXT_PUBLIC_ is public; in Vite, anything prefixed VITE_ is.
• Use separate keys for development and production.

2. Authentication

• Use a proven auth provider or library. Do not let an agent invent its own password hashing or session scheme.
• Check every protected page and every protected API route. Hiding a button is not access control.
• Add rate limits to login, signup and password reset.
• Make sure password reset and email-change flows require proof of ownership.

3. Authorisation and your database

• For every query, ask: does it check the signed-in user owns this record? Test by changing an ID in the URL or request.
• If you use Supabase or Postgres row-level security, turn it on for every table and write a policy for each. A table with RLS off and a public key is an open table. There is a step-by-step version in our Supabase RLS checklist.
• Never trust a user ID or role sent from the client. Read it from the session.
• Give the app's database user only the permissions it needs.

This is the single most useful prompt to hand an agent for the database step. It asks for a report and forbids changes until you approve, which keeps a helpful agent from rewriting your policies on its own:

List every database table, bucket and storage location. For each, state who
can read, insert, update and delete it through the public client or API, and
what enforces that (row-level security policies, server checks, or nothing).
Flag every table with no rules, rules that allow everything, rules based on
user-editable fields, and views or functions that bypass the rules. Then write
a test (or SQL script) that proves user A cannot read or change user B's rows.
Report first. Do not change policies until I approve.

4. Input and output

• Validate every input on the server: type, length, format. Client-side checks are for friendliness only.
• Use parameterised queries or your ORM. Watch for any string-built SQL an agent produced.
• Escape or sanitise user content before rendering it as HTML.
• Limit file uploads by size and type, and store them outside the web root or in a bucket with sensible access rules.

5. Dependencies

• Run your package manager's audit command and fix high-severity findings.
• Check that every package an agent added actually exists and is the one you meant. Look-alike package names are a real attack.
• Remove packages you do not use.

6. Transport, headers and CORS

• HTTPS only, with redirects from HTTP.
• Restrict CORS to the origins you actually use. Avoid a wildcard on routes that use cookies or credentials.
• Set sensible security headers such as a content security policy and frame protection.
• Mark session cookies HttpOnly, Secure and SameSite.

7. Errors and logging

• Production errors should not show stack traces or database messages to users.
• Never log passwords, tokens or full card numbers.
• Set up error alerts so you hear about problems before your users tell you.

8. Payments and webhooks

• Verify webhook signatures. Do not mark an order paid because a request said so.
• Compute prices on the server. Never accept a price from the client.
• Use the provider's hosted checkout where you can, so card data never touches your server.

9. Backups and recovery

• Turn on automated database backups and test a restore once.
• Know how to roll back a bad deploy.
• Write down who can access production and remove anyone who should not.

10. Ask the agent to audit itself, then check its work

Agents are decent reviewers when given a narrow brief. Ask for one category at a time, such as "review every API route for missing authorisation checks and list file and line". Then verify the findings yourself. An agent that says everything is fine has not earned your trust.

The Vibemast Ship-It Kit includes 20 security audit prompts built this way, one per risk area, a one-page checklist PDF, and rescue prompts for when an agent has made a mess. The free mini pack includes five prompts to try first. It will not replace a professional review for sensitive data, and it cannot test your app for you. It gives your agent a structured way to look for the common problems.

Hoist it. Ship it.

To stop the agent creating these problems in the first place, add the security lines from the 12 AI coding agent rules to your rules file.

Turn the checklist into an audit you can run

A checklist is only useful if each item gets checked. A practical order for one afternoon:

1. Secrets and anything sent to the browser first: they are the fastest to find and the worst to leak.
2. Database access next. On Supabase, use the Supabase RLS checklist for AI-built apps.
3. Then authorisation on every route, payments and webhooks, and rate limits.
4. Ask the agent to report findings only, with no edits, then fix one finding at a time in small diffs.

To stop the same problems coming back, add the security lines from the 12 rules for AI coding agents to your rules file.

The Ship-It Kit has 20 audit prompts, one per area (secrets, browser-exposed keys, database access, auth, authorisation, injection, XSS, CSRF and CORS, uploads, rate limits, payments and webhooks, dependencies, logging, admin surfaces, privacy, AI features, backups and a final attack simulation), plus a one-page checklist PDF.

Who the paid kit is for, and who it is not for

• Worth it if you build on one of its four stacks (Next.js with Supabase, Vite with React, FastAPI, Phaser) and want tested files and prompts today instead of writing and testing your own.
• Not worth it if you only need one rules file for one project. The free guides and the free mini pack are enough, and you can adapt them yourself.

Related guides

• Cursor rules for Next.js and Supabase
• When your AI agent keeps breaking your code

FAQ

How long does this take?

About an afternoon for a small app if you work through it in order. Larger apps need longer, particularly the authorisation step.

What should I check first?

Secrets and database access. A leaked key or an open table is the most damaging and the easiest to find.

Can an AI agent run this checklist for me?

It can do a useful first pass, one category at a time. Ask it to report before it changes anything, then check the findings yourself.

Is this enough for an app that takes payments?

It covers common basics, including webhook verification and server-side prices. Because money is involved, a professional review is a sensible extra step.