The honest answer is that nobody can tell you without looking, and anyone who says otherwise is selling something. “Vibe-coded” covers apps built in a browser by describing them, apps built by an agent typing into your own repository, and everything in between. Those fail in genuinely different ways, and a checklist written for one is wrong for another.
What follows is the part that is shared, the part that is not, and the one test worth doing before anything else.
The split that decides which advice applies to you
There are two kinds of tool and the difference matters more than the brand.
Platform builders — Lovable, Bolt, Base44, v0 — give you a database, a login system and hosting as part of the product. That is a real head start: you did not hand-roll authentication, so you did not hand-roll an authentication bug. The failures move to configuration. The permission rule you never opened, the storage bucket left public, the preview URL pointed at the production database. There is often no code to read, which means no amount of reading code will find the problem.
Agents in your repository — Cursor, Claude Code, Codex, Copilot — ship no database, no login system and no framework. Whatever your project already contained, plus whatever the model wrote this session, is your stack. Nothing is enforcing rules underneath, so the check that stops one customer reading another’s data exists only if the agent wrote it. Here the code is the thing to read, and nobody can tell you what to fix without opening your repository.
If you are not sure which you have, the test is simple: can you open the files and read them? If yes, you are in the second group.
The three that are true of almost every AI-built app
1. Nobody checked who is asking. An endpoint takes an id — an order, a document, a profile — looks it up and returns it. What is missing is the line that also asks whether that id belongs to the person requesting it. This is the most common serious bug in AI-built software, and it is invisible in testing, because in testing you are always the owner of everything you look at.
2. A secret ended up somewhere public. In front-end code the browser downloads, in a config file, in a chat window, or committed to a repository in March and deleted in April — where it still sits, in March’s commit. Publishable keys are designed to be public; secret keys and service keys are not, and they look similar enough that they get swapped.
3. Nothing has an upper bound. No rate limit on an endpoint that costs money, no ceiling on what a model call can return, no spend limit at the provider. This one is a bill rather than a breach, and it arrives just as fast.
Those three are worth checking no matter which tool you used, because none of them is anyone’s fault in particular. A model writes the feature you described. It does not stop to wonder whether a stranger could call it, because you did not ask.
The ten-minute test, and why it comes first
Before any scanner, any checklist and any of the advice above, do this. It needs no tools and it finds the problem that would hurt you most.
Sign up twice, with two different email addresses, in two different browsers. In account A, create something — an order, a note, a document. Copy the address of the page that shows it, or the request your app makes to load it. Now, signed in as account B, open that address and change the id in it.
If account B can see account A’s data, stop and fix that before anything else. It is the failure that exposes every customer at once, it is the hardest to walk back after launch, and it is the one your users will otherwise find for you.
Then do the same signed out, in a private window, and see what loads before any login at all.
What a scanner can and cannot see
If you are looking at tools, the useful question is not which is best but what each is able to look at. There are three kinds and they see different things.
Something that scans your live URL checks what is visible from outside: security headers, exposed files, cookie settings, an open CORS policy. Fast, needs nothing from you, and it cannot see your authorization logic at all, because that logic never appears in a response to a stranger.
Something that reads your code can follow the path from a request to a database query and notice the missing ownership check — the thing the URL scanner structurally cannot reach. The cost is that it needs your source, which is a real decision to make rather than a detail.
A platform’s own built-in scan knows things neither of the others can, because it can read your actual permission settings rather than guessing at them. It also cannot tell you whether those settings are right for your product — whether one therapist should be able to read another’s notes is a question about your business, not your configuration.
None of the three is complete, which is the honest thing to say about all of them. What matters is knowing which blind spot you are accepting.
One thing to demand of anything you run
Ask what it did not check.
A list of problems with no denominator is a feeling rather than a result. Twelve findings could mean twelve problems out of twelve checks, or twelve out of three hundred with the rest never run. Those are completely different situations and they look identical on the screen. A tool that will not tell you what it skipped, and why, is asking you to mistake its limits for your safety.
The same applies to a clean result. “Nothing found” is only good news if you know how much was looked at.
Now the tool you actually used
The general answers above stop being useful fairly quickly, because the specifics are where the problems are. Each of these goes into what that particular tool does and does not do for you:
Platform builders: Lovable · Bolt · Base44 · v0
Agents in your repository: Cursor · Claude Code · Codex · Replit
And if your app sits on Supabase, as a great many do, the Supabase checklist covers the database layer underneath whichever tool you used.
If you would rather work through the whole surface in order, the pre-launch checklist is the long version — security, but also the legal, operational and billing things that break a launch without anybody being hacked.
Written September 2026. Tools change monthly; the three shared failures and the ten-minute test have not changed in the two years people have been building this way.
Questions people ask
Is my vibe-coded app secure?
It depends which tool built it, because platform builders like Lovable and Base44 fail through configuration you never opened, while agents like Cursor and Claude Code fail through code that was never written. Three problems are shared by almost all of them: no check on who is asking, a secret somewhere public, and no upper bound on anything that costs money.
How do I check if my AI-built app is safe before launch?
Start with one test that needs no tools. Sign up twice with two email addresses in two browsers, create a record in account A, then try to open it as account B by changing the id in the URL. If B can see A's data, fix that before anything else - it exposes every customer at once and is the hardest thing to walk back after launch.
Can a security scanner find everything in a vibe-coded app?
No, and the useful question is which blind spot you are accepting. A scanner that checks your live URL cannot see authorization logic, because that logic never appears in a response to a stranger. One that reads your code can follow that path but needs your source. A platform's built-in scan reads your real settings but cannot know whether those settings are right for your product.
What is the most common security problem in AI-generated code?
An endpoint that looks up a record by id and returns it without checking whether that record belongs to the person asking. It is invisible during testing because you are always the owner of everything you look at, and it is the failure that exposes every customer at once rather than one.
Why do AI coding tools produce these problems?
Not because they write bad code - on the narrow question you asked, a model often writes better code than a tired human would. It is that nobody asked the questions that were not in the prompt. A model builds the feature you described and does not stop to wonder whether a stranger could call it, whether the migration can be undone, or whether anyone wrote a privacy policy.