DEV Community: Hannes

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

Hannes — Sun, 16 Aug 2026 12:06:12 +0000

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:

Security headers are invisible. Nothing looks different when they are missing. No error, no warning — the app just works, right until it does not.
Templates carry defaults. Analytics snippets and font links ship with the starter code. They work, so nobody removes them.
Nobody prompts for compliance. You ask for "a booking app with Stripe", not "and a CSP header and a consent gate". Why would you.
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

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.
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.
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.
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.

Self-hosting Google Fonts: the 15-minute fix for a classic GDPR finding

Hannes — Tue, 11 Aug 2026 21:52:15 +0000

Originally published on howsafeismyapp.com.

If your app's <head> contains a line like

<link href="https://fonts.googleapis.com/css2?family=Inter" rel="stylesheet">

then every visitor's browser contacts Google's servers before your page even renders — transmitting their IP address along the way. In 2022, a German court (LG München I) ruled that exactly this, done without consent, violates visitors' rights, and awarded damages to a website visitor. The decision triggered a wave of warning letters (Abmahnungen) against site operators, aimed precisely at small sites that had copied the standard embed code.

It remains one of the most common findings on AI-built apps, because font embeds are baked into templates and AI-generated layouts. It is also one of the easiest to fix. (Practical guidance, not legal advice.)

Why this is a GDPR issue at all

An IP address is personal data. Sending it to a third party requires a legal basis (Art. 6 GDPR), and transfers to US providers raise the additional third-country questions of Art. 44 GDPR. "The CSS loads faster from Google's CDN" is not a legal basis — especially since self-hosting is equivalent in practice: fonts served from your own domain are cached, local, and remove a DNS lookup and TLS handshake to a foreign origin. The details are on our check page: Google Fonts loaded directly from Google.

Fonts are the famous example, but the same logic applies to anything your page pulls from third-party CDNs on first load — icon fonts, CSS frameworks, JS libraries.

Find out if your app is affected

Fastest way: our free Google Fonts checker answers this in seconds. Manually: open your app in a private window with DevTools → Network, reload, and filter for fonts.googleapis.com or fonts.gstatic.com. In a Lovable/Bolt/v0 project you can also just search the code for googleapis — the embed usually sits in index.html or a global CSS file.

The fix: serve the fonts yourself

Download the font files. The open-source tool google-webfonts-helper packages any Google Font as .woff2 files with ready-made CSS — or download from the font's official repository. .woff2 alone is enough for every current browser.
Put the files in your app's public/static folder, e.g. public/fonts/inter-v13-latin-regular.woff2. In Lovable, add them to the project's public assets.
Replace the Google <link> with local @font-face rules:

@font-face {
  font-family: "Inter";
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url("/fonts/inter-v13-latin-regular.woff2") format("woff2");
}

Delete the fonts.googleapis.com link tag — this step is the actual fix; the scanner (and the warning-letter industry) looks for the request, not your intentions.
Reload with the Network tab open: there should be no request leaving your domain for fonts.

Total effort for a typical two-font app: about 15 minutes.

Two upgrades while you're at it

Long cache lifetimes for font files. They never change; a year-long Cache-Control header makes repeat visits faster than the Google CDN ever was.
Check the rest of your first load. If fonts came from a third party, other resources often do too. Loading anything over plain HTTP is its own finding — resources loaded over unencrypted connections — and third-party tracking scripts are a much bigger consent problem than fonts: tracking loads before anyone could consent.

Verify from the outside

The nice thing about this class of problem: it is fully visible from the outside, no access to your code needed. Our free passive scan requests your app like any anonymous browser would and reports every third-party request on first load — fonts included — plus 14 other checks. Takes about a minute; nothing gets stored.

Common questions

Does `font-display: swap` or preconnect help legally?

No. Those are performance tweaks — the legal issue is the request to Google's servers itself, which transmits the visitor's IP address. Only removing the request fixes it.

What about Bootstrap, jQuery or icon CDNs?

Same logic. Any resource loaded from a third-party CDN on first paint transmits visitor IPs to that provider without a legal basis. Self-host what you can; whatever remains needs a justification and a mention in your privacy policy.

Is this a fine risk or a warning-letter risk?

In practice, warning letters and small damages claims — the 2022 Munich decision awarded a visitor damages, and copycat claims followed in waves. The cost of a single response letter to a lawyer exceeds the cost of self-hosting many times over. If you're doing a broader consent cleanup anyway, start here: Do you need a cookie banner?.

Row Level Security in Lovable apps: why your database might be public

Hannes — Tue, 11 Aug 2026 21:49:44 +0000

Originally published on howsafeismyapp.com.

Here is the uncomfortable truth about most Lovable apps: the database is not behind your login form. It is behind Supabase's API — and whether that API hands out your data to strangers depends on one setting most AI-generated apps never mention: Row Level Security.

This is the most serious finding our scanner sees in the wild. It is also completely fixable in an afternoon. (Practical guidance, not legal advice.)

Why your frontend talks to the database directly

Traditional apps put a backend server between the browser and the database. Lovable apps usually don't: the browser talks to Supabase's REST API directly, authenticated with the so-called anon key that is shipped inside your JavaScript bundle.

That key is supposed to be public. Anyone who opens your app has it — and with it, anyone can send requests like:

GET https://your-project.supabase.co/rest/v1/users?select=*

What decides whether that request returns your entire users table or an empty response is not the key. It is Row Level Security.

What RLS actually does

Row Level Security is a PostgreSQL feature that Supabase builds on. With RLS enabled on a table, every query is filtered through policies — rules that say which rows a given user may read or write. A typical policy:

a user may SELECT rows in profiles where user_id = auth.uid()
nobody may SELECT from payments at all via the public API

Without RLS enabled, there is no filter. The anon key can read every row of every exposed table. Your login form is decoration; the data was never behind it.

Why AI-built apps get this wrong

Lovable and similar builders generate working code fast, and "working" means the app can read and write its own data. Two common paths to trouble:

The generated setup never enables RLS on new tables, because everything works without it in development.
RLS was enabled, but a debugging session ended with a policy like USING (true) — "allow everyone" — that never got removed.

Neither produces an error. The app works perfectly. That is exactly why this finding survives into production. Our check page explains what the scanner looks for: Database readable without a login.

Check your own app in two minutes

Open your app in the browser, then open DevTools → Network.
Reload and look for requests to *.supabase.co/rest/v1/... — note your project URL and the apikey header (that's the anon key; it's meant to be visible).
In a private browser window — logged out of everything — request one of your tables with that URL and key, for example with curl.
If you get data back while logged out, that table is public. Anything with names, emails, or user content is now a data-protection incident waiting to be discovered by someone less friendly.

Under Art. 32 GDPR you are required to have appropriate technical measures for personal data; an openly readable users table is about as clear a failure of that as exists. If real personal data was exposed, Art. 33 GDPR (breach notification, 72 hours) becomes the relevant question — a conversation you want to avoid ever needing.

Locking it down

In the Supabase dashboard:

Table editor → your table → enable RLS. Do this for every table in the public schema. Supabase warns you about tables without RLS — take the warning seriously.
Write policies from the user's perspective. Start restrictive: users read their own rows (auth.uid() = user_id), insert only their own, update only their own. Add broader read access only where the product genuinely needs it (e.g. a public feed).
Tables the browser never needs (internal logs, admin data) get RLS enabled with no policies at all — that means no access via the public API, which is exactly right.
Never ship the service_role key to the frontend. It bypasses RLS entirely. If it appears anywhere in your bundle, rotate it now — we cover this separately: Admin key exposed in frontend code.

Then re-run the two-minute check from above. The logged-out request should now return an empty array or an error — both are success.

After the fix: verify from the outside

The inside view (dashboard says RLS enabled) and the outside view (what a stranger's browser can actually fetch) can disagree — a forgotten table, a too-broad policy, a second Supabase project. The outside view is the one that matters, and it is what a passive scan checks: our scanner requests your app the way any anonymous visitor would and reports which tables answer. It takes about a minute, needs no login, and stores nothing.

Common questions

Is the Supabase anon key a secret?

No — it is designed to be public and ships in your JavaScript bundle by design. The protection layer is Row Level Security, not the key. The key that must stay secret is service_role — see admin key exposed in frontend code.

Will enabling RLS break my app?

Enabling RLS without policies makes tables return empty results via the public API — so your app's own queries stop working until you add policies for them. That is the point: write the policies your app needs, and everything else stays closed. Budget an hour, not a weekend.

How do I know whether someone already accessed my data?

Check the API logs in the Supabase dashboard for anonymous requests to sensitive tables. If personal data of real users was readable, look into the breach-notification duties of Art. 33 GDPR — the 72-hour window starts when you become aware, and honest, early handling counts in your favor.

DEV Community: Hannes

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

What I did

The results

What each finding actually means

Why builders ship this way

The fixes, in the order I would do them

The caveats

See where your app stands

Self-hosting Google Fonts: the 15-minute fix for a classic GDPR finding

Why this is a GDPR issue at all

Find out if your app is affected

The fix: serve the fonts yourself

Two upgrades while you're at it

Verify from the outside

Common questions

Does font-display: swap or preconnect help legally?

What about Bootstrap, jQuery or icon CDNs?

Is this a fine risk or a warning-letter risk?

Row Level Security in Lovable apps: why your database might be public

Why your frontend talks to the database directly

What RLS actually does

Why AI-built apps get this wrong

Check your own app in two minutes

Locking it down

After the fix: verify from the outside

Common questions

Is the Supabase anon key a secret?

Will enabling RLS break my app?

How do I know whether someone already accessed my data?

Does `font-display: swap` or preconnect help legally?