Going from an idea to a working app in a few days is now routine. A prototype built with Cursor, Claude Code, Lovable or Bolt can look flawless in a demo. The problem is that the distance between "works in the demo" and "safe to open to real users" is invisible.
This article tries to make that distance measurable: what research says about AI-generated code, which vulnerabilities show up most often, and which checks you should run before going live.
Working Code and Secure Code Are Not the Same
Language models are very good at writing code that produces the requested behavior. But satisfying a request and making sure that request cannot be abused are different problems. Ask for "a page that shows the user profile" and the model builds the page. It usually does not ask "what happens if another user changes the ID in the URL?" unless you do.
The nature of vibe coding amplifies this. When code is accepted without being read line by line, security decisions are simply never made. The app works because the only scenario you tested was the well-intentioned user.
What the Research Says
This is no longer guesswork. Two studies stand out.
The Veracode 2025 GenAI Code Security Report tested more than 100 language models on security-sensitive tasks in Java, JavaScript, Python and C#. 45% of generated code samples introduced an OWASP Top 10 vulnerability. On cross-site scripting (XSS) tasks, the failure rate rose to 86%.
CodeRabbit's 2025 report looked at real pull requests: 320 AI-assisted PRs compared with 150 human-only PRs. AI-assisted PRs averaged 10.83 issues, human-only PRs 6.45. By category, the gap is sharper:
| Vulnerability type | In AI-assisted code |
|---|---|
| Cross-site scripting (XSS) | 2.74x more often |
| Insecure direct object reference (IDOR) | 1.91x more often |
| Improper password handling | 1.88x more often |
Honesty matters here: the widely repeated line "AI code has 2.74x more vulnerabilities" actually refers only to the XSS category. The overall picture is not "everything is three times worse". But there is a clear systematic tendency in specific vulnerability types, and those are exactly the ones that are most expensive in production.
An 8-Point Checklist Before Going Live
This list is made of the first things we look at when we take over a project built quickly with AI. All of it can be checked in an audit of a few days.
1. Have secrets leaked into the code or the client?
API keys, database connection strings and service account credentials are the most common problem we find. Keys embedded in frontend code in particular are readable by anyone in the browser. Scan the git history too: a deleted key keeps living in the commit history.
2. Is authorization checked on the server for every request?
Authentication (who you are) and authorization (what you can access) are different things. Hiding a button in the UI is not authorization. On every API endpoint, verify on the server that the requested record belongs to that user. IDOR vulnerabilities come from exactly this gap.
3. Are database access rules open?
In projects built on services like Supabase and Firebase, the client talks directly to the database. The only line of defense is then row-level security rules (RLS in Supabase). A table without rules is open to anyone holding the anonymous key.
4. Is user input validated and escaped?
Treat every piece of data from forms, URLs or APIs as untrusted. Validate schemas on the server, avoid rendering raw HTML, use parameters in database queries.
5. Are dependencies real and up to date?
Models sometimes suggest package names that do not exist. Attackers can register those names and put malicious code inside; this attack is called "slopsquatting". Verify that every new dependency really is the expected package and run automated scanning for known vulnerabilities.
6. Is there rate limiting and abuse protection?
Login, sign-up, password reset and especially endpoints that call a language model should not be exposed without rate limits. Otherwise you may wake up to both account takeover attempts and an unexpected API bill.
7. Do error messages and logs say too much?
In production, stack traces, SQL errors or internal file paths should never be returned to the user. Logs should never contain passwords, tokens or personal data.
8. Are development and production separated?
Separate database, separate keys, backups and a rollback plan. A common scenario in vibe code projects is the development database being carried into production as is.
A Checklist Alone Is Not Enough
These items catch the most common problems, but they do not replace a security audit. The bigger risk is code that nobody truly understands. When a vulnerability is found, the person fixing it needs to know how the system works. We covered this in detail in our knowledge debt article.
One more point: writing code with AI is not the problem. Most teams already use these tools and the speed gain is real. The problem is production speed outpacing review speed. The answer is not to slow down but to make review part of the process: add static analysis and dependency scanning to the CI pipeline, and require code review for critical endpoints.
Conclusion
Vibe coding is the fastest way to get a prototype out in days. But before it becomes a product carrying real user data, working code has to be turned into secure code. The eight items above are the starting point for that work.
We audit, harden and ship AI-built projects under our Vibe Code to Production service. For setting up automated scanning and deployment pipelines, see our DevOps and CI/CD page.
