I scanned 55 public Lovable apps — all 55 had a GDPR or security finding

AI app builders are genuinely remarkable. You describe an app, and minutes later it is deployed on a real URL with a real database. That part works.

What does not come along is the boring layer underneath: security headers, consent timing, legal pages. Nobody prompts for those, so nobody gets them.

I wanted to know how large that gap actually is, so I measured it. (Practical guidance, not legal advice.)

What I did

I collected 55 publicly discoverable apps on *.lovable.app — trackers, invoicing tools, portfolios, CRM dashboards, fitness apps, waitlist pages — and ran a passive check on each.

Passive matters. Every app was loaded once over HTTPS with plain GET requests, exactly the way any visitor's browser loads it. No login attempts, no active probing, no guessing at hidden paths. Everything below is what these apps tell the entire internet on first page load.

Results are aggregate only. No app is named, and none will be. The full breakdown lives on the research page.

The results

Out of 55 apps, every single one had at least one finding — on average 4.3 each:

• 98% have no Content-Security-Policy (54 of 55)
• 98% have no clickjacking protection (54 of 55)
• 95% embed a third-party tracker (52 of 55)
• 95% load tracking before any consent (52 of 55)
• 45% hotlink Google Fonts from Google (25 of 55)

Not one clean result in the sample. That was the part I did not expect.

What each finding actually means

No Content-Security-Policy. A CSP tells the browser which scripts may run. Without it, any script that gets injected into your page — through a compromised dependency, a vulnerable input, a malicious extension — executes with full access to everything your users type. It is the strongest browser-side defense against XSS, and virtually nothing in this sample had one.

No clickjacking protection. Without X-Frame-Options or frame-ancestors, anyone can embed your app in a hidden iframe, overlay it with fake UI, and trick a logged-in user into clicking your real buttons. Delete account. Confirm payment. They never see what they clicked.

Trackers before consent. This is the legal one. Under Germany's § 25 TDDDG and the GDPR, consent has to come first. A banner that appears after analytics already fired protects nobody — the data left on page load. In this sample, 52 of 55 apps started sending data to third parties before the visitor could possibly agree. Background: tracking without consent and what a third-party tracker is.

Google Fonts hotlinked. Loading fonts from fonts.googleapis.com sends every visitor's IP address to Google. A German court (LG München I, 2022) awarded damages over exactly this, and it started a wave of warning letters. Nearly half the sample still does it — and it is the easiest fix on the list. Details: Google Fonts and the GDPR.

Why builders ship this way

None of this is Lovable being careless. It is structural, and it applies to Bolt, v0, Replit and every other builder equally:

1. Security headers are invisible. Nothing looks different when they are missing. No error, no warning — the app just works, right until it does not.
2. Templates carry defaults. Analytics snippets and font links ship with the starter code. They work, so nobody removes them.
3. Nobody prompts for compliance. You ask for "a booking app with Stripe", not "and a CSP header and a consent gate". Why would you.
4. The obligation is yours regardless. If people in the EU use your app, you are the operator under Art. 3(2) GDPR — wherever you are based, whoever generated the code.

The fixes, in the order I would do them

1. Security headers. Mostly one config file. X-Frame-Options and nosniff are one-liners with near-zero breakage risk. Add HSTS once everything runs on HTTPS. Do CSP last, in report-only mode, tightening until the console is quiet.
2. Self-host your fonts. Download the .woff2 files, serve them from your own domain, delete the Google link. About 15 minutes — the walkthrough is in self-hosting Google Fonts.
3. Fix consent timing. Either remove the non-essential trackers (then you may need no banner at all), or route every tracking script through a consent tool's blocking mode so nothing fires until opt-in. We covered which apps actually need one in do you need a cookie banner for your Lovable app.
4. Write real legal pages. A privacy policy naming the services you actually use. Generic generator text listing tools you do not have is its own liability.

None of this requires rebuilding your app. For most projects it is an afternoon of configuration.

The caveats

This is a convenience sample, not a random draw — 55 apps I could discover publicly. Read the percentages as directional, not exact. A different 55 would land nearby, not identical.

I also deliberately excluded findings that are public by design. A Supabase anon key appears in the frontend of essentially every Lovable app, and that is how it is meant to work — it is protected by row-level security, not by secrecy. Counting it as a "leak" would inflate the numbers and mislead people, so it is out. Only documented security and GDPR checks are counted. (The genuinely dangerous Supabase findings — a service-role key in the bundle, or a table readable without login — are in scope. Neither appeared in this sample.)

See where your app stands

The complete data, with every finding linked to what it means and how to fix it, is on the research page. If you want the same check on your own app, it runs in about a minute, passively, with no login: see what we check on Lovable apps, or run the cookie and tracker scanner on its own.