Blog · 2026-08-06
Is your Lovable app GDPR compliant? The 15-point checklist
By the howsafeismyapp team
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.comtransmits 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:
- Today: open database, exposed keys — these are breaches waiting to happen.
- This week: consent traps — remove or gate every tracker, self-host fonts.
- Before you promote the app: imprint, privacy policy.
- 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.
Common questions
Does GDPR apply to me if I'm not in the EU?
Yes, if people in the EU use your app (Art. 3(2) GDPR). The law follows the users, not your location. The security-related points on this list matter everywhere regardless.
Isn't Lovable responsible for making my app compliant?
No. Lovable provides the tool; you are the operator (the "controller" in GDPR terms). What the generated code does when a visitor loads your app is legally your responsibility — which is exactly why this checklist exists.
Can a small side project really get in trouble?
The realistic first contact is not a regulator's fine but a warning letter (Abmahnung) from a competitor or a damages claim from a visitor — both of which target easily visible findings like missing legal pages and fonts loaded from Google. Small does not mean invisible.