Vibe Coding Security Checklist
87 checks across 11 categories for apps built by prompting an AI coding tool — check them off, then copy the list as a ready-to-paste prompt for your AI assistant to review your codebase against.
0 / 87 checked
No checklist items match your search.
How it works
"Vibe coding" means building an app largely by prompting an AI tool rather than writing the code by hand — and the result can run perfectly on your laptop while still being wide open the moment it's public. Once a URL is reachable, anyone can call your API directly, guess adjacent URLs, or read whatever got left in your JavaScript bundle; an interface that only looks locked down isn't locked down at all.
This checklist collects 87 checks across 11 categories: access control, roles and permissions, accounts, abuse and cost limits, input and file handling, AI-feature-specific risks, browser security headers, secrets management, infrastructure, the legal pages almost every new app skips, and payment handling. It is not a penetration test and won't make an app unhackable — it closes the specific gaps that most often get beginner AI-built apps compromised: authorization checks that live only in the UI, permission roles read from editable client-side storage, and API keys shipped inside the browser bundle.
Two items here carry more nuance than a one-line summary usually gives them:
- Password hashing. Argon2id is OWASP's current recommended default, with scrypt as a fallback and bcrypt reserved for legacy systems that can't run either — not three interchangeable options. MD5 and SHA-1 were never designed for password storage and shouldn't be used for it.
- Minimum password length. 8 characters is the long-standing NIST floor for a user-chosen password, but NIST's 2025 SP 800-63B Revision 4 recommends 15+ characters specifically when the password is the only factor protecting the account — i.e. when there's no MFA behind it.
Check items off as you go — progress saves in this browser only, nothing is sent anywhere. Use Copy as AI prompt to get a plain-text version of the full list, checked items marked, ready to paste into Claude, ChatGPT, or Cursor and ask it to review your codebase and explain what it changed.
FAQ
What is a vibe coding security checklist?
A vibe coding security checklist is a pre-launch review for apps built largely by prompting an AI coding tool (Cursor, Claude, Replit, Lovable, bolt.new) rather than written by hand. It targets the gaps that specifically trip up AI-generated apps — authorization checks that live only in the UI, permission roles read from the browser, and API keys shipped inside the JavaScript bundle — before the app goes public.
Does CORS protect my API from unauthorized access?
No. CORS only restricts which websites' JavaScript is allowed to read your API's response inside a browser — it has no effect on direct requests made with curl, Postman, or a script, which ignore CORS entirely. It's a browser-enforced policy, not a server-side access control, so it has to be paired with real authentication and authorization checks.
Do I still need Row Level Security if I'm using Supabase or Neon?
Yes. Row Level Security (RLS) is a PostgreSQL feature that both Supabase and Neon expose, and it should be turned on for every table holding user data. It makes the database itself refuse to return rows that don't belong to the requesting user — a backstop that still protects you even if an application-level query has a scoping bug.
What's the minimum safe password length in 2026?
NIST's SP 800-63B guideline has long set 8 characters as the floor for a user-chosen password, but its 2025 Revision 4 recommends at least 15 characters when the password is the only authentication factor with no MFA behind it. Checking new passwords against a breached-password list matters more for real-world security than forcing complexity rules.
Is this checklist the same as a penetration test?
No. This is a self-review checklist of common gaps, not a penetration test, and it won't find every vulnerability or substitute for professional security testing before handling sensitive data at scale. It closes the holes that most often get beginner AI-built apps compromised, not every possible hole.
What's the most common way AI-built apps get taken over?
Reading a user's role or permission level from client-side storage — localStorage, a cookie, or an unverified JWT claim — instead of looking it up server-side from the database on every request. Because client-side values are fully editable by whoever owns the browser, this single pattern is behind most reported takeovers of vibe-coded apps.