We asked 4,740 live AI-built apps for their private data with no login. 261 answered.

Part 1: live apps

Over two days in August 2026 we took 4,740 deployed apps from public launch directories, Show HN and builder galleries and did what any visitor's browser does with no session: requested /dashboard, /admin and /account, re-issued each app's own /api endpoints with no auth header, and where the frontend shipped a Supabase anon key, tried a one-row read with that same public key.

261 of 4,740, or 5.5 percent. Every probe was read-only, nothing returned was stored, and no app is named. An app counts as exposed only when its own response proved it: a rendered private view, a records payload, or a successful row read. There is no scanner heuristic between the request and the verdict.

Part 2: repositories

We also statically scanned 2,148 public GitHub repositories built with or by AI tools, in three separately sourced corpora. 551 of them, 25.7 percent, contained at least one high-severity finding. The corpora are not comparable to each other; read each row on its own.

What the scanner found most

• 276Hardcoded credential in source
• 135Path traversal from user input
• 79Code injection (eval / exec)
• 72Math.random() for a security value
• 49TLS certificate verification disabled
• 46Prototype pollution
• 40SQL injection by string concatenation

Treat the repo rates as upper bounds. They come from a static scanner. High-severity findings in the Lovable and Bolt corpus were manually reviewed and false positives are marked and excluded in the dataset; the other corpora were reviewed in aggregate to fix scanner rules, not individually labelled. The pattern that holds in every group independently: hardcoded secrets sit at or near the top.

Why it keeps happening

Ask an AI tool to add login and it builds the sign-in page, the session, the redirect. That is authentication. The part it routinely skips is authorization: the check that runs after login on every route and every endpoint, including the ones with no visible button. Because the login screen exists, the app feels secure. The insecure version works, so it ships. Same story with the API key pasted inline and meant to be moved later.

Common questions