Lovable-apps lekken data: zo check je Supabase RLS

Is Lovable veilig? De bouwer wel, de database vaak niet

Lovable maakt van een beschrijving in gewone taal een werkende webapp. Het Hamburgse securitybedrijf Crissy Field zocht in het webarchief Common Crawl 159.041 Lovable-projecten op, van december 2025 tot en met september 2026. Daarvan gebruikten er 34.545 de database Supabase (Crissy Field).

Bij 24.664 sites gingen er records mee zodra de pagina laadde, "without requiring a login or any other interaction". Dat hoeft geen lek te zijn: soms is die data bedoeld om te tonen. Met dezelfde key deden de onderzoekers daarna extra leesverzoeken, en kregen ze meer terug dan de pagina liet zien. Bij 7.403 van die 24.664 sites, zo'n 30 procent, vonden ze e-mailadressen, verspreid over 10.560 tabellen.

Crissy Field bracht het uit samen met Handelsblatt, dat er op 2 november over schreef (Handelsblatt). Techzine meldde het op 4 november (Techzine).

Paspoortnummers, chats en klantmails

Een Duits lifestyleforum had meer dan 80.000 profielen open staan, met naam, e-mailadres en geboortedatum, plus meer dan 200.000 chatberichten. Bij evenementenorganisatoren en restaurants lagen tienduizenden ticket- en maaltijdrecords, met telefoonnummers, adressen en betaalgegevens. Eén dienstverlener had ruim 1.000 records met gegevens uit identiteitsbewijzen, waaronder paspoortnummers. Bij een andere aanbieder waren 280.000 verstuurde klantmails leesbaar.

Of iemand die data misbruikte, kon Crissy Field niet vaststellen. Het eigen databaseproduct van Lovable viel buiten het onderzoek. De onderzoekers zijn ook eerlijk over hun 30 procent: een e-mailadres kan een openbaar contactadres of testdata zijn.

"The 30% figure should therefore not be read as a confirmed data leak rate."

Volgens het rapport legde Handelsblatt de bevindingen voor aan Lovable. Een reactie staat niet in het rapport, en ook Techzine meldt er geen. Wel wijst Crissy Field erop dat de voorwaarden van Lovable de verantwoordelijkheid voor de app en de data bij de klant leggen.

Waarom de key in je code geen lek is, en een tabel zonder RLS wel

In de broncode van zo'n app staat een Supabase-key. Dat is geen fout. De publishable key, en zijn voorganger de anon key, is volgens Supabase "safe to expose online" en komt alleen bij wat Row Level Security toestaat (Supabase). Row Level Security (RLS) is de regel per tabel die bepaalt wie welke rijen mag zien.

Daar zit het gat. Een tabel zonder RLS in een schema dat de API ontsluit (standaard public) is volgens de documentatie leesbaar én schrijfbaar voor elke rol met rechten erop (Supabase). In de standaardinstelling heeft de publieke key die rechten: op bestaande projecten krijgt een nieuwe tabel in public ze meteen. Dan kan iedereen met die key bij de tabel. En een view, een opgeslagen query die je als tabel aanspreekt, omzeilt RLS standaard.

Crissy Field noemt RLS niet bij naam; het rapport spreekt van fouten in toegangsrechten. De koppeling met RLS is onze lezing van de Supabase-documentatie.

Zo check je Supabase RLS in tien minuten

De snelste route is de Security Advisor in het Supabase-dashboard. Drie meldingen tellen hier (Supabase):

1. 0013 rls_disabled_in_public, met de titel "Table publicly accessible". Een tabel zonder RLS. De oplossing is alter table <naam> enable row level security; en daarna policies. Zonder policy is de tabel ook voor je eigen app dicht, dus schrijf die meteen erbij.
2. 0024 permissive_rls_policy: een policy die met USING (true) alles doorlaat.
3. 0010 security_definer_view: een view die de policies van de tabel eronder negeert. Met security_invoker = true gelden ze weer.

In de SQL-editor vraag je select tablename, rowsecurity from pg_tables where schemaname = 'public'; op. Staat rowsecurity op false, dan ligt die tabel in de standaardinstelling open. Staat hij op true, kijk dan nog naar de policies (melding 0024). Zoek daarna in de frontendcode op sb_secret_. Een oude service_role-key herken je zo niet: plak elke key die met eyJ begint in een JWT-decoder en kijk of er "role": "service_role" in staat. Een secret key "bypasses every Row Level Security policy" en hoort nooit in de browser.

Vul hieronder per tabel in hoe hij staat.

Interactief

Check per tabel of je publieke key erbij kan

Per tabelDe regels

Kies per tabel hoe hij staat. Persoonsgegevens zijn namen, e-mailadressen, telefoonnummers, adressen, betaal- of ID-gegevens. Het blok zegt of de publieke key erbij kan. Weet je niet hoe een tabel staat, open dan de Security Advisor: die noemt per tabel of RLS ontbreekt of een policy te ruim is. Of kies Weet ik niet.

Staat de secret- of service_role-key ergens in je frontend?

NeeJaWeet ik niet

Zoek in de code van je frontend op sb_secret_. Een oude service_role-key vind je zo niet: plak elke key die met eyJ begint in een JWT-decoder en kijk of er "role": "service_role" in staat. Of vergelijk met de keys op de API keys-pagina. De publishable of anon key hoort wel in je frontend te staan.

0 van 1 tabel leesbaar met de publieke key, 1 onbekend

• Tabel 1

  Soort object, tabel 1

  TabelVieween opgeslagen query, geen echte tabel
  Row Level Security, tabel 1

  RLS uitgeen regels op de tabelRLS aan, geen policyRLS staat aan, er is nog geen regelRLS aan, policy using (true) voor anoniedereen mag alle rijen lezenRLS aan, policy op auth.uid()elke gebruiker ziet alleen zijn eigen rijenWeet ik niet
  Persoonsgegevens erin, tabel 1

  JaNeeWeet ik niet
  Onbekend: kijk in de Security Advisor

  De Security Advisor in het Supabase-dashboard loopt alle tabellen langs. Staat er "Table publicly accessible" (0013) of een waarschuwing over een te ruime policy (0024), dan ligt er iets open.

  Volgende stap. Open de Security Advisor, of vraag in de SQL-editor op welke tabellen in public RLS missen. Security Advisor openen.

  select tablename, rowsecurity
    from pg_tables
    where schemaname = 'public';

  In de Security Advisor: 0013 en 0024.

  Bron: Supabase, Database Advisors

Tabel toevoegen

Alleen regels uit de Supabase-docs, gecontroleerd op 5 november 2026. Het blok telt wat jij invult en kijkt niet in je project. Blok: AI Centrum Nederland.

De check kijkt niet in je project en volgt alleen de Supabase-docs, gecontroleerd op 5 november 2026. Crissy Field zet er zelf een grens bij.

"Automated checks are no substitute for a professional security assessment."

Persoonsgegevens gelekt? Dan geldt mogelijk de meldplicht

Onze duiding (AVG). Wie een Lovable-app inzet voor klanten of leden, is wat ons betreft de verwerkingsverantwoordelijke, niet Lovable. Lagen er persoonsgegevens open, dan kan dat een inbreuk zijn die je moet beoordelen. Artikel 33 van de AVG vraagt dan mogelijk een melding bij de Autoriteit Persoonsgegevens "zonder onredelijke vertraging en, indien mogelijk, uiterlijk 72 uur" na ontdekking (AVG, art. 33). Dat hoeft niet als een risico voor de betrokkenen niet waarschijnlijk is.

Bij een tabel met paspoortnummers is dat risico er duidelijk. Bij een lijst met nieuwsbriefadressen is de afweging lastiger. Die afweging hoort in je AI-governance, net als de vraag wie in je organisatie apps bouwt zonder dat iemand meekijkt. Met Copilot Code werd in oktober al duidelijk dat apps bouwen zonder programmeren gewoon wordt. Wie zo bouwt, stelt de rechten per tabel zelf in of laat ze openstaan.

Volgende Stap

Bouwen je collega's zelf apps met Lovable of Copilot? In de workshop vibe coding bouw je zelf een werkende tool met Claude, v0 en Lovable. Twijfel je over de beveiliging van een app die al live staat, neem contact op.

Headerbeeld: Lovable.