PRE-LAUNCH SECURITY · 2026

Ship the idea.
Secure the edges.

27 checks for the security gaps AI-generated code can leave behind. Work through them before your app goes live.

Download the checklist PDF Start the checklist

27 practical checks
5 security areas
Progress saved here

Shakir CheppaliBy Shakir Cheppali · @shakirc.ai

BEFORE THE FIRST USER

AI can help you build fast.
Security still needs a human pass.

PRE-LAUNCH / 27 CHECKS

THE FIVE AREAS

0101–04 / CHECKSSecrets and API keys4 checks 0205–10 / CHECKSAuthentication and access6 checks 0311–17 / CHECKSData and user input7 checks 0418–23 / CHECKSHTTPS, headers and production config6 checks 0524–27 / CHECKSDependencies, monitoring and testing4 checks

YOUR PRE-LAUNCH PASS

Check what’s already true.

Ticks are saved in this browser. Come back any time and pick up where you left off.

01

CHECKS 01–04

Secrets and API keys

0 / 4

Keep credentials out of the browser, source control, and Git history. If a secret has escaped, rotate it.

01Hide your API keysKeep secret keys on the server in environment variables. Anything in frontend code or a NEXT_PUBLIC_ variable is visible to everyone.
02Keep .env out of GitAdd .env to .gitignore and commit only a .env.example with empty values.
03Scan your Git history for leaked secretsDeleting a key in a later commit does not remove it from history. Run gitleaks or trufflehog, or turn on GitHub secret scanning.
04Revoke and rotate any exposed keyIf a key was ever committed or shipped to the browser, treat it as stolen: create a new one and disable the old one.

02

CHECKS 05–10

Authentication and access

0 / 6

Enforce identity, ownership, and roles on the server for every protected request.

05Lock your databaseTurn on Row Level Security (or equivalent rules) on every table, so each user can read and write only their own rows.
06Check auth on every API routeVerify the session on the server for each request. Hiding a button in the UI is not protection.
07Stop ID guessingChanging /orders/18 to /orders/22 must not show someone else’s data. Check that the record belongs to the logged-in user.
08Lock down admin routesCheck the user’s role on the server for every admin page and admin API, not just in the menu.
09Store passwords safelyUse a trusted auth provider, or hash passwords with bcrypt or argon2. Never store plain text.
10Make password-reset links expireOne use only, valid for 15–60 minutes, and invalidated after the password changes.

03

CHECKS 11–17

Data and user input

0 / 7

Treat all browser input as untrusted. Validate it, limit it, and return only what the caller is allowed to see.

11Validate every form on the serverBrowser checks are easy to bypass. Validate type, length and range again on the server (for example with zod).
12Use parameterised queriesUse your ORM or query builder. Never build SQL by joining strings with user input.
13Prevent XSSEscape or sanitise anything users can post (comments, names, bios) before showing it. Avoid dangerouslySetInnerHTML with user content.
14Restrict file uploadsAllow only the file types you need, set a size limit, rename files, and store them in private storage.
15Verify prices and payments on the serverNever trust a price or total sent from the browser. Check payment webhooks with the provider’s signature.
16Rate-limit sensitive endpointsLimit login, signup, OTP, password reset and AI calls per user and per IP to stop brute force and surprise bills.
17Return only the data you needAPI responses should not include password hashes, emails of other users or internal fields.

04

CHECKS 18–23

HTTPS, headers and production config

0 / 6

Ship with secure transport, browser protections, safe error handling, and a clean production environment.

18Enforce HTTPSRedirect all HTTP traffic to HTTPS and turn on HSTS.
19Restrict CORSAllow only your own domains. Never use * on APIs that use cookies or tokens.
20Add security headersSet Content-Security-Policy, X-Frame-Options, X-Content-Type-Options and Referrer-Policy.
21Secure your cookiesMark session cookies HttpOnly, Secure and SameSite, and protect forms against CSRF.
22Turn off debug mode in productionShow users a generic error page and keep stack traces in your logs only.
23Remove leftoversDelete test accounts, seed data, exposed .git folders, backups and public source maps from the live site.

05

CHECKS 24–27

Dependencies, monitoring and testing

0 / 4

Reduce attack surface, spot suspicious activity, and review the whole app before launch.

24Update vulnerable packagesRun npm audit (or your package manager’s equivalent) and update anything flagged high or critical.
25Remove unused packagesEvery extra dependency is extra attack surface. Uninstall what the app no longer uses.
26Log and monitor suspicious activityLog failed logins, permission errors and unusual spikes, and set an alert. Keep automatic database backups on.
27Run a full security testAsk Claude to audit the codebase against this list, fix every finding, then test the main flows again.

0 / 27checks complete

FINISH WITH A CODE REVIEW

Ask Claude to check
the whole codebase.

The PDF recommends a full audit against this list. Copy a ready-to-use prompt, then review each finding before making changes.

CLAUDE PROMPT

Review this codebase for security issues before launch. Audit it against each point, report concrete findings with file paths and severity…

27 checks · Findings first · Fixes in priority order

TAKE IT WITH YOU

Save it. Share it.
Ship with care.

Keep the printable checklist nearby while you prepare your app for launch.

Download the checklist PDF

SC · FIELD GUIDE27-Point
Pre-Launch
Security ChecklistFOR VIBE CODERS · 2026

PDF CHECKLIST27 checks · 5 areasDownload PDF ↗

Ship the idea.Secure the edges.

Ask Claude to checkthe whole codebase.

Save it. Share it.Ship with care.

Ship the idea.
Secure the edges.

Ask Claude to check
the whole codebase.

Save it. Share it.
Ship with care.