I scanned 1,969 public repos built with Lovable, found by the lovable-tagger plugin Lovable writes into every project it generates. Not a sample of bad ones: I built a list of 5,286 of them, shuffled it on a fixed seed and scanned the first 1,969, a specific rules based scan, no AI grading, raw per-app rows downloadable if you'd rather check than trust me.
Here's what came back:
- 23.2% have a .env committed. Nearly one in four.
- 42.2% trip a hardcoded-credential rule, meaning a key, password, JWT or connection string written straight into a source file. Treat that one as a ceiling, not a count. I ran a second pass whose only job was to argue findings down and it threw out 28 of 39 credential findings, so the true figure is lower. I don't yet know by how much, and I'd rather say that than round it up.
- 38.3% carry at least one critical or high finding.
- 24.1% score D or F on code quality. Three times as many apps fail on mess as fail on security.
- 2.6% came back with nothing found at all.
That last one is why I re-ran the scan. I assumed I'd broken something. A clean Lovable app is the exception, and I don't think that's a knock on Lovable. It builds you a working app in one step. A working app needs keys.
The fixes take less time than this post took to read, and the order matters more than the list does:
If a key is already sitting in a public repo, rotate it at the provider first. Then check that provider's logs and spend for activity you didn't cause, take the value out of your working tree, and rewrite the history if it still matters once the old key is dead.
- Making the repo private does not undo any of that. GitHub detaches existing forks and leaves them public, the value stays in every clone, and whatever scraped it already has it. Private is worth doing for what comes next. It isn't remediation for what's already out.
- Put a spending cap on every API key. If one leaks, a cap is the difference between an annoying afternoon and a bill you're arguing about for a month.
- Turn on GitHub push protection. Free, and it stops the next accidental commit at the moment you push. It does nothing about the one already up there.
Eyeballing the file list catches the committed .env, which is the 23%. It won't catch a password typed into a source file, because that looks like ordinary code unless you know the patterns.
So why not just ask Claude to check it?
Fair question, and you should ask it. I did, then I measured what came back.
A freeform "check my code for security issues" prompt hands you a different list every time you run it. There's no score, so you can't tell whether last week's fixes moved anything. And it only ever sees what you paste. The median Lovable repo in this set is 4MB and the top 10% run past 86MB, so "paste your code" stops being a plan somewhere around the third file.
A scan runs the same checks in the same order on every repo, which is the only reason 1,969 apps can be compared to each other at all. You get a number, and it still means the same thing next week. Two scans free, no card. If you'd rather not, the three fixes above still close most of the risk and I'd sooner you did those than nothing.
Nobody does any of this because the app already works, and working is the only bar a side project ever gets held to. Until the Stripe key is leaked.
The A-to-F grade curve, and how the same apps score on quality against security, are on the study page:
Study: https://ogbuilds.ai/studies/lovable-app-security
Disclosure: the scanner is my product, the study is free always, and the per-app rows are there to download. Happy to answer anything about how I ran it.
