DEV Community: Hannes

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

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?