We scanned nearly 2,000 AI-built apps. The same secret kept leaking.

We have published these studies one at a time: the Lovable and Bolt scan, the Hacker News scan, and the Claude Code scan. Each one has its own headline. But when you line all four up next to each other, a pattern appears that is more useful than any single number, because it holds no matter who built the app or what they built it with.

The one flaw that showed up everywhere

A hardcoded secret is a credential written directly into source code as a plain string, an API key, a database URL and key, a session-signing secret, a password, instead of being read from an environment variable at runtime. When the code gets pushed to a repository, the secret goes with it. Anyone who can read the repo can read the secret, and it stays in the git history even after someone deletes the line.

Here is how often it turned up, by corpus:

In the app-builder corpus it was the single most common high-severity finding, in 1 of every 5 apps. In the Claude Code corpus it was again the most common, in roughly 1 of every 11. In the Hacker News corpus it ranked among the top three high-severity patterns. Three completely different populations of developers, and the same class of mistake sat at or near the top of each one.

Why it doesn't matter who built the app

This is the part worth understanding, because it explains why the pattern is so stable. A hardcoded secret is not a knowledge gap and it is not a tooling failure. Every developer who has ever done it knew, abstractly, that it was wrong. It happens anyway because it is the path of least resistance in a specific moment: you are trying to get something working, the key is right there in your clipboard, pasting it inline works instantly, and moving it to an environment variable is a small chore you will do later. Later frequently does not come before the first git push.

A no-code builder does not protect you from this, because the builder often generates the hardcoded key for you as part of its default scaffold. A more capable AI model does not protect you from this either, which we measured directly: the secret-leak rate held flat across three generations of Claude models, because the model was never the thing deciding to paste the key in. It is a human reflex, and it shows up wherever humans ship software quickly, which is now everywhere.

Why it is worse than it sounds

“A leaked key” can sound abstract until you follow what it actually opens. In these studies the hardcoded secrets included database URLs paired with their access keys, session-signing secrets, cloud service keys, and admin passwords. Depending on the key, a reader of the repo could query or modify the app's entire database, forge a login session for any user including an administrator, or run up charges on a paid service in the owner's name. And because a public repository is continuously scraped by automated bots hunting for exactly these strings, exposure is not hypothetical or slow. Committed keys get found.

The fix is the same everywhere too

The uniformity of the problem is good news, because it means one habit closes most of it. Before a repository goes public:

• Search your own code for the obvious markers: supabase.co, apiKey, SECRET, password, and any long random-looking string. Most hardcoded secrets are found in under a minute this way.
• Move every secret into an environment variable, and confirm your .env file is listed in .gitignore before the first push, not after.
• If a secret was ever committed, rotate it at the provider. Removing the line does not remove it from git history, so assume anything that was pushed is already compromised and issue a new one.
• For anything a framework signs with (session secrets, tokens), generate a long random value and make the app refuse to start if the environment variable is missing, rather than falling back to a default.

Methodology and limits

The figures combine four scans run with Prbl: 976 repos linked from Hacker News, 628 apps generated by Lovable and Bolt, and 364 web apps written with Claude Code (across three model generations). Every high-severity finding was manually reviewed, and false-positive patterns the reviews surfaced were fixed in the scanner before the numbers were computed. The corpora were sourced and scoped differently, so the per-group rates are not perfectly comparable to one another, that is not the claim. The claim is narrower and more robust: in each group, independently, hardcoded secrets landed at or near the top of the high-severity findings. No specific repository, owner, or file is identified anywhere in this post.

Every few months a new tool promises to change how software gets built. Some of them genuinely do. None of them have changed the fact that the fastest way to ship a working app is to paste the key inline and mean to fix it later. Until that reflex changes, the single highest-value thing you can do before going public is the most boring: go find the secret you left in the code.

Common questions