Scan of 100 Lovable-built apps finds dead projects, missing headers and a leaked API key

A developer writing on dev.to scanned 100 apps pulled from Lovable's public showcase and found that 14 had already gone offline. Of the 86 still reachable, none earned a clean privacy score, and one was exposing a working OpenAI API key inside its public JavaScript bundle, where anyone with browser developer tools could read it.

The scan was run with Vespez, a security and GDPR checking tool that the author says they build — a connection the post discloses up front. The methodology is described in enough detail to judge the results.

The numbers

According to the dev.to post, the 86 live apps averaged 77 out of 100 on security checks and 38 out of 100 on GDPR checks. Three had no security findings at all; zero had a clean GDPR sheet. The app exposing the OpenAI key was not named, with the author saying it would be reported privately rather than publicised.

Missing headers were the most common failure

96 percent of the apps had no Content-Security-Policy header, and 92 percent could be embedded inside another site, the setup needed for clickjacking attacks. Ninety-two percent were missing both at once. The author's interpretation is that these are not dozens of independent omissions but one platform-level gap: Lovable does not set these headers by default, so they only exist if a builder already knows enough to add them.

A similar default appeared in third-party loading. Fifty-five percent of apps pulled Google Fonts directly from Google's servers — a side effect of the template rather than a considered decision, the author writes, and the sort of third-party data transfer that European privacy law scrutinises.

The gaps that fall on the builder

Fifty-seven percent of the apps had no findable privacy policy, and 63 percent had no terms of service. Unlike the missing headers, the author puts these omissions on the people building the apps rather than on the platform.

One finding cut the other way: consent banners, where they existed, did their job. Apps with a banner fired trackers before a visitor accepted only 10 percent of the time; apps without one did so 96 percent of the time. The problem is coverage — 23 of the 86 apps never added a banner at all.

Moving to a custom domain made things worse

Apps still hosted on a lovable.app subdomain averaged a GDPR score of 44, while apps that had moved to their own custom domain averaged 34. With samples of 36 versus 50 apps, the author treats the difference as suggestive rather than conclusive — but it is the custom-domain apps, the ones being treated as real products, that scored lower.

Method, and its limits

Each app got a single pass: a headless browser rendered the page, recorded network requests and cookies before the visitor interacted with any consent prompt, and checked response headers. Where a privacy policy existed, an AI model read it and compared what it claimed against what the site actually did. The 14 unreachable apps were excluded from scoring, and nothing from the pages was kept beyond scores and findings.

The author is explicit about the caveats: this is a scan, not a legal audit, so a low score signals a likely problem rather than a confirmed violation. The sample also comes from a public showcase of AI-builder projects, not a random slice of the web.

Why it matters

AI app builders have stripped most of the friction out of going from idea to deployed product. This scan is an empirical hint at what does not come along for the ride: security headers, consent handling, privacy documentation and the habit of keeping secrets off the client. The leaked API key is the sharpest illustration — credentials shipped to the browser are readable by anyone, and generating code does not fix that for you. The data comes from one platform's showcase and one vendor's scanner, so it is a data point rather than a verdict, but it feeds a live argument about whether tools like Lovable should ship safer defaults instead of leaving them to builders who may not know which questions to ask.