Is AI-Generated Code Safe to Ship? The Checklist for Non-Developers

The uncomfortable truth and the practical fix: where vibe-coded projects actually get burned, and the pre-launch checklist that catches most of it — no security degree required.

DifficultyBeginner

Time15 min read, 1 hour to apply

You'll needThe AI that built your project

You'll buildA pre-launch security pass you can run on any project — using the AI itself as your reviewer, pointed the right way.

Short answer: AI code is as safe as the questions you asked. Models write working code by default, not hardened code — and they'll cheerfully omit input validation, expose secrets, and trust every user, because you didn't mention attackers and they didn't volunteer. The good news: the same AI finds these problems instantly when explicitly asked. This page is the asking.

First, triage: what kind of project is this?

Tier 1 — personal tools on your own machine or behind no public URL: relax, the checklist below is optional hygiene. Tier 2 — public but read-only (content sites, portfolios, games without accounts): low risk; the secrets and forms sections apply. Tier 3 — anything accepting user input, storing data, taking payments, or calling paid APIs: the full checklist, no exceptions, because tier 3 is where real people get burned.

The Big Five failure modes

Nearly every vibe-coding horror story is one of these: (1) Secrets in frontend code — API keys visible to anyone who clicks View Source, then drained by bots (the Claude-API tutorial's proxy pattern is the fix). (2) Trusting user input — forms and URLs fed straight into databases or pages, enabling injection attacks. (3) Missing authorization — checking who you are but not what you're allowed to touch, so user A can read user B's data by changing a number in the URL. (4) Open databases — Supabase/Firebase tables with no row-level security, fully readable and writable by the public (our database tutorial drills RLS for exactly this reason). (5) Client-side enforcement — prices, permissions, or game rules enforced only in the browser, where any user can edit them.

The pre-launch prompt (run it verbatim)

Act as a security reviewer for code written by a non-developer about to make this public. Review every file for, in priority order: exposed secrets or API keys; user input used without validation or sanitization (XSS, injection); missing authorization checks — could one user access another's data; database security rules (assume the client is hostile); anything security-critical enforced only client-side. For each finding: severity (critical / should-fix / hardening), what an attacker could actually do, and the exact fix. No style feedback. Then list what you CAN'T verify from code alone that I should check manually. [paste all files / run in your project with Claude Code]

Worth knowingRun it in a FRESH conversation, not the one that built the project. The builder session is invested in its own choices; a cold reviewer with a hostile mandate finds what the proud parent missed. Two different models reviewing is even better.

The manual checks no review can do for you

Five minutes of hostile clicking: view-source your live site and search for 'key', 'token', 'secret'; submit your forms with garbage, emptiness, and <script>alert(1)</script>; if users have data, log in as one and try to reach another's by editing URLs; check your Supabase dashboard's RLS warnings (it literally flags unprotected tables); confirm spending limits exist on every paid API. Attackers' scripts try exactly these within days of any site going live — beat them to it.

The honest boundaries

This checklist makes hobby and small-business projects respectable, not bulletproof. Some things should exceed vibe-level assurance: storing passwords yourself (don't — use Supabase Auth or similar), handling card numbers directly (don't — that's why Stripe-hosted checkout exists, see the payments tutorial), medical or legal data, anything where a breach hurts people who trusted you. The mature move isn't avoiding those forever; it's knowing that crossing that line means paying for a real review — and budgeting for it like you budget for hosting.

Make it a habit, not an event

One rule that compounds: every time a project gains a new power — first form, first login, first payment, first API key — that's a security-prompt moment, not just pre-launch. The checklist takes ten minutes; the habit is what actually keeps you safe.

Keep going

Need somewhere to put it live? See where to host AI-built sites. Compare tool costs on the pricing tracker (or stick to the free options), then pick your next build.