We built 24 apps on Lovable, Replit and Manus and scanned all of them. 561 vulnerabilities came back, and they clustered into a small number of repeating patterns. If you've generated an app and you're about to put real users on it, these are the checks worth doing first, roughly in order of how quickly you can do them.
Ten minutes, browser and terminal
Look for keys in the client bundle. Open your deployed site, view source, and search the JavaScript for key, secret, token and sk_. Anything an AI builder needed to make the preview show real data may well have been put somewhere the browser can read it. If your database credentials are in there, that's the first thing to fix and everything else can wait.
Check your CORS setting. Open the network tab, look at a response header for Access-Control-Allow-Origin. If it says *, that was set so the preview pane would render and it should not have survived to production. Set it to your actual domain.
Try to log in badly, twenty times in a row. If nothing slows you down or locks you out, there's no rate limiting. Same test on password reset and any OTP endpoint. Auth routes without throttling are the cheapest thing in the world to attack and one of the most common things we found missing.
Send a request with someone else's ID. Log in as one user, find a request that fetches your own data, change the ID in it to another user's, and send it again. If you get their data back, you have a broken object-level authorisation problem. This is the single most consequential pattern we saw: the auth check passes, so the code looks correct, but the query never filters by who's actually asking.
The one you can't spot-check
That last test tells you about one endpoint. It says nothing about the other eighty.
Broken object-level auth is a per-query problem, and a generated app of any size has a lot of queries. Checking them by hand means reading every database call and asking whether it constrains by the authenticated user, which is fine for a weekend project and unrealistic for anything real.
It's also the pattern that pattern-matching scanners handle worst, because the vulnerable code is syntactically identical to the safe version. The only difference is a where clause that isn't there. In our RealVuln benchmark, rule-based scanners reached a best F3 of 14.4 with recall at or below 0.19 across 66 hand-labelled repositories, and this class of bug is a large part of why.
If you're on Supabase
Lovable, Replit and several others use Supabase by default, and Supabase exposes tables over a REST API as soon as they're created. Without row-level security policies configured, that API is open.
This has already caused real incidents. CVE-2025-48757 was assigned after researchers found large numbers of Lovable-built apps exposing user data through exactly this route. If your app has a Supabase backend, check that RLS is enabled on every table with user data in it, not just the ones you remember creating.
Do this before you do any of it
Most of what we found traces back to the scaffolding rather than the features. The keys, the CORS wildcard, the missing throttle, those came from the template, not from anything you asked for.
So if you're going to build more than one thing on a platform, it's worth fixing the starting point once rather than auditing every app afterwards. It's the same handful of settings each time.
Where this stops being a checklist
The list above is what you can reasonably do by hand on one application. It doesn't scale, and it's not meant to. Once you're generating faster than you can read, the checking has to be automatic, and it has to produce a fix rather than another finding. Which is the problem Kolega exists to solve.
Links to add on publish
Answer: Is AI-generated code less secure than human-written code?
Blog: Vibe Coded & Vulnerable
Glossary: BOLA
RealVuln,
https://realvuln.kolega.dev/Up-link:
/use-cases/ai-generated-code-security