METHODOLOGY

Vibe-Coded Software

An app generated mostly by AI tools where no human has read the security-critical paths. It demos cleanly and breaks predictably: missing authorization, unvalidated input, leaked secrets. The single most common serious defect is a working login screen with no server-side check stopping user A from reading user B's data.

Last reviewed: byChristof Jori wiki ↗

Vibe-coded software is the output of vibe coding: an application built mostly by AI tools where no human has read the parts that matter for security. It is not defined by being AI-generated. It is defined by the absence of a human review on the paths where getting it wrong costs real money, real data, or a real breach. Plenty of AI-generated code is reviewed and hardened and perfectly safe. Vibe-coded software is the subset that was not.

The defining trait is that it demos cleanly and breaks predictably. It demos cleanly because the model is very good at making the happy path work, the path you walk through in the demo. It breaks predictably because the failures cluster in the same handful of places every time: authorization that checks you are logged in but not whether you are allowed to see this particular record, input that is trusted instead of validated, secrets hard-coded or shipped to the browser, no rate limiting, no error handling beyond a generic catch. If you have audited one vibe-coded app you can guess the findings of the next one before you open it.

Worked example, the canonical one. A booking app has a clean login. Once you are in, the app fetches your bookings from /api/bookings/1234. Change 1234 to 1235 and you see someone else’s booking, their name, their address, their payment reference. The login screen made it feel secure, so nobody checked. The server never verified that the logged-in user owns booking 1235. This is called a broken-object-level-authorization bug, and it is the single most common serious defect in vibe-coded software, because the demo never exercises the case of one user reaching for another user’s data.

The honest trade-off: vibe-coded software is genuinely cheaper and faster to produce, and for a prototype that is exactly right. The cost is that the savings are front-loaded and the bill arrives later, as a breach, a GDPR incident, or a rewrite. Calling it out is not anti-AI snobbery. The code can be perfectly good once the missing 10% is added back. The mistake is shipping the 90% and assuming the demo proved the other 10% exists.

Wavect audits vibe-coded software for exactly this profile under Software Quality Assurance. We read the authorization paths first, because that is where the worst and most common bug lives, then input validation, secrets, and error handling, then we add the regression suite and CI/CD gate that stops the next change from reopening the hole. It is not a rewrite. It is making the technical debt the tools left behind visible, then paying down the part that can hurt you.

// FAQ

FAQs

A working login screen with no server-side authorization. The app checks that you are logged in, but not that you are allowed to see the specific record you requested. Change one ID in the URL and you read another user’s data. The demo never tests this, so nobody catches it until it is exploited.
Read the authorization paths. If logging in is the only access check and individual records are not verified against the current user, it was almost certainly vibe-coded. Other tells: secrets in the client bundle, no input validation, a generic catch-all error handler, and no test suite worth the name.
No. It means nobody read the security-critical paths. The generated code is often clean and reasonable on the happy path. The problem is the missing 10%, the auth, validation, and secrets handling that the prompt never asked for. Add that back and the same codebase can be production-ready.