What 1,236 AI-built app scans revealed.

What the totals mean—and what they do not

The 1,236 apps and 12,205 findings are cumulative operational totals from scanning tooling used by our team. They show what repeatedly turns up in the apps people bring us; they are not a prevalence estimate for every AI-built app on the internet.

Submissions are self-selected, scan coverage can vary and a scan can only report what its checks can observe. We publish the denominator because raw finding counts without it are easy to overstate. For a frozen cohort with dates, methodology and explicit limitations, use the linked 2026 Vibe App Scanner security report.

Broken access control leads by a wide margin

The most common serious finding, by far, is broken access control: data that anyone can reach because no rule decides who may. On Supabase apps it is a table with no row-level security behind the public anon key. On Firebase apps it is a database left in test mode, wide open from the root. In both cases the public key that is meant to be shared reaches data that is not, and the app behaves normally the entire time.

The exposures this produces are not abstract. A lending product with a table of full bank account numbers readable by anyone with the public key. A health app exposing patient access codes and payment codes the same way. An education platform exposing its users' stored Google authentication tokens, enough to access those accounts elsewhere. Private in intent, public in fact.

Writable data and privileged functions

Reading is the milder version. In many apps the same tables could also be written to by unauthenticated strangers: tables named orders, payments and transactions where an outsider could insert a forged record the app would treat as real. In one app, a table named security_events, the audit log meant to record suspicious activity, was itself writable by anyone, so an attacker could overwrite the record of their own actions.

The same failure extends to database functions. We have found privileged functions left callable with the public key, including ones named generate_license_key and generate_transfer_token. A stranger could call these directly and have the database mint a valid licence or transfer token for them.

Exposed secrets and misconfiguration

Beyond access control, the recurring findings are secrets that should never have shipped to the browser, and platform settings left at their wide-open defaults. Storage buckets open to anonymous uploads, so a stranger could place files of their choosing into the app's own storage. Service-role keys and other true secrets sitting in client code where anyone can read them. None of it visible from the outside; all of it visible to someone using the public key the way an attacker would.

What ‘no findings’ means

Twenty-one of the 1,236 apps returned no findings from the checks that ran. That is encouraging, but it is not a security certificate: automated checks cannot prove that product-specific permissions and business logic are correct. It means the tooling did not observe one of the covered failures, not that no vulnerability could exist.

The strongest apps had deliberate access rules and had tested those rules with more than one account. A code audit adds the human review needed to check whether each user can reach only the records, files and actions the product intends.