Is vibe coding secure? What the research says, and what to check

Why does generated code miss security?

A coding tool is asked for a feature and optimises for the feature working. Ask for “let users download their invoices” and you get an endpoint that downloads an invoice. You test it on your own account. It works.

What the tool does not do, unless you ask, is decide who is allowed to download which invoice. That rule belongs to your business, not to the framework, so there is no convention for the model to fall back on. It is also invisible in every test a founder naturally runs, because you only ever test as yourself. Security properties are mostly about what should not happen, and nobody demos what should not happen.

The same is true of the backend a browser builder sets up for you. The database works on day one. Whether a stranger can read it depends on rules that nobody looks at while the feature is being built.

Which flaws show up most in vibe-coded apps?

The public record shows a short list that repeats:

• Broken access control. A signed in user can read or change another user’s records by changing an id. OWASP ranks broken access control first in its Top 10:2025 and reports that every application in its contributed test data had some form of it. See how IDOR works in AI-built apps.
• Database rules left open. Apps that query a hosted database straight from the browser depend on row level security policies. CVE-2025-48757 describes exactly this in sites generated by one app builder; the supplier disputes the record, and the dispute itself makes the point that the app owner is responsible for the rules. More in securing an app made with an app builder.
• Secrets in the wrong place. A secret API key bundled into the frontend, or committed once and left in the history. See what to do when an API key is in your frontend.
• Missing browser protections. No HTTPS redirect, no security headers, a wildcard CORS rule added to make local development stop complaining.
• Errors that say too much. Stack traces and query fragments returned to the browser because they were useful while building.
• AI features that trust their own output. A chatbot or agent that acts on whatever text it reads. See how to limit prompt injection.

None of these are exotic. The generated code is usually competent at the mechanical parts with one right answer, such as parameterised queries and password hashing. The misses cluster where the right answer depends on your own rules. We wrote about that pattern in what AI coding tools actually get wrong.

Is one AI coding tool more secure than another?

The evidence does not support a ranking. The 2025 report above found no major language immune and no improvement from bigger models, and every tool on the market writes code from the same kind of instruction: yours. If your prompt never mentions who may see what, no tool will reliably invent the rule.

What does differ is how much the tool decides for you. Coding tools that work in your editor change code you can read and run locally, so the review happens in your repository. Browser app builders also make architecture choices on your behalf, often including where the database lives and how the browser reaches it. That makes the database rules and the server routes the first place to look.

What should you check before launch?

You do not need to read the whole codebase. Check by category, ask your coding tool targeted questions, and write down the answers. A first pass looks like this:

• Access control: list every route that reads or changes a record by id, and confirm each one checks the record belongs to the caller. The guide stop one user reading another user’s data walks through it.
• Database rules: confirm row level security is on for every table the browser can reach, with a policy per action. See lock down a hosted database.
• Secrets: search the built frontend and the repository history for keys. If one is exposed, rotate it first.
• Transport and headers: HTTPS everywhere and the standard security headers. HTTPS and security headers in ten minutes covers the set.
• Errors and AI features: generic errors to the browser, details to your logs, and an AI feature that cannot do more than the user could.

A useful prompt to start with: “List every API route and server function in this project. For each one, tell me how the caller is authenticated, what record it reads or writes, and what code checks that the caller owns that record. Do not change anything yet.” The answer is a map. The routes with an empty last column are your first fixes.

The free Vibe Coding Security Checklist puts every check in one place, ranked by severity with a fix deadline, and says how to check each one by hand. It is the long version of the list above.

How do you show someone else that your app is secure?

Sooner or later an investor, a customer or a procurement team asks. “We use best practices” does not survive the second question. A dated record does: what you checked, what you found, what you fixed, and how you confirmed the fix held. Gaps are expected at an early stage; not knowing where they are is the real finding.

The guide answer “is it secure?” with evidence shows how to build that record by hand, and our post on answering a security questionnaire covers the written version buyers send.

So, is vibe coding secure?

It is as secure as the checks you run on what it produced. The tools have made writing software faster without making the security review optional, and the review is smaller than it looks because the failures are predictable. Start with access control and the database rules, because those are where real data leaks, then work down the list.