Vibe Coding Security Checklist: 20 Things to Check Before You Ship AI-Generated Code

AI coding agents write code that works far more reliably than code that's secure. They'll happily put an API key in front-end code, leave a database open to the internet, or forget to check whether the logged-in user actually owns the record they're editing, because the app still works in a demo. Security researchers have repeatedly found serious flaws in a large share of vibe-coded apps.

This checklist covers the issues we see most often. Go through it before you share your app with anyone, and re-run it before each major release. Every section includes a prompt you can hand to your agent.

Why vibe-coded apps are especially vulnerable

• Agents optimize for "it runs". Security failures don't show up as errors.
• Training data includes insecure code. Tutorials often skip auth and validation for brevity. Veracode's 2025 GenAI Code Security Report↗ (opens in a new tab) found AI models introduced security flaws in roughly 45% of tested tasks.
• Beginners don't know what to look for. That's what this checklist is for.
• Real incidents. CVE-2025-48757↗ (opens in a new tab) exposed the databases of many apps built with an AI app builder because Row Level Security was never configured.

Secrets and configuration

1. No secrets in front-end code. API keys for OpenAI, Stripe (secret key), database service roles, etc. must only be used on the server. In Next.js, any variable prefixed NEXT_PUBLIC_ is shipped to the browser. Search your built site's JavaScript for sk_, secret, and service_role.

2. .env files are git-ignored and never committed. Check git log --all -- .env*. If a secret was ever committed, rotate it; deleting the file doesn't remove it from history. See Git for vibe coders.

3. Secret scanning is on. Enable GitHub secret scanning and push protection, or run a scanner like gitleaks↗ (opens in a new tab).

4. Production and development are separate. Different databases, different keys. Never point your local agent at production with write access.

Prompt: Audit this project for exposed secrets: hardcoded keys, secrets in client
components or NEXT_PUBLIC_ variables, committed .env files, and secrets in logs.
List each finding with file:line and how to fix it.

Authentication and authorization

5. Use a proven auth provider. Supabase Auth, Clerk, Auth.js, Firebase Auth, WorkOS and similar. Never let an agent invent its own password hashing or session system.

6. Check authorization on every server action, API route and data query, not just in the UI or in Next.js proxy/middleware. Hiding a button isn't security.

7. Check ownership, not just login. The most common vibe coding bug: /api/invoices/123 returns invoice 123 to any logged-in user. Every query should include "and belongs to this user" (this class of bug is called IDOR).

8. Admin features require an admin check on the server. Roles stored in the client or in user-editable profile fields can be faked.

Prompt: For every Route Handler, Server Action and database query in this project,
verify (1) the user is authenticated and (2) they are authorized for that specific
record. Produce a table: endpoint | auth check | ownership check | issue.

Database security

9. Row Level Security (RLS) is enabled on every table if you use Supabase or expose Postgres to the client. With RLS off, the public "anon" key in your front end can read and write everything. Write policies so users can only access their own rows, and test them while logged in as a different user.

10. Queries are parameterized. Use your ORM or query builder; never build SQL by concatenating user input.

11. Backups are enabled and tested. An agent running the wrong migration can delete data. Know how to restore.

Input, output and the browser

12. Validate all input on the server with a schema library like zod: types, lengths, formats, allowed values. See our Next.js API routes guide for examples.

13. Avoid rendering raw HTML. Be suspicious of dangerouslySetInnerHTML, innerHTML and unsanitized Markdown. If you must render user HTML, sanitize it with a library like DOMPurify.

14. File uploads are restricted by type and size, stored outside your app server, and never executed.

15. Errors don't leak internals. Users should see "Something went wrong", not stack traces, SQL queries or file paths.

Infrastructure and dependencies

16. Rate limiting on login, signup, password reset, AI features and any expensive endpoint. Otherwise bots will brute-force accounts or run up your AI bill overnight.

17. Dependencies are real, needed and updated. AI models sometimes invent package names that don't exist; attackers register those names with malware ("slopsquatting"). Check every new package exists and is popular before installing. Run npm audit and keep your framework patched; React and Next.js have shipped critical security fixes that only protect you if you update.

18. Security headers and HTTPS. HTTPS everywhere, plus headers like Content-Security-Policy, X-Content-Type-Options and Referrer-Policy. CORS should only allow origins that actually need access.

Payments and AI features

19. Payments are verified on the server. Never trust the client to say "payment succeeded". Use Stripe Checkout or Payment Links and verify webhook signatures.

20. If your app uses an LLM, guard against prompt injection and runaway costs. Don't give the model access to data or actions the current user shouldn't have, treat model output as untrusted input, and set per-user usage limits and billing alerts.

Keep your AI agent safe too

Your development environment is part of your attack surface. Recent disclosures showed malicious repositories and plugin updates compromising coding agents (see AI coding agent security news):

• Keep permission prompts on for commands that delete, deploy or push.
• Only install MCP servers from trusted sources, with least-privilege tokens.
• Be careful letting agents read untrusted content (web pages, issues, emails), which can contain prompt injection.
• Put your security rules in AGENTS.md so every session follows them: "Every table needs RLS. Check ownership on every query. Never use NEXT_PUBLIC_ for secrets."

A 15-minute pre-launch security pass

1. Ask your agent to run the three audit prompts above.
2. Fix critical findings first (secrets, missing auth, open database).
3. Create two test accounts and try to access account A's data while logged in as B, by changing IDs in URLs and API requests.
4. Open your deployed site, view the JS bundle in DevTools, and search for "key", "secret" and "sk_".
5. Run npm audit and update anything critical.
6. Turn on backups, billing alerts and error monitoring.

For a bigger app, or anything handling payments, health or personal data, pay for a professional security review. It costs far less than a breach.

Frequently asked questions

Is vibe coding inherently insecure?

No, but AI agents don't prioritize security unless you ask. With a checklist, good context files and review, AI-built apps can be as secure as hand-written ones.

Can I ask the AI to make my app secure?

Yes, and you should, but use specific prompts like the ones above. "Make it secure" is too vague to be reliable, and you should verify the fixes yourself.

What's the most common security bug in vibe-coded apps?

Missing authorization: users can access or modify other users' data by changing an ID. Exposed secrets and databases without Row Level Security come close behind.

Do AI app builders handle security for me?

Partly. Platforms like Lovable, Bolt and Replit provide secure building blocks, but your app's data rules and logic are still your responsibility.

---

Next steps: learn to debug AI-generated code, or follow our full-stack app walkthrough, which builds these checks in from the start.