When an AI-built app fails a security audit, triage by reachability rather than by the scanner’s severity label. Close anything a stranger can reach without logging in today, then anything any signed-up user can reach this week. Most findings in AI-generated apps are missing authorisation rather than exotic exploits.
1. What the scans keep finding
2. Triage order: reachability beats severity
3. Fix today: the three that cannot wait
4. Fix this week: the ones any user can reach
5. Fix this month: hardening and hygiene
6. Patch it, or start again?
7. If real user data has been through it
8. How to not be here again
9. How the Vibe Check works
10. Frequently asked questions
There is now a great deal written about how often AI-generated applications contain security flaws. There is almost nothing written about the thing that actually matters to a founder: it is Tuesday morning, a scan has come back with forty findings, the app is live, and someone has to decide what to do in what order. This is about that.
About Wow Labz. Wow Labz is an AI-native custom software development company based in Bengaluru, India. Since 2011 it has shipped 400+ products across 15+ years, won 30+ awards, and touched 100M+ lives. It holds a 5.0 rating across 23 verified Clutch reviews and is ISO 27001 certified.
What the scans keep finding
The published research is unusually consistent, and the pattern is more useful than the headline percentages.
A passive scan of 30,998 live applications built with AI coding tools, reported in vibe-eval’s August 2026 monthly, found that 57% of reachable Supabase-backed apps, 2,096 of 3,680, allowed unauthenticated table reads. The same report cites a Symbiotic Security study of 1,072 live apps finding at least one vulnerability in 98% of them, and 42.3 vulnerabilities per AI-assisted repository against 9.6 for human-only repositories.
The Cloud Security Alliance’s research note on AI-generated code reports Veracode testing more than 100 language models on security-sensitive coding tasks, with 45% of generated samples introducing OWASP Top 10 vulnerabilities, and a pass rate that has not improved across testing cycles from 2025 into early 2026.
The most instructive number is a comparison. securityscanner.dev’s Q2 2026 report scanned 23,764 deployed apps and found 7% of Lovable and Bolt applications had databases anyone could read. Scanned as a control group, Y Combinator backed companies came in at 0%. Same tools, same era, completely different outcome.
That control group is the whole point. These are not failures of AI code generation in some inherent sense. They are failures of configuration and review, by teams who did not know what to check. Which means they are fixable, usually quickly, and usually without throwing the product away.
Triage order: reachability beats severity
Scanners rank findings by severity. That ranking is close to useless on the first morning, because it does not tell you what an attacker can actually do right now. Sort by reachability instead: how much access does someone need before this becomes their problem rather than a theoretical one.
The same ordering in table form:
| Tier | Who can reach it | Typical findings | Timeframe |
|---|---|---|---|
| Tier 1 | Anyone, no login needed | Database readable without auth, secrets in client-side code, admin routes with no auth check | Today. Take the app offline if you cannot. |
| Tier 2 | Any signed-up user | Object references not scoped, authorisation enforced in the browser, write access where read was intended | This week |
| Tier 3 | Needs effort, luck or insider access | Dependency vulnerabilities, missing rate limits and headers, no logging or audit trail | This month |
The ordering rule, stated plainly. A medium-rated flaw a stranger can hit today outranks a critical one that needs an admin account nobody has. Reachability beats severity.
Fix today: the three that cannot wait
Database readable without authentication
This is the single most common serious finding in AI-built applications, and it has one usual cause: row level security was never enabled, or a policy was written that evaluates to true for everyone. The AI built the feature and nobody prompted it for the policy.
The fix is to enable row level security on every table holding user data, then write an explicit policy per table scoping rows to the authenticated user. Verify by querying the API with an anonymous key and confirming you get nothing back. Do not verify by logging into the app, which proves only that logged-in access works.
Secrets in client-side code
API keys, database credentials and service tokens bundled into the JavaScript the browser downloads. Anyone can read them with developer tools open. Rotate every exposed key first, because the old one may already be in someone’s collection, then move the calls that needed it behind a server-side route.
A service key in a browser bundle is worse than a readable database, because it frequently bypasses row level security entirely.
Admin routes with no authorisation check
Internal tools, dashboards and data exports reachable on a public URL because the route exists and nothing checks who is calling it. Hiding the link is not a control. Add a server-side authorisation check on the route itself, not on the component that renders it.
Fix this week: the ones any user can reach
These require an account, which most attackers can create in thirty seconds. Treat the account requirement as a speed bump rather than a control.
-
Object references not scoped. An identifier in a URL or request that is not checked against the caller. Change the number, see somebody else’s record. Fix by scoping every lookup to the authenticated user at the data layer rather than filtering in the interface.
-
Authorisation in the browser. Role checks implemented in the front end, where the client simply chooses not to run them. Anything the browser enforces, the browser can skip. Move the check server-side.
-
Write access where read was intended. Policies that permit insert, update or delete where only read was intended. Common when a policy was copied between tables. Audit each one against what that table actually needs.
Fix this month: hardening and hygiene
-
Dependency vulnerabilities. Outdated packages, and occasionally packages that do not exist because the model invented a plausible name. Run a dependency audit and check that every import resolves to something real and maintained.
-
Missing rate limits and headers. Rate limiting, CORS configuration, content security policy, cookie flags. Individually minor, collectively the difference between an annoying attack and a successful one.
-
No logging or audit trail. The finding that matters most after an incident rather than before one. Without logs you cannot answer the only question that will be asked, which is whether anyone already took the data.
Patch it, or start again?
The question everyone asks on day two. Four questions answer it.
| Question | Patch if | Rebuild if |
|---|---|---|
| Can you describe what the app does, screen by screen? | Yes, and someone can explain the data model | Nobody can, so you would be guessing at the system |
| Is authorisation in one place or scattered through the UI? | One place, enforced at the data layer | Scattered across components, so fixes will miss some |
| Is there any test that proves a fix worked? | Yes | No, in which case write tests before patching anything |
| Has real user data been through it? | Handle the exposure either way | Handle the exposure either way. A rebuild does not undo it. |
Two or more answers in the right-hand column and patching will cost more than rebuilding, because each fix is unverified and the next change can silently reopen what you just closed.
The usual outcome, though, is neither extreme. Keep the product and rebuild the data and authorisation layer underneath it. The screens are rarely the problem and they are the part the AI genuinely got right.
If real user data has been through it
This sits outside the engineering work and gets handled in parallel, not afterwards.
-
Determine whether anything was actually accessed. Pull whatever access logs exist and establish whether the exposure was used. Frequently the honest answer is that you cannot tell, and that is itself a finding worth recording.
-
Rotate every exposed credential. Every key that appeared in client code or a public repository, on the assumption it is already compromised.
-
Take advice on disclosure. Obligations vary by jurisdiction and by the kind of data involved, and several regimes have short reporting windows. Get advice rather than guessing, and do it on day one.
-
Write down the timeline. A short internal note covering what was exposed, for how long, what you did and when. You will need it, and writing it later from memory is considerably harder.
This is general guidance and not legal advice. Breach notification duties depend on your jurisdiction, your sector and the data involved, and a qualified adviser is better placed to determine them than we are.
How to not be here again
The control group in that scan is the useful model. Those teams were not writing code by hand. They were checking different things.
-
Make anonymous access a release check. Before shipping anything, confirm every table holding user data denies anonymous access. One query with an anonymous key answers it.
-
Prompt for policy, not just function. A model generating a feature will not add an authorisation policy unless asked. Ask, every time, and treat the policy as part of the feature rather than a follow-up.
-
Write the two tests that matter. Two tests per table: an anonymous request returns nothing, and a second user’s request returns nothing. These are cheap to write and they catch the majority of what scanners find.
-
Have someone review the data layer. Not a full audit every time, but one person who checks the data layer before each release. The teams that avoid this entire article have one.
How the Vibe Check works
We run the Vibe Check because this problem is common, fast to diagnose and genuinely alarming when founders see their own results. Senior engineers audit an AI-built application in 72 hours and hand back a signed report with findings ordered the way this article describes, plus a fixed-price plan for closing them. It is free, it starts with an NDA, and access is read-only.
What it is not is a scanner report with a logo on it. Automated scanning is part of it, and the part that matters is a person deciding which findings are reachable in your specific deployment, which are noise, and what the shortest route to safe actually is.
Where remediation turns into rebuilding, that is ordinary engineering work and our custom software development guide covers how we scope it. The oversight model that prevents this class of problem in the first place is in our guide to human-in-the-loop AI.
Built with AI and not sure what is exposed?
Finding out takes 72 hours and costs nothing. Senior engineers audit the app, hand you a signed report with findings ordered by reachability, and tell you plainly which are urgent and which can wait. NDA first, read-only access, twenty founders a week. Get a free Vibe Check and you will at least know where you stand.
Frequently asked questions
What should I fix first after an AI-built app fails a security audit?
Anything reachable without logging in: a database readable without authentication, secrets in client-side code, and admin routes with no authorisation check. Sort by reachability rather than the scanner’s severity label, because a medium-rated flaw a stranger can hit today matters more than a critical one requiring an admin account nobody has.
Why do AI-generated apps have security problems?
Mostly missing authorisation rather than exotic exploits. A model asked to build a feature will build the feature, and will not add an access policy unless prompted. Published scans of live AI-built applications consistently find unauthenticated database reads as the most common serious issue, caused by row level security being off or misconfigured.
Is vibe coding safe for production?
It depends entirely on what gets checked before release. A Q2 2026 scan of 23,764 deployed apps found 7% of those built on popular AI tools had openly readable databases, while Y Combinator backed companies scanned as a control group came in at 0%. Same tools, different review practices. The tool is not the determining factor.
Should I patch my AI-built app or rebuild it?
Patch if someone can explain the data model, authorisation sits in one place, and tests exist to prove a fix worked. Rebuild if two or more of those are missing. The common middle path is keeping the product and rebuilding the data and authorisation layer underneath it, since the screens are usually fine.
How do I check if my app’s database is publicly readable?
Query your API with an anonymous or public key, from outside the application, and see what comes back. If you get rows, anyone can. Do not test by logging into the app, which only proves that authenticated access works. Run this check on every table holding user data before each release.
What do I do if user data was already exposed?
Establish from access logs whether anything was taken, rotate every exposed credential on the assumption it is compromised, take advice on disclosure obligations, and write down the timeline while it is fresh. Notification duties vary by jurisdiction and data type, so get qualified advice rather than guessing.
