More than 1 in 4 apps built with Lovable or Bolt has a high-severity security flaw. We checked.

These aren’t the Lovable or Bolt codebases themselves. They’re real projects other people built with those tools and pushed to GitHub, the AI app builders’ actual output. We found 639 of them by searching for each platform’s export fingerprint (Bolt’s .bolt/config.json, Lovable’s lovable-tagger build plugin), cloned each one, scanned it with Prbl, and deleted the clone immediately after. 628 scanned successfully. 27.1% of them had at least one high-severity finding. Not a style nitpick, not a linter warning. A finding that could plausibly lead to unauthorized access, credential exposure, or account takeover.

What “high-severity” actually means here

One pattern showed up far more than anything else. It doesn’t show up when you click around the demo, it doesn’t show up to the model that generated it, and it shows up the day someone deliberately looks for it.

1. Hardcoded credentials: real API keys and passwords, shipped to GitHub

The single most common high-severity finding, by a wide margin: 265 occurrences across 128 apps. Not placeholders, not your-api-key-here. Real, working values: Firebase config keys, third-party API keys for services like Firecrawl and TinyMCE, and in two separate apps, a real API key for a major LLM provider, hardcoded directly in source and pushed to a public repo.

An illustrative, simplified example of the pattern:

const firebaseConfig = {
  apiKey: "AIza...", // real key, not a placeholder
  authDomain: "my-app.firebaseapp.com",
};

The most common single shape within this category was a Supabase project URL and anon key hardcoded directly into client code, the default pattern both tools scaffold a new project with. Supabase’s anon key is designed to be exposed in client-side code, that part is normal. What it depends on is Row Level Security being correctly configured on every table it can touch. We did not test whether RLS was enabled on any of these projects, that would mean probing live production databases, which we won’t do. What we can say is that the key ships hardcoded by default, and whether that’s safe depends entirely on a configuration step that’s easy to skip when the app already works.

What this actually costs you: a real API key in a public repo gets scraped by bots within minutes. Anyone with read access to the repo, including in a private repo that’s ever cloned, forked, or leaked, gets every credential in it, permanently. Deleting the line in a later commit doesn’t help, the key is still sitting in git history.

2. Weak randomness: passwords, OTPs, and tokens that aren’t actually random

Second most common: 76 occurrences across 39 apps. Math.random() used to generate something that gates access: a password reset token, a one-time login code, an account invite code, a temporary password assigned to a new user. Math.random() is not cryptographically secure and was never designed to be, it’s predictable enough that an attacker who understands the pattern can narrow down or reproduce the output.

What this actually costs you: a predictable password-reset token means an attacker can take over any account without ever seeing the real password. A predictable invite code means anyone can join a space meant to be private. The fix is one line, swap Math.random() for crypto.randomUUID() or crypto.getRandomValues(), but it has to be the developer who knows to make that swap.

3. TLS verification disabled

Smaller in volume, 14 occurrences across 8 apps, but some of the highest-stakes findings in the dataset. One app set process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0', which disables certificate verification for every outgoing HTTPS request the entire process makes, not just one connection. Others disabled certificate checking on a single database or API connection, frequently with a comment explaining that it was changed to bypass a certificate error rather than fix it.

What this actually costs you: with certificate verification off, anyone positioned between your app and the server it’s talking to (a compromised network, a malicious Wi-Fi hotspot) can intercept and read or modify that traffic, including credentials and API responses, without either side knowing.

What we found that we didn’t expect

Splitting the results by platform turned up a real difference we didn’t anticipate going in. Apps built with Lovable were roughly twice as likely to have a high-severity finding as apps built with Bolt, and roughly twice as likely to have a hardcoded credential specifically.

We can’t fully explain the gap from this dataset alone, we didn’t set out to compare the two platforms head to head and this isn’t a controlled test of their respective defaults. The most visible contributor we observed directly: Lovable’s default project scaffold wires up a Supabase client with the project URL and anon key written directly into a committed file, a pattern that showed up by name, in the same file path, across dozens of the Lovable apps we scanned. That alone doesn’t account for the entire gap, but it’s the clearest single factor we could point to in the data.

Why this keeps happening

None of this is about careless developers. Most of these apps work exactly as intended. The prompt that built them asked for a feature, not a threat model, and the model delivered the feature. Whether the app is safe to put in front of real users with real accounts is a different bar, and nothing in the build-and-ship loop these tools create checks for it by default.

Methodology

Apps were sourced via the GitHub code search API, searching for each platform’s distinctive export fingerprint: Bolt’s .bolt/config.json file, and Lovable’s lovable-tagger Vite plugin reference in package.json. This is a structural fingerprint left by the export process itself, not a keyword match, so it reliably identifies real output from each tool rather than unrelated repos that happen to mention the product name. We pulled 340 Bolt repos (the full set returned) and a random sample of 300 from 898 Lovable candidates, for 639 total, explicitly excluding forks and the platforms’ own repositories.

We initially attempted to source by raw GitHub star count for a related, separate study and found the results dominated by repos with fabricated star counts, full writeup in how we test Prbl. The fingerprint-based approach used here doesn’t have that failure mode, since it matches a structural artifact of the export process, not a popularity signal.

Each repo was shallow-cloned, scanned with Prbl’s open-source scanner rules, and the clone deleted immediately afterward. No source code was retained, and no specific repo, username, or finding is identified anywhere in this post. 628 of 639 repos scanned successfully, the remainder failed to clone or contained no scannable source files.

Every single high-severity finding in this dataset, all 470 of them, was manually traced back to its source line before being counted, the same discipline used for our Hacker News repo study. That review surfaced 17 distinct false-positive patterns in our own scanner, all fixed and covered by new regression tests before these numbers were finalized: generated-SDK example credentials, self-referential constants, explicitly-labeled mock and dev placeholder tokens, route paths mistaken for secrets, a committed Python virtualenv that produced two dozen spurious findings from third-party packages, and several others. Full details in how we test Prbl.

The aggregate counts behind every number in this post are available as a raw CSV. It contains rule-level occurrence counts and affected-app counts only, no repo names, usernames, file paths, or owners.

Limitations

• Results are based on static analysis and may contain false positives, despite manual review of every high-severity finding.
• We manually reviewed and traced every individual high-severity finding to source, but did not penetration-test any live application or verify backend configuration (e.g. Supabase Row Level Security policies) on any scanned project.
• Only apps the original developer chose to push to a public GitHub repo were included. Apps kept private, or never exported from the builder at all, aren’t represented, and we have no way to know how this sample compares to the full population of apps built with either tool.
• Findings represent code-level risk and do not account for deployment-specific mitigations a developer may have added outside the repo (e.g. a reverse proxy enforcing TLS).
• The Bolt-vs-Lovable comparison is observational, not a controlled experiment, and is based on a 300-repo random sample for Lovable against a 340-repo full set for Bolt.

Frequently asked questions

Are apps built with AI app builders like Lovable and Bolt secure?

In a sample of 628 real apps built with Lovable or Bolt and pushed to GitHub, 27.1% had at least one high-severity security finding, most commonly a hardcoded API key or password.

What is the most common security issue in Lovable or Bolt apps?

Hardcoded credentials were the single most common high-severity finding (265 occurrences across 128 apps), most often a third-party API key or a Supabase project URL and anon key written directly into committed source code, ahead of weak randomness in password and token generation (76 occurrences, 39 apps).

How do I check if my own Lovable or Bolt app has these issues?

Paste your GitHub repo URL into Prbl’s free scanner for a direct answer in under a minute. No account required.

What to actually do about it

The 628 apps in this dataset didn’t know they were being checked. Yours hasn’t been checked yet either.

You don’t need to read your own codebase line by line wondering if you’re one of the 1 in 4. Paste your GitHub repo URL into Prbl and get a direct answer in under a minute, free, no account required. If something high-severity turns up, you’ll know exactly which file, which line, and what to do about it.