
Vibe coding turns a plain-language prompt into a working app in an afternoon. A founder can describe a booking form, a dashboard, or a small store, and watch the code appear. The demo looks finished. The danger hides one layer deeper: code that runs is not code that holds up under attack. This article shows the holes that appear most often in AI-generated apps, and the short checklist that closes them before launch.
Vibe coding earns its place in a builder toolkit. It cuts the time from idea to working prototype from weeks to hours, and it lets people without a formal coding background test ideas that would otherwise stay on paper. Speed alone does not make an app ready for users. Research keeps returning the same warning: a large share of AI-generated code carries security flaws that a short review would catch. Veracode tested AI-generated code against common vulnerability patterns and found that 45 percent of samples introduced a known security vulnerability, with 86 percent lacking defenses against cross-site scripting. Treat every AI-written codebase as a draft. Read it, scan it, test it, and name one person who owns each release. With that gate in place, vibe coding stays fast and stops leaking.
If you are new to the approach, start with What Is Vibe Coding? Definition, Uses, and Limits for the basics, then use this guide as the security pass before you ship.
Three independent lines of research point the same way. First, lab tests of generated code keep finding the same flaw classes: injection, broken access control, and missing input validation. Veracode’s GenAI Code Security Report put the vulnerability rate at 45 percent of samples, and the cross-site scripting gap at 86 percent. Second, field data shows the review gap widening. Stack Overflow’s 2025 Developer Survey found that 84 percent of developers use or plan to use AI coding tools, while 46 percent distrust the accuracy of the output. Developers ship more code than they read. Third, real incidents confirm the pattern. Researchers at Wiz found a vibe-coded social platform, Moltbook, with a misconfigured database open to the internet, exposing about 1.5 million authentication tokens and 35,000 email addresses. No sophisticated exploit broke in. A missing configuration check left the door open.
Secrets sprawl adds another measurable risk. GitGuardian counted 23.8 million secrets leaked on public GitHub in a single year. AI tools raise the odds of a leak because a prompt can ask the model to “make login work” and the model answers with a key pasted straight into the source. One more number shapes the whole discussion: GoodFirms reports that 19.7 percent of AI-recommended packages turn out to be hallucinated, names that sound plausible and install nothing, or worse, names that attackers register to catch careless installs. Speed creates volume. Volume without review creates exposure.
For the full research picture, see the GoodFirms analysis of vibe coding security risks and the Levelop guide to hidden risks in vibe-coded apps. Both gather the primary studies in one place.
Security scanners see the same five flaws again and again in AI-generated apps. Learn the shape of each one and you can spot most of them in a single read-through.
Broken access control sits at the top of the OWASP Top 10 for good reason. An AI model builds the happy path first: a logged-in user sees their own dashboard. It often skips the check that stops one user from opening another user’s record by changing an ID in the URL. Test every route with a second account. If user B can open user A’s data, the app is not ready.
Injection flaws come next. A model that builds a search box or a comment form may glue user input straight into a database query or page markup. Parameterized queries and output encoding close this hole. Any code that builds SQL or HTML by gluing strings together deserves a rewrite.
Secrets in source code form the third hole. API keys, database passwords, and tokens pasted into frontend code or committed files leak the moment a repo goes public or a bundle ships to browsers. Move every secret to environment variables on the server, and route third-party calls through a backend.
Missing authentication on admin routes is the fourth. AI scaffolds often generate an admin page, a debug endpoint, or a data export route with no login check at all. Search the codebase for “admin”, “debug”, and “export” and confirm each route demands a logged-in admin.
Hallucinated packages round out the list. A model invents a package name, a developer installs it without checking, and an attacker who registered that name ships malicious code. Verify every dependency on its registry page before install, and pin versions so a later reinstall pulls the same code.
Secret handling decides more breaches than any clever exploit. AI models learn from public code, and public code contains plenty of keys pasted in plain sight. A model repeats the pattern without warning. Builders must break the pattern at three points.
First, keep secrets out of prompts. A prompt that includes a real key teaches nothing and risks logging the key in a chat history or a shared workspace. Tell the model to read secrets from environment variables instead. Second, keep secrets out of frontend code. Anything shipped to a browser is public, no matter how the code obfuscates it. Third, scan before every release. Tools like TruffleHog and Gitleaks find keys in git history in seconds, and a key that already leaked needs rotation, not deletion alone, because deletion never unpublishes a commit someone already copied.
One habit prevents most of this class: add a secrets file to version control ignore lists on day one, and make the app fail with a clear error at startup when a required secret is missing. A loud failure beats a silent fallback to a hardcoded default.
Frontend checks shape the interface. Server checks guard the data. AI-generated apps often confuse the two. A button hidden from non-admin users still leaves the endpoint open to anyone who calls it by hand. Every data route needs its own authorization check on the server, independent of the interface.
Database permissions add a second layer. Backend-as-a-service platforms like Supabase and Firebase ship with row-level security that a builder must enable table by table. A vibe-coded app that skips this step can expose entire tables to any authenticated user, or to the public when anonymous access stays on. Open each table, confirm the policy, and test with a low-privilege account. The Moltbook case shows the cost of skipping this check: a database left open exposed tokens and addresses at scale.
Related reading on our site covers the wider maintenance side: Vibe-Coded Tech Debt: How to Find and Fix It shows how small skipped checks compound into a codebase nobody wants to touch.
Run this checklist in order. Each item takes minutes and catches a class of flaw that scanners sometimes miss. Stop the release when an item fails, fix it, and rerun the list.
| Check | Pass Looks Like | Fail Looks Like |
|---|---|---|
| Secrets scan | Scanner reports zero keys in code and history | Any key, token, or password in source |
| Access control test | Second account cannot open first account data | URL ID change reveals another user’s records |
| Admin route audit | Every admin and debug route demands admin login | An admin page loads without login |
| Dependency check | Every package verified on its registry page | An unknown or unversioned package in the lockfile |
| Database policy review | Row-level rules enabled on every table | Any table readable without authentication |
| Input handling | Parameterized queries and encoded output everywhere | SQL or HTML built by string gluing |
Pair the checklist with a testing pass. How to Test AI-Generated Code Before You Ship covers the test types that catch behavior bugs, while this checklist covers the security side.
Manual review catches logic flaws. Automated scanners catch pattern flaws at scale. Use both, and wire the scanners into the build so a failing check blocks the release instead of arriving as a report nobody reads.
| Tool Type | What It Catches | Good Starting Options |
|---|---|---|
| Static analysis (SAST) | Injection, unsafe functions, weak crypto in source | Semgrep, Snyk Code |
| Dependency scan (SCA) | Known vulnerable or hallucinated packages | Snyk, npm audit, Dependabot |
| Secrets scan | Keys and tokens in code and git history | TruffleHog, Gitleaks |
| AI code review | Logic gaps a pattern scanner cannot see | A second model pass with a security prompt |
Free tiers cover small projects well. Semgrep runs from the command line, Dependabot ships inside GitHub, and TruffleHog scans a repo in one command. The Kaspersky guide to safer vibe coding adds small-team habits around these tools, and the Catdoes vibe coding security checklist groups the same checks by priority for founders shipping solo.
Context discipline also matters. MCP Explained: How AI Coding Tools Get Context shows how the context you feed a coding agent shapes the code it writes, and AGENTS.md: The One Rule File Every AI Coder Reads shows how to bake security rules into the agent itself, so every generation starts with the guardrails already in place.
Vibe coding is not going away, and it should not. It hands builders a fast path from idea to working software. The risk was never the speed. The risk was shipping the output without the checks that every other codebase gets. A secrets scan, an access control test, a dependency check, and a named reviewer for each release close most of the holes researchers keep finding. Build the gate once, run it every time, and the speed stays yours without the exposure. Start with your current project: run the checklist above on the last feature you shipped, fix the first fail you find, and make the checklist part of your release routine from that point on.