Research, archived edition
Vibe Coding Security Index: Q3 2026
73.9% of the 1,246 AI-built apps Ubserve scanned from 1 July 2026 to 30 September 2026 had at least one high or critical security finding.
- Published:
- 6 October 2026
- Data as of:
- 6 October 2026
- Sample:
- 1,246 apps, 1,829 completed scans
Key findings
- In Q3 2026, 921 of 1,246 AI-built apps scanned by Ubserve, or 73.9%, had at least one high or critical security finding.
- 5.0% of those 1,246 apps, meaning 62 apps, had at least one critical finding in Q3 2026.
- Missing security headers was the most common high-severity finding in Q3 2026, affecting 835 of the 1,246 apps Ubserve scanned, or 67.0%.
- Of the 217 apps where Ubserve found a Supabase project URL and anon key in the public frontend bundle in Q3 2026, 34.6% had at least one database table that answered a request carrying no credentials.
- The table most often readable without authentication was profiles, open on 49 of the 217 Supabase-backed apps Ubserve scanned in Q3 2026.
- Session tokens kept in browser storage affected 7.7% of the 1,246 apps Ubserve scanned in Q3 2026, which is 96 apps and the second most common high-severity finding.
- The median app Ubserve scanned in Q3 2026 carried 12 findings of any severity, and 26.1% of the 1,246 apps had no high or critical finding at all.
Why this edition has no quarter-on-quarter comparison
This is the first edition, so there is no comparison to draw. Ubserve scanned 1,246 apps in Q3 2026 against 197 in the quarter before it, and a sample that small cannot support a claim about direction. The first real comparison will appear in the Q4 2026 edition.
Within the quarter the sample grew month by month, shown below. Read this as how the sample was composed, not as a trend in app security: the months differ in how many apps were scanned, not in any measured change to the apps themselves.
| Month | Apps scanned |
|---|---|
| July 2026 | 350 |
| August 2026 | 233 |
| September 2026 | 680 |
What we found, by category
The table ranks categories by the share of apps carrying at least one high or critical finding in that category. Each app counts once per category, however many findings it had. Categories affecting fewer than 30 apps are shown with a sample size and no percentage.
| Category | Apps affected | Share of 1,246 apps |
|---|---|---|
| Missing security headers | 835 | 67.0% |
| Session tokens in browser storage | 96 | 7.7% |
| Exposed keys and secrets | 92 | 7.4% |
| Insecure cookie flags | 64 | 5.1% |
| Vulnerable dependencies | 25 | Insufficient sample |
| Permissive CORS | 23 | Insufficient sample |
| Endpoints answering without authentication | 17 | Insufficient sample |
| Database readable without authentication | 15 | Insufficient sample |
| Domain and certificate hygiene | 6 | Insufficient sample |
| Files served that should not be public | 5 | Insufficient sample |
Missing security headers: 67.0% of apps (835 of 1,246)
A security header is a line in the server response that tells the browser what to allow on the page, covering things like which scripts may run, whether the page may be framed by another site, and whether the browser should insist on HTTPS.
AI tools generate application code, not deployment configuration. Headers live in a host config file or middleware that nothing in the prompt asked for, so they are simply never written, and the app works perfectly without them.
This is a configuration change rather than a code change, usually a few lines in your framework or host config. To see what your site currently sends and what is missing, run our free security headers checker.
Session tokens in browser storage: 7.7% of apps (96 of 1,246)
The app keeps a session token, usually a JWT, in localStorage or sessionStorage, where any JavaScript running on the page can read it.
Storing a token in localStorage is the shortest path to a working login in a generated frontend, and it survives a page refresh with no server work. Cookie-based sessions need server involvement that a single-file prototype avoids.
Move the session to a cookie the server sets with HttpOnly, Secure and SameSite, so page scripts cannot read it. If you must keep a token in the browser, keep its lifetime short and never store a refresh token beside it.
Exposed keys and secrets: 7.4% of apps (92 of 1,246)
A credential is readable in what the app serves to the public, most often inside the JavaScript bundle. In Q3 the most common single case was a Google Maps API key, followed by Supabase keys.
An AI tool cannot tell which keys are safe in a browser and which are not, and the quickest way to make a feature work is to put the key where the calling code is. Some keys genuinely belong in the client, which makes the mistake harder to spot.
Decide per key whether it belongs in the browser at all, move the rest behind a server route, then rotate anything that was ever public. Our guide on what to do after a key leaks covers the order that limits the damage, because rotating before you have replaced every use takes the app down.
Insecure cookie flags: 5.1% of apps (64 of 1,246)
A cookie is set without the flags that restrict how it can be used, most often a missing HttpOnly, which leaves the cookie readable by JavaScript on the page.
Cookie flags are set where the cookie is created, often in generated auth glue code that was written to work rather than to harden. Nothing breaks when they are missing, so no error ever surfaces them.
Set HttpOnly on any cookie the browser does not need to read, Secure everywhere, and SameSite to Lax or Strict unless a cross-site flow genuinely needs None.
6 further categories appeared on fewer than 30 of the 1,246 apps, so no rate is published for them: vulnerable dependencies (25 apps), permissive cors (23 apps), endpoints answering without authentication (17 apps), database readable without authentication (15 apps), domain and certificate hygiene (6 apps), files served that should not be public (5 apps). The full finding-level counts are in the CSV.
What the critical findings actually were
62 of the 1,246 apps Ubserve scanned in Q3 2026carried at least one critical finding. Counts are small, so these are counts rather than rates, and the table below shows how many of those 62 apps each critical finding appeared on.
| Critical finding | Apps |
|---|---|
| A Supabase table returned rows to an unauthenticated request | 14 |
| CORS reflected any origin while allowing credentials | 13 |
| A GraphQL mutation ran without an authentication check | 5 |
| A Supabase service-role key was present in what the app serves | 4 |
| CORS used a wildcard origin while allowing credentials | 4 |
The two most common critical findings are both access control rather than code quality: a database table that answers anyone, and a CORS configuration that lets any website read authenticated responses. If you want to check the second one on your own app, our CORS tester shows which origins your API will answer and whether it allows credentials.
Supabase-backed apps
Ubserve found a Supabase project URL and anon key in the public frontend of 217 of the 1,246 apps scanned in Q3 2026, and 34.6% of those 217 apps had at least one table that returned rows to a request carrying no credentials. That is 75 apps where a stranger with a browser console could read data.
This is the one platform split in this edition, and it is the only one we can make honestly, because the evidence comes from the app itself rather than from its domain name. Which tables were open follows a clear pattern, and it is the tables holding people and money.
| Table name | Apps where it answered |
|---|---|
| profiles | 49 |
| users | 17 |
| subscriptions | 16 |
| orders | 13 |
| payments | 10 |
| transactions | 8 |
| customers | 7 |
| invoices | 7 |
| accounts | 2 |
Row Level Security is off by default on a new Supabase table, and an AI tool that scaffolds a schema has no reason to turn it on. For the wider picture of how these apps fail, see our analysis of Supabase app security. If your policies are written but data still leaks or queries return nothing, the usual causes are in why Supabase RLS stops working.
Why there is no Vercel or Netlify breakdown
A hosting platform cannot be read reliably from a URL. An app on Vercel with its own domain looks like any other host, so a cohort built from vercel.app hostnames would measure apps still on a default or preview domain rather than Vercel-hosted apps in general. For this edition, apps on platform subdomains are counted as ordinary apps, and no hosting split is published.
Where we could identify a builder or host by subdomain, the samples were too small to report rates anyway: 21 apps on a netlify.app hostname, 17 on a Lovable domain and 9 on a Firebase domain, all below the 30-app floor.
Methodology
Sample. 1,246 apps, from 1,829 completed Ubserve scans from 1 July 2026 to 30 September 2026. Data pulled 6 October 2026. Ubserve has scanned 1,419 apps across 2,360 completed scans since 23 March 2026; this edition uses only the Q3 2026 window.
These are apps whose owners chose to run a scan. It is not a random sample of the web, and it is not a random sample of AI-built apps. People tend to scan when they are about to ship or when they already suspect a problem, which plausibly pushes the failure rate up, while anyone who never heard of Ubserve is absent entirely. Read the numbers as the shape of problems in AI-built apps that someone cared enough to check, not as a measurement of every vibe-coded app in existence.
Unit of analysis. One app, not one scan. An app is one hostname, lowercased, with a leading www. removed, so www.example.com and example.com are the same app. Where an app was scanned more than once in the quarter, only its most recent scan inside the window is used, so the report describes the latest state we observed. An app scanned again in a later quarter will appear in that edition too.
Severity. Ubserve classifies each finding as critical, high, medium or low, per finding, at the time of the scan. An app counts as having a critical finding when at least one of its findings is critical, and as high or critical when at least one is high or critical. The same kind of finding can be scored differently on different apps depending on what the scan could prove, so severity is always read per finding rather than assumed from its type.
What a scan checks. The scan requests the app the way an outsider would: it reads the served JavaScript and response headers, tests CORS and cookie behaviour, looks for files that should not be public, and, where the app ships a Supabase project URL and anon key, tries ordinary reads against common table names with that public key. The full list is on the page describing what Ubserve checks. No credentials are used, nothing is modified, and no exploit is run beyond an unauthenticated read.
Categories. Findings are grouped from their machine type into the reader-facing categories in the table above, using a fixed map published in the script that produced this report. The per-type counts behind every category are in the CSV, so the grouping can be checked rather than taken on trust.
Reproducibility. Every number here is read from a single JSON file written by scripts/index-q3-2026.ts, which queries the scan database directly. The page contains no hand-typed figures, and a check in the repository fails if a rendered number differs from that file.
Limitations
- Self-selected sample. These are apps someone chose to scan, so the rates are not generalisable to all AI-built apps.
- We cannot attribute an app to the tool that built it. Nothing in a deployed app reliably says it came from Cursor, Lovable, Bolt or a human, so no per-builder rates appear here.
- Hosting platform is not detectable from a URL once an app uses a custom domain, which is why there is no hosting breakdown.
- Supabase table checks only run when the app ships a project URL and anon key in its frontend, so the 217 Supabase-backed apps are the ones we could test, not every Supabase app scanned.
- Table coverage is limited to common names the scan tries, so an open table with an unusual name would not be counted.
- Missing headers are counted as reported at scan time. A header added later is not reflected until the app is scanned again.
- One quarter is a baseline, not a trend. Nothing here supports a claim about whether AI-built app security is improving or worsening.
Frequently asked questions
What percentage of vibe-coded apps are insecure?
In Q3 2026, 73.9% of the 1,246 AI-built apps Ubserve scanned had at least one high or critical finding, and 5.0% had a critical one. These are apps whose owners chose to scan them, so treat the figure as the shape of the problem rather than a census. See key findings.
What is the most common vulnerability in AI-generated apps?
Missing security headers, found on 835 of the 1,246 apps Ubserve scanned in Q3 2026, or 67.0%. It is a deployment configuration gap rather than a coding mistake, which is why AI tools leave it out: the app works without it. See findings by category.
Is Lovable, Bolt or Cursor code secure?
This report cannot answer that, and no honest reading of the data can. Nothing in a deployed app reliably identifies the tool that wrote it, so Ubserve publishes no per-builder rates. What the Q3 2026 data shows is that 73.9% of 1,246 AI-built apps shipped with a high or critical finding regardless of origin. See limitations.
How often is a Supabase database left open in an AI-built app?
Of the 217 apps where Ubserve found a Supabase project URL and anon key in the frontend in Q3 2026, 34.6% had at least one table that returned rows to a request with no credentials. The table left open most often was profiles, on 49 apps. See Supabase-backed apps.
How many findings does a typical AI-built app have?
The median app Ubserve scanned in Q3 2026 had 12 findings of any severity and a mean of 15.1. Most are medium or low. Counting only what we would act on before launch, the median app had 1 high or critical finding, across 1,246 apps.
Are any AI-built apps actually secure?
Yes. 26.1% of the 1,246 apps Ubserve scanned in Q3 2026, meaning 325 apps, had no high or critical finding at all. A clean result is not a guarantee of safety, because the scan tests what is reachable from outside rather than reviewing source.
Is vibe-coded app security getting better or worse?
The data cannot say yet. Q3 2026 is the first edition of this index, and the quarter before it covered only 197 apps, too few to compare against 1,246. The first quarter-on-quarter comparison arrives in the Q4 2026 edition, using the same definitions. See why there is no comparison.
How does Ubserve collect this data?
From its own production scans. Ubserve requests an app the way an outsider would, reading served JavaScript, response headers, cookie behaviour and CORS, and testing unauthenticated reads where the app ships a Supabase anon key. No credentials are used and nothing is modified. Q3 2026 covers 1,829 completed scans of 1,246 apps. See methodology.
How to cite this report
Please cite the dated edition rather than the hub, so the figures you quote keep resolving to the version you read.
Ubserve, "Vibe Coding Security Index: Q3 2026", 6 October 2026. https://ubserve.com/research/vibe-coding-security-index/2026-q3
Permalink for this edition: https://ubserve.com/research/vibe-coding-security-index/2026-q3
Download the data
Both files are aggregates only. They contain no app URLs, hostnames, customer names or finding values, and are published under CC BY 4.0, so you may reuse them with attribution.
- Headline metrics (CSV): the sample size and each top-level rate for Q3 2026.
- Findings by type (CSV): every finding type, its category, the severities observed, and how many apps it affected.
Edition history
| Edition | Published | Apps | Note |
|---|---|---|---|
| Q3 2026 | 6 October 2026 | 1,246 | First edition. Baseline quarter, no prior-quarter comparison. |
This is the permanent copy of the Q3 2026 edition. The current edition may be newer.
Check your own app
The scan behind these numbers is the same one you can run on your own URL, and it takes about a minute. If you would rather work through it by hand first, start with the pre-deploy security checklist.
Run the free scan