Is your Lovable app GDPR compliant? The 15-point checklist

You built your app in an afternoon with Lovable. It works, it looks good, people are signing up. Then someone asks: "Is this even GDPR compliant?" — and you realize you have no idea.

This is the checklist we run on every app our scanner sees. All 15 points come from real findings on real vibe-coded apps. None of this is legal advice, but every point links to a plain-language explanation of what it means and how to fix it in a Lovable project.

The two findings that should worry you most

1. Your database is readable without a login. Lovable apps usually ship with Supabase, and Supabase is secure *if* Row Level Security is configured. If it isn't, anyone with your project URL can read your users table — no password needed. This is the single most serious finding we see, and it turns into a reportable data breach the moment real user data is in there. What it means and how to fix it →

2. An admin key in your frontend code. The anon key belongs in the browser; the service_role key never does. AI builders sometimes paste the wrong one. With a service key, a stranger has full write access to everything. Check yours →

The consent traps

Most EU privacy fines against small companies are not about hackers — they are about tracking users before asking.

• Tracking loads before anyone could consent. If Google Analytics, Meta Pixel or similar fires on page load, a cookie banner underneath does not help you — the request already happened. Details →
• Tracking cookies set without consent. Same rule (§ 25 TDDDG), different symptom. Details →
• Third-party trackers in general need a legal basis under Art. 6 GDPR — "the template included it" is not one. Details →
• Google Fonts loaded from Google's servers. A German court decision made this famous: loading fonts from fonts.googleapis.com transmits visitor IPs to Google. Self-hosting the font files fixes it in minutes. Details →

The paperwork Germany actually enforces

• Imprint (Impressum). If your app targets the German market commercially, § 5 DDG requires one — and it is the easiest thing for a competitor to report. Details →
• Privacy policy. Art. 13 GDPR requires you to explain what data you process before you process it. A Lovable app with a signup form and no privacy policy is visibly non-compliant to anyone who checks. Details →

The technical hygiene layer

These are Art. 32 GDPR ("appropriate technical measures") and standard security headers. Individually small, together they are what a professional review looks at first:

• Resources loaded over unencrypted connections
• Source maps publicly accessible — your readable source code, one URL away
• No Content-Security-Policy
• No HSTS
• No clickjacking protection
• No nosniff header

Headers are genuinely quick wins on Lovable: they are set once at the hosting layer and apply to every page.

The one people forget

Accessibility (BFSG). Since June 2025, the Barrierefreiheitsstärkungsgesetz applies to many consumer-facing digital products in Germany. Basic gaps — missing alt texts, no keyboard navigation, insufficient contrast — are now a compliance topic, not just good manners. Details →

How to work through this

Fix order that makes sense in practice:

1. Today: open database, exposed keys — these are breaches waiting to happen. 2. This week: consent traps — remove or gate every tracker, self-host fonts. 3. Before you promote the app: imprint, privacy policy. 4. Next quiet afternoon: security headers, source maps, accessibility basics.

Or let the scanner do the reading: it checks all 15 points passively — no login, no agent installed, nothing stored — and gives you the findings in about a minute.