The vibe coding security checklist you can actually enforce at runtime

AI writes the feature in minutes, while security work can be missed or deferred. AI-assisted launches can expose secrets, databases, or authorization mistakes unless teams review and enforce the right controls. This is the 13-point checklist of common risks and why scanning once is not enough to keep them fixed.

Why AI-built apps ship insecure by default

An AI coding agent optimizes for one thing: making the feature work. Ask it to "add login" and it will produce something that logs in. It will not, unasked, threat-model the auth flow, rotate secrets out of the repo, add rate limiting, or lock down the database — because none of that is what you asked for, and none of it shows up when you click around the happy path.

That's the trap. The app looks done. It demos perfectly. And the holes — a Supabase key sitting in client-side JavaScript, an authorization check that runs in the browser, an admin route with no guard — are invisible until someone who isn't you goes looking. By then it's a headline, not a checklist item.

The 13-point vibe coding security checklist

Run this before anything AI helped you build touches real users:

• No secrets in the repo or the client bundle. Grep for API keys, tokens, and connection strings in your source and your shipped JS. AI loves to hardcode them. Move everything to server-side environment variables.
• Authorization is enforced on the server, not the browser. The single most common AI mistake: hiding a button or gating a route in client code. Anyone with dev tools bypasses it. Every protected action must be checked server-side, per request.
• Row-level / object-level access control on your data. "User A can only see User A's rows" must be enforced by the database or the API, not assumed. Backwards or missing access control has exposed tens of thousands of users in real vibe-coded apps.
• Rate limiting on every public endpoint. Without it, one script maxes out your API, your bill, or your login form. AI rarely adds it.
• No debug, seed, or admin endpoints left exposed. Scaffolding the AI generated to "test" something often ships to prod wide open. Remove or guard them.
• Input is validated and parameterized. Confirm queries are parameterized (no string-built SQL) and user input is validated server-side — injection is still the classic.
• Auth tokens are short-lived and stored safely. Check token lifetime, refresh handling, and that nothing sensitive sits in localStorage where any script can read it.
• The database is not publicly reachable. Confirm it's firewalled to your app, not the internet, and that default credentials are gone.
• Dependencies are pinned and scanned. AI pulls in packages freely. Lock versions and run a vulnerability scan.
• Error responses don't leak internals. No stack traces, env values, or SQL in what the user sees.
• Money paths are server-verified. Paywalls, entitlements, and prices must be checked server-side. Client-only paywalls get bypassed and your keys get drained.
• You can see what's actually running. Runtime logs and request traces, in one place — so you find a problem before a user does.
• Define evidence and recovery per managed change. Retain actor, release, and result evidence where configured, and design rollback separately because not every change is logged, attested, or reversible.

Why a one-time scan isn't enough

Most "vibe coding security" advice ends at "run a scanner." Scanners are useful — but a scan is a snapshot of one moment. The whole premise of vibe coding is that you keep shipping AI-generated changes, fast. The change you make tomorrow can reintroduce the exact hole the scan cleared today, and nobody re-runs the scan before every deploy.

Security that survives rapid iteration is not a one-time audit. Apply configured runtime rules to managed routes and services, choose the appropriate manual, exact-hash allowlist, or automatic release mode, and retain bounded evidence. None of that proves complete runtime state or guarantees rollback.

Enforce configured runtime boundaries

This is the layer a code scanner and a coding assistant can't give you, because it isn't about the code — it's about the live system:

• Security policy enforced on the running app, not just recommended in a report — rate limits, blocked traffic, and access rules applied to real requests.
• An explicit approval rule for managed changes, using manual review for risky work and allowlist or automatic approval where your policy permits it.
• Runtime logs and request traces in one place, so you catch the breach attempt or the broken auth check as it happens.
• Bounded action evidence and recovery controls, with explicit scope, retention, attestation status, and recovery preconditions.

Frequently asked questions

Is vibe coding secure enough for production?

Not by default — AI optimizes for "it works," not "it's safe." It can be production-ready after you explicitly add and enforce the controls the AI skipped: server-side authorization, no exposed secrets, rate limiting, locked-down data, and an audit trail.

What are the most common security mistakes in AI-built apps?

Hardcoded/exposed secrets, missing or backwards authorization, access control enforced only in the browser, no rate limiting, leftover debug/admin endpoints, and no audit trail — because the model ships the happy path and skips the controls nobody asked for.

Is a one-time security scan enough?

No. A scan is a snapshot; a later change can reopen the hole. Use configured runtime controls and bounded evidence, and verify their coverage rather than treating them as complete proof of what ran.