The Vibecoder's Security Checklist

The short, non-negotiable list of security things to get right in any app you build by vibecoding. It exists because AI reliably produces code that works in a demo and is wide open in production, and none of these gaps show up when you test your own app — only when someone malicious does.

Most real-world breaches of small apps come from a handful of the same mistakes, and every one of them is something the AI will happily leave in unless you ask. Turning them into a checklist means you don't have to be a security engineer — you just have to run down the list and make the AI fix each item before the app touches the public internet.

Before your app is reachable by anyone but you, and again before any launch. Run the whole list any time the app starts handling real user accounts, real data, or real money.

There's no point at which a public app is exempt. For a purely local experiment that no one else can reach, the urgency is lower — but the moment it's deployed, the list applies.

Do a security review of this app as if you were an attacker, focused on the common vibe-coding gaps: (1) secrets or API keys exposed in the frontend, (2) missing or weak authentication and authorization, (3) a database without access rules so users can read others' data, (4) missing input validation, (5) debug modes or verbose errors left on in production. For each, tell me if it's a problem here and exactly how to fix it.

A founder runs this checklist on a working app and discovers the database had no access rules — any logged-in user could read every other user's records by changing an ID in the URL. It looked perfect in their own testing; the checklist caught it before launch, not after a breach.

Turn the checklist into a repeatable gate: run it as a prompt after every significant feature, keep a short written record of what was checked, and add automated checks (auth required on protected routes, no secrets in the client bundle) so regressions can't sneak back in as the app grows.

• Treating 'it works when I use it' as evidence it's secure — you're not the threat model.
• Fixing one item and assuming the rest are fine; the gaps usually come in clusters.
• Running the review once before the first launch and never again as the app changes.