Is Vibe Coding Safe? A Security Checklist for AI-Built Apps
Quick answer
Vibe coding is safe to ship only if you review the code like any other code. In Veracode's 2025 benchmark of more than 100 AI models, generated code introduced a security flaw in 45% of tasks. Before launch, check authentication, input validation, secrets, and database access rules, and never give an AI agent production credentials.
What the data says
In July 2025, Veracode tested more than 100 AI models on 80 coding tasks designed around known security weaknesses. The models wrote code that worked, but it introduced a security flaw in 45% of tasks. Two weaknesses stood out: the models failed to defend against cross-site scripting in 86% of relevant cases and against log injection in 88%. Veracode also found that security results had not improved as the models got better at writing correct code.
These are benchmark tasks chosen to probe known weaknesses, not a measurement of all AI-written code. They still show the pattern: AI code that runs is not the same as AI code that is safe.
Two incidents worth learning from
| Incident | What happened | The lesson |
|---|---|---|
| Replit agent deletes a database (July 2025) | During a code freeze, an AI agent ran commands that deleted a production database, despite instructions not to make changes without approval. Replit's CEO called it “unacceptable” and added safeguards, including separate development and production databases. | Instructions are not guardrails. Keep agents away from production. |
| Exposed Lovable apps (CVE-2025-48757, 2025) | A researcher scanned 1,645 apps from Lovable's public showcase and found about 170 with Supabase tables anyone could read or write, because row-level security was missing or misconfigured. Lovable disputes the CVE, saying each app owner is responsible for their data. | Whoever is responsible, the data is yours to protect. Check your database rules. |
Pre-launch security checklist
Accounts and access
□ Every page and API route that shows private data checks who is logged in
□ Users can only read and change their own records (test with two accounts)
□ Row-level security is ON for every database table
Inputs
□ Every form and API input is validated on the server, not just in the browser
□ User-provided text is escaped before it's shown on a page (prevents XSS)
Secrets
□ No API keys or passwords in the code or the git history
□ Secret keys live in environment variables on the server
□ Only public, limited keys are ever sent to the browser
Errors and logs
□ Error messages don't reveal whether an email exists or how the system works
□ Logs never contain passwords, tokens, or payment details
Recovery
□ Backups exist, and you have restored from one at least onceGuardrails for AI agents
- No production credentials. Give agents a development database and read-only keys wherever possible.
- Work on branches. Let the agent change a branch; you merge after review.
- Enforce checks with hooks. A rule in your CLAUDE.md is guidance. A hook that runs tests and blocks on failure is enforcement.
- Review with a second model. Use the Check step of the ARC Method, ideally with a model from a different vendor.
A security review prompt to copy
"Security audit only. Do not change behavior or style.
Review this diff for: missing authentication or authorization checks,
unvalidated inputs, injection (SQL, XSS, log), secrets in code,
sensitive data in responses or logs, and database access rules.
For each issue: file and line, severity (HIGH / MED / LOW),
how it could be exploited, and the exact fix."Go deeper: Chapter 13: Security in the full guide.
Frequently asked questions
Can an AI model review its own code for security?
It helps, but it is not enough on its own. A fresh session with a security-only prompt catches more than the session that wrote the code, and a model from a different vendor catches more still, because models from one family tend to share blind spots.
What is row-level security, and why does it matter for vibe-coded apps?
Row-level security (RLS) is a database rule that limits which rows each user can read or change. Many AI app builders use Supabase, where the browser can query the database directly. If RLS is off, anyone with the app's public key can read or change other users' data.
Should I hire a security professional?
If your app handles payments, health data, or other sensitive personal information, yes. Get a professional review before launch. The checklist on this page covers the basics, not a full audit.
What should I do if I find a leak after launch?
Rotate any exposed keys immediately, close the access path (for example, enable row-level security), check your logs for what was accessed, and tell affected users if personal data was exposed. Then add a check so the same mistake can't ship again.