A study of public AI-built apps
What a free code check finds in 200 public AI-built apps
We read the code of 200 public apps made with AI builders on 28 October 2026. Code only: nothing was run, no site or database was touched, and nobody was contacted.
What the code showed
A sample of recently updated apps, not a census: the shares describe these 200 apps and nothing wider. Each share is of the apps the rule could look at; a rule that reads database migrations can only look at the apps that have them.
43%
50 of the 117 apps with database migrations in the repository had a row-level security rule that lets anyone change every row of a table, with no condition.
15%
18 of the 117 apps with database migrations in the repository had a table made in the migrations with row-level security never switched on.
6%
11 of all 200 apps had a string with the shape of a live secret key (payment, AI, cloud, chat, source host or database), in a file that is not a test or an example.
15%
30 of all 200 apps had a server route that calls a paid AI service and, in its file, shows no check of who is asking and no limit on how often.
78%
146 of the 186 apps with a lockfile had a part the app runs, not only builds with, with a published advisory rated high or critical by its publisher.
16%
32 of all 200 apps had a settings (.env) file kept in the repository, holding no secret the check recognises.
Found in nearly every app (90% or more), so they do not set one app apart from another:
Build robot
98%196 of 200
Errors and uptime
92%184 of 200
How to read these numbers
Code only
The check reads an app's code. It never visits the app's site, never opens its database and never tries a key. A finding says what the code shows. It does not say that anyone read the data.
A sample, not a census
These are the most recently updated apps among those GitHub's search returns. The shares describe these 200 apps and nothing wider.
No one is named
No app and no owner is named here, and nobody was contacted.
Every line of the reading
Every line of the reading, in its order: what the code shows, the apps with at least one, and who the share is of.
A table made in the migrations with row-level security never switched on
15%18 of the 117 apps with database migrations in the repository
A row-level security rule that lets anyone change every row of a table, with no condition
43%50 of the 117 apps with database migrations in the repository
A rule that lets any signed-in person change every row of a table, with no condition
26%31 of the 117 apps with database migrations in the repository
A rule that lets anyone read every row of a table, with no condition (right for a public list, wrong for personal data; the code cannot tell which)
55%64 of the 117 apps with database migrations in the repository
A rule that lets every signed-in person read every row of a table that looks personal
26%31 of the 117 apps with database migrations in the repository
An update or delete rule whose condition never asks who is asking
24%28 of the 117 apps with database migrations in the repository
A database view that runs with its maker's rights over a table that has row-level security, so it can show rows the table's own rules would hide
27%32 of the 117 apps with database migrations in the repository
A database function that runs with its maker's rights and that nothing in the migrations stops visitors from running
64%75 of the 117 apps with database migrations in the repository
A file bucket set to public in the migrations
51%60 of the 117 apps with database migrations in the repository
Firestore rules that allow with if true
Not counted: 0 apps with Firestore rules in the repository
Server code that reads or changes a row by an id from the request, with the database's service key and no sign of an owner check in the file
13%25 of all 200 apps
A database query built from text a visitor sent
9%18 of all 200 apps
Page content written from text a visitor sent or saved
15%30 of all 200 apps
An upload with no test of its size or type
2%3 of all 200 apps
Passwords hashed with a fast function (MD5, SHA-1 or a plain SHA) in place of a password hash
8%5 of the 62 apps with sign-in code of their own
A sign-in token the server decodes without checking its signature, or signs with a key written in the code
15%9 of the 62 apps with sign-in code of their own
A token or code made with Math.random
45%28 of the 62 apps with sign-in code of their own
A cookie set without all of its protection flags
0%0 of the 62 apps with sign-in code of their own
A password stored or compared exactly as it was typed
8%5 of the 62 apps with sign-in code of their own
A sign-in route with no limit on attempts
6%4 of the 62 apps with sign-in code of their own
A setting for an AI or payment key whose name makes the build copy it into the page every visitor downloads
4%7 of all 200 apps
A server route that calls a paid AI service and, in its file, shows no check of who is asking and no limit on how often
15%30 of all 200 apps
A call to a paid AI service with no ceiling on the answer and no limit on what is sent
<1%1 of all 200 apps
A payment webhook route whose file shows no check of the sender's signature
1%2 of all 200 apps
A string with the shape of a live secret key (payment, AI, cloud, chat, source host or database), in a file that is not a test or an example
6%11 of all 200 apps
A private-key file kept in the repository
0%0 of all 200 apps
A settings (.env) file kept in the repository, holding no secret the check recognises
16%32 of all 200 apps
A part (package) the lockfile pins that has a published security advisory
89%166 of the 186 apps with a lockfile
A part the app runs, not only builds with, with a published advisory rated high or critical by its publisher
78%146 of the 186 apps with a lockfile
Which kind of key
Of the apps that held a string shaped like a live secret key, by the kind of key:
Your database's master key (Supabase service role)
3%5 of 200
An Anthropic key
<1%1 of 200
An OpenAI key
2%4 of 200
A webhook signing secret
<1%1 of 200
A string with a key's shape is not proof that the key works. The check never tried one; it never kept one (a finding carries the kind of key and the file, not the key).
By area of the map
The "Ready for real customers" map has 23 areas that a code reading can speak to. Apps with at least one thing to fix in the area, most common first. The Tests area is left out: it needs a live copy of an app, and this study ran none.
Parts
83%166 of 200
Marketing
80%160 of 200
Browser protections
80%159 of 200
Accessibility
78%155 of 200
Old runtimes
72%143 of 200
Legal pages
66%132 of 200
Search and launch
65%129 of 200
Staging and deploys
60%119 of 200
Open-source licences
59%117 of 200
Speed
56%112 of 200
Backups
55%110 of 200
Data access
52%104 of 200
Personal data
43%85 of 200
Email
36%72 of 200
Access holes
31%61 of 200
Support
28%56 of 200
Keys
28%55 of 200
Logins
21%41 of 200
Input safety
20%40 of 200
Cost guard
17%34 of 200
Payments
4%7 of 200
How it was done
- Who counts
Lovable: package.json lists lovable-tagger, a plugin Lovable adds to the projects it makes; or the README keeps Lovable's welcome line or its project link. Bolt: a .bolt/ folder at the top of the project, which Bolt writes into the projects it makes.
- How the apps were found
GitHub's search, one request at a time, waiting whenever GitHub's limits said to. Only apps that are public, not forks, not empty and at least 30 days old, most recently updated first; the first 100 of each builder that could be read.
- Passed over as the walk went
4 (younger than 30 days on the day of the study); 31 (a code archive larger than the check reads).
- How each app was read
By the check's own reader: the default branch at its head, one archive, read in memory. Nothing was cloned, installed, built or run. Judged by the rules the check runs for a customer's app (rules version 2026-10-28a); its parts looked up in the public flaw database by name and version only.
- What a reading keeps
A reading keeps its first 60 findings. 72 of the 200 apps had more, and their kinds were counted from the check's complete list.
- When
Read 28 October 2026, 13:13 to 13:40 UTC.
What it cannot tell you
- Which apps
GitHub's search returns at most 1000 results for a query and ranks them its own way, and its index is not the whole of GitHub. Apps that are never updated, private apps, and apps that left their builder's marker out are not in the study.
- Code only
A rule that reads a migration cannot see a setting made in a dashboard, and a rule that reads sign-in code reads only the app's own code. A finding is a place to look, not a verdict on the app.
- The flaw database
0 of 200 apps had a flaw-database answer that did not finish, and 1 had advisories past the 80 whose descriptions the check fetches per reading (a part whose advisory was not described is rated medium).
- The builders are counted together
Lovable and Bolt were sampled to the same size, 100 each, and this page does not compare them.
- The rules move
A later reading of the same apps could say something else (rules version 2026-10-28a).
Want to see it on your app?
If your app was made with an AI builder, the free check reads it the same way and tells you in plain words what to fix. It changes nothing without your yes.