AI-built app database exposure scan, October 2026

Plain-English methodology

What was sampled, when, and how

Question

How often could a person who was not logged in read a database table in a live, AI-built app using only the Supabase anon key that the app already publishes to every visitor?

Sample and dates

The sample contained 500 live AI-built apps built with Lovable, Bolt, and base44. Candidate hosts came from certificate-transparency logs and Wayback Machine archives of the builders' deployment domains, about 5,300 unique hosts, which a liveness filter reduced to 4,512 reachable apps. A deterministic stratified sample of 500 was drawn across the three builders so no single builder dominated the headline. The observations were collected in October 2026, and 497 of the 500 were reachable at scan time. This was a convenience sample of publicly discoverable deployments, not a random sample of all AI-built software.

What was measured

First, the scan recorded whether each app used Supabase. For the 177 apps that did, it measured whether at least one table returned a row to an unauthenticated read made with the public anon key. A second classification recorded whether any readable table was clearly sensitive rather than intentionally public.

Sensitive categories included user and profile records, sessions, subscriptions, private chat or support messages, audit logs, employee records, bookings, and regulated-operation records. Public catalogs, blog posts, and feature-flag tables were not counted as sensitive.

How the measurement was made

1. The public JavaScript bundle delivered by each live app was inspected.
2. When a Supabase project URL and anon key were present, one unauthenticated REST GET request was made per table with limit=1.
3. An app was counted once in the readable-table measure if any tested table returned a row. It was counted once in the sensitive-table measure if any such table was clearly non-public.

No write requests were made. No authenticated routes or service-role credentials were used. No app was named, and no row contents or app-level results were retained for publication. Only the aggregate counts on this page were kept.

Interpretation and limitations

• The result describes this 500-app convenience sample and should not be projected to all AI-built apps.
• The 323 non-Supabase apps were not tested for equivalent access-control failures on other backend platforms in this scan.
• A one-row read establishes that anonymous data access was possible at scan time; it does not measure the total number of exposed rows.
• An empty table can produce no row even if its access policy is permissive, so this method may undercount readable tables.
• Apps may have changed their database policies since the October 2026 observation.
• An earlier June 2026 wave scanned 66 apps and found a higher 40.6% readable-table rate. That was a smaller, earlier sample. This larger wave is more representative, and the lower rate reflects both the broader sample and tightening builder defaults.