Ik heb de afgelopen drie maanden apps gecontroleerd die klanten naar ons brachten nadat zij hun MVP's hadden gebouwd op Lovable. Het patroon is zo consistent dat het bijna saai is: blootgestelde Supabase service keys in client bundles, nul RLS-beleidsregels, hardcoded OpenAI- en Stripe-geheimen die zomaar in de JavaScript zitten voor iedereen met DevTools om op te pikken. Elke keer.

Dit is geen aanval op Lovable. Het platform is echt indrukwekkend voor prototyping. Maar er zit een canyon-grote kloof tussen "werkende demo" en "productie-klaar application", en Lovable vertelt je niet over het grootste deel van wat in die kloof zit. Een onderzoeker uit de community controleerde 50 door AI gebouwde apps en vond dezelfde vijf beveiligingsfouten in bijna allemaal. Een ander ontwikkelaar scande 200+ vibe-coded sites en vond een gemiddelde beveiligingsscore van 52 op de 100 -- waarbij de ergste overtreders zich concentreerden op Lovable + Supabase-applicaties in het bijzonder.

Laten we elke kwetsbaarheid doorlopen die we blijven vinden, waarom Lovable's eigen tooling ze mist, en precies hoe je elk ervan oplost.

Inhoudsopgave

Lovable Security Vulnerabilities 2026: Exposed Keys, Missing RLS, and What Audits Catch

De architectuur die het probleem creëert

Om te begrijpen waarom Lovable-apps onevenredig getroffen zijn, moet je de architectuur begrijpen. Lovable gebruikt uitsluitend Supabase als backend. Er is geen Firebase-optie, geen custom backend, geen ontsnappingsroute. Wanneer je iets in Lovable bouwt, genereert het een React-frontend die rechtstreeks met Supabase's REST API praat via de client library.

Supabase is zodanig ontworpen dat de anon-sleutel veilig publiek kan worden blootgesteld -- het is in feite een projectidentificatie. Het beveiligingsmodel is volledig afhankelijk van Row Level Security (RLS)-beleidsregels op PostgreSQL-niveau. Zien we het als volgt:

Component Bedoeld om openbaar te zijn? Wat beschermt je
Supabase URL Ja Niets nodig -- het is gewoon een URL
anon-sleutel Ja RLS-beleidsregels op elke tabel
service_role-sleutel Absoluut niet Moet alleen server-side blijven
Database-verbindingsstring Nee Nooit blootstellen aan clients

Het probleem is dat Lovable's AI code genereert die alle deze hetzelfde behandelt. Het zet de anon-sleutel in de frontend (prima), maar creëert vervolgens tabellen zonder RLS in te schakelen (catastrofaal). Soms zet het ook de service_role-sleutel in client code (game over). Zoals één developer op Reddit zei: "AI doet wat je vraagt. Het denkt gewoon nooit na over wat je niet hebt gevraagd."

Kwetsbaarheid 1: Blootgestelde Supabase-sleutels in client-code

Elke Lovable-app initialiseert de Supabase-client ongeveer zo:

// src/integrations/supabase/client.ts
import { createClient } from '@supabase/supabase-js'

const supabaseUrl = 'https://xyzcompany.supabase.co'
const supabaseAnonKey = 'eyJhbGciOiJIUzI1NiIs...'

export const supabase = createClient(supabaseUrl, supabaseAnonKey)

De anon-sleutel die hier staat is prima -- dat is met opzet. Het probleem komt in twee vormen voor:

Het `service_role`-sleutellek

We hebben Lovable-gegenereerde code gezien waar de service_role-sleutel in client-side code terecht komt, meestal omdat iemand de AI met iets zoals "maak dit werken ook al blokkeert RLS het" heeft opgesteld. De oplossing van de AI? Gebruik de admin-sleutel. De service_role-sleutel omzeilt alle RLS-beleidsregels volledig. Als het in je frontend bundle zit, kan iedereen het extraheren en volledige lees-/schrijftoegang tot je hele database hebben.

Het `.env`-bestand gepleegd bij Git

Lovable-projecten die naar GitHub zijn uitgeplaatst hebben vaak .env-bestanden die in de repository zijn gepleegd. Zelfs als de repo nu privé is, als het ooit openbaar was -- zelfs voor een minuut -- die sleutels zijn gecompromitteerd. Bots scrapen GitHub constant voor precies dit patroon.

Hoe te controleren:

# Zoek in je codebase naar service_role-sleutels
grep -r "service_role" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.env" .

# Controleer git-geschiedenis op per ongeluk gepleegde geheimen
git log --all -p -- '*.env'

Hoe te repareren: Verwijder de service_role-sleutel onmiddellijk uit alle client-code. Roteer de sleutel in je Supabase-dashboard (Instellingen → API). Gebruik de sleutel alleen in server-side code -- Supabase Edge Functions, een Next.js API-route, of een aparte backend.

Kwetsbaarheid 2: Ontbrekende of verbroken RLS-beleidsregels

Dit is de grote. CVE-2025-48757 blootgestelde 303 kwetsbare eindpunten over 170+ Lovable-gebouwde apps. Volgens Escape.tech betreffen 83% van de blootgestelde Supabase-databases RLS-misconfiguraties.

Dit is wat er standaard gebeurt wanneer Lovable een tabel creëert:

-- Wat Lovable vaak genereert
CREATE TABLE user_profiles (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID REFERENCES auth.users(id),
  full_name TEXT,
  email TEXT,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Merk op wat ontbreekt? RLS is niet ingeschakeld.
-- Deze tabel is volledig leesbaar en schrijfbaar door iedereen met de anon-sleutel.

Zonder RLS is je Supabase-database in wezen een publieke API. Iedereen die je project-URL en anon-sleutel kent -- beide zitten in je frontend-code -- kan dit doen:

// De browser-console van een aanvaller
const { data } = await supabase.from('user_profiles').select('*')
// Retourneert ALLE gebruikergegevens

await supabase.from('user_profiles').delete().neq('id', '')
// Verwijdert alles

Drie soorten RLS-falen

Foutmodus Wat gebeurt er Ernst
RLS helemaal niet ingeschakeld Volledige openbare lees-/schrijftoegang Kritiek
RLS ingeschakeld maar geen beleidsregels gedefinieerd Niemand kan iets openen (app breekt) Hoog (dwingt devs om RLS uit te schakelen)
Veel te toegestane beleidsregels (bijv. USING (true)) Ziet er veilig uit, is eigenlijk niet Hoog

De derde is bijzonder sinister. We hebben Lovable zien genereren beleidsregels zoals deze wanneer opgesteld om "de permissies te repareren":

CREATE POLICY "Allow all access" ON user_profiles
  FOR ALL
  USING (true)
  WITH CHECK (true);

Dit is RLS-theater. Het is ingeschakeld, het heeft een beleid, en het doet eigenlijk helemaal niets.

Hoe een correct beleid eruit ziet:

-- Schakel RLS in
ALTER TABLE user_profiles ENABLE ROW LEVEL SECURITY;

-- Gebruikers kunnen alleen hun eigen profiel lezen
CREATE POLICY "Users read own profile" ON user_profiles
  FOR SELECT
  USING (auth.uid() = user_id);

-- Gebruikers kunnen alleen hun eigen profiel bijwerken
CREATE POLICY "Users update own profile" ON user_profiles
  FOR UPDATE
  USING (auth.uid() = user_id)
  WITH CHECK (auth.uid() = user_id);

-- Alleen geverifieerde gebruikers kunnen invoegen, en alleen voor zichzelf
CREATE POLICY "Users insert own profile" ON user_profiles
  FOR INSERT
  WITH CHECK (auth.uid() = user_id);

Lovable Security Vulnerabilities 2026: Exposed Keys, Missing RLS, and What Audits Catch - architecture

Kwetsbaarheid 3: Hardcoded geheimen van derden

Deze doet me elke keer winnen. We vinden regelmatig OpenAI API-sleutels (sk-...), Stripe secret keys (sk_live_...), SendGrid-sleutels, en andere referenties hardcoded rechtstreeks in React-componenten.

// Werkelijk gevonden in een Lovable-gegenereerd bestand
const openai = new OpenAI({
  apiKey: 'sk-proj-abc123...',  // Dit zit in je browser bundle
})

Iedereen die DevTools opent, naar het Sources-tabblad gaat, en naar sk- of sk_live zoekt krijgt je sleutels. Aanvallers automatiseren dit. Er zijn bots die JavaScript-bundles specifiek scannen naar deze patronen.

De financiële gevolgen zijn reëel. We hadden een klant naar ons komen nadat een blootgestelde OpenAI-sleutel resulteerde in $4.200 aan kosten over een weekend. Stripe secret keys zijn erger -- ze geven volledige toegang om terugbetalingen te verwerken, klantgegevens te bekijken, en abonnementen aan te passen.

De reparatie: Verplaats alle third-party API-aanroepen naar server-side functies. Supabase Edge Functions werken hier goed voor:

// supabase/functions/openai-proxy/index.ts
import { serve } from 'https://deno.land/std@0.168.0/http/server.ts'

serve(async (req) => {
  const { prompt } = await req.json()
  
  const response = await fetch('https://api.openai.com/v1/chat/completions', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${Deno.env.get('OPENAI_API_KEY')}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      model: 'gpt-4o',
      messages: [{ role: 'user', content: prompt }],
    }),
  })
  
  return new Response(JSON.stringify(await response.json()))
})

Kwetsbaarheid 4: Ontbrekende beveiligingsheaders

De scan van 200+ sites vond dat de meeste Lovable-uitgeplaatste apps met nul beveiligingsheaders worden verscheept. Geen Content-Security-Policy. Geen Strict-Transport-Security. Geen X-Frame-Options. Geen X-Content-Type-Options.

Dit kan lijken op iets minors vergeleken met een blootgestelde database, maar ontbrekende headers maken het volgende mogelijk:

  • Clickjacking -- je app kan worden ingebed in een iframe op een kwaadaardige site
  • XSS-versterking -- zonder CSP hebben injecteerde scripts geen beperkingen
  • MIME type sniffing-aanvallen -- browsers kunnen bestanden als uitvoerbare code interpreteren
  • Downgrade-aanvallen -- zonder HSTS kan verkeer worden onderschept
Header Doel Lovable-standaard
Content-Security-Policy Voorkomt XSS, controleert resource-laden Ontbreekt
Strict-Transport-Security Dwingt HTTPS af Ontbreekt
X-Frame-Options Voorkomt clickjacking Ontbreekt
X-Content-Type-Options Voorkomt MIME sniffing Ontbreekt
Referrer-Policy Controleert referrer-informatie Ontbreekt
Permissions-Policy Controleert browserfuncties Ontbreekt

Kwetsbaarheid 5: Geen invoervalidatie of sanitatie

Lovable-gegenereerde formulieren sturen doorgaans gebruikersinvoer rechtstreeks naar Supabase zonder enige validatie. Geen lengtecontroles, geen typevalidatie, geen sanitatie van HTML of SQL-aanverwante inhoud.

Hoewel Supabase's PostgREST-laag traditionele SQL-injectie voorkomt, resulteert het gebrek aan invoervalidatie nog steeds in:

  • Opgeslagen XSS via niet-gesaniteerde HTML in tekstgebieden
  • Denial of service via extreem grote payloads
  • Business logic-misbruik (bijv. negatieve hoeveelheden, prijzen van $0,00)
  • Gegevensbeschadiging van onverwachte types

Wat Lovable's ingebouwde beveiligingsscan werkelijk controleert

Lovable heeft wel een ingebouwde "Security Scan"-functie die toegankelijk is via het dashboard. Eerlijke vermelding waar het verschuldigd is -- het bestaat. Maar dit is wat het werkelijk controleert versus wat niet:

Controle Ingebouwde scan Productie-audit
Basis syntaxisfouten ✅ ✅
Bekende afhankelijkheid CVE's Gedeeltelijk ✅
Hardcoded geheimen in bron ❌ ✅
RLS ingeschakeld op alle tabellen ❌ ✅
RLS-beleid juistheid ❌ ✅
Service role-sleutelblootstelling ❌ ✅
Beveiligingsheaders ❌ ✅
Invoervalidatie dekking ❌ ✅
Auth-configuratiebeoordeling ❌ ✅
Storage bucket-beleidsregels ❌ ✅
Rate limiting ❌ ✅
Cookie-beveiligingsvlaggen ❌ ✅

De ingebouwde scan is oppervlakkig op zijn best. Het zal de kwetsbaarheden die werkelijk misbruikt worden niet opvangen.

Wat een productie-audit oppikt dat het platform niet doet

Wanneer we een productiebeveiliging audit doen voor een klant die op Lovable heeft gebouwd, dit is wat we doorgaans vinden en repareren. Dit is de echte lijst, van werkelijke aanbestedingen:

Database-laag

  • Tabellen met RLS uitgeschakeld (gemiddeld: 60-70% van tabellen)
  • RLS-beleidsregels met true als voorwaarde
  • Ontbrekende beleidsregels voor DELETE-operaties (devs vergeten delete)
  • Geen beleidsregels op junction/join-tabellen
  • Storage buckets ingesteld op openbaar zonder uploadbeperkingen
  • Ontbrekende indexen op kolommen gebruikt in RLS-beleid voorwaarden (prestaties + beveiliging)

Verificatie-laag

  • Zwakke JWT-geheimen (Supabase-standaardinstellingen zijn prima, maar soms veranderen mensen ze)
  • Ontbrekende vereisten voor e-mailbevestiging
  • Geen rate limiting op auth-eindpunten
  • Wachtwoord reset-flows zonder juiste token-verloop
  • OAuth omleidings-URL-misconfiguraties

Client-code laag

  • service_role-sleutels in frontend-bundles
  • Third-party API-sleutels hardcoded in componenten
  • .env-bestanden gepleegd in git-geschiedenis
  • Debug-logging die gebruikersgegevens in de console blootstelt
  • Foutmeldingen die database-schemaïnformatie lekken

Infrastructure-laag

  • Geen beveiligingsheaders wat dan ook
  • Cookies zonder Secure, HttpOnly, of SameSite-vlaggen
  • Blootgestelde serverversie-informatie
  • Geen CORS-configuratie (accepteert aanvragen van elke origin)
  • Afhankelijkheden met bekende CVE's die maandenlang niet zijn bijgewerkt

Een typische Lovable-app die we controleren heeft 15-25 reparaties nodig voordat het productie-klaar is. De meeste nemen minder dan een uur elk, maar je moet weten dat ze bestaan eerst.

Het Moltbook-incident: een real-world casestudy

In januari 2026 ontdekten beveiligingsonderzoekers bij Wiz dat Moltbook -- een AI-sociaal netwerk -- zijn volledige Supabase-database blootgesteld had door een misconfigureerde client. De anon-sleutel zat in de frontend JavaScript (normaal), maar RLS was niet geconfigureerd op kritieke tabellen (catastrofaal).

Het resultaat? 1,5 miljoen API-sleutels waren toegankelijk. Niet alleen gebruikersgegevens -- werkelijke API-sleutels behorend tot gebruikers die hun OpenAI-, Anthropic- en andere accounts hadden verbonden. Volledige lees- en schrijftoegang tot elke tabel. Een onderzoeker kon de volledige database doorbladeren door gewoon de Supabase-client in een browser-console te gebruiken.

De openbaarmaking timeline was strak -- Moltbook's onderhouder repareerde de kritieke tabellen binnen uren na contact. Maar het schadeboekvenster was onbekend. Hoe lang was de database blootgesteld voordat iemand controleerde? Niemand weet.

Dit is het Lovable + Supabase-patroon dat op schaal uitvoert. Het platform genereert werkende code. Het genereert gewoon geen veilige code.

Een Lovable-app repareren voordat je naar productie gaat

Hier is de checklist die we gebruiken. Je kunt het meeste hiervan zelf doen als je comfortabel bent met SQL en Supabase's dashboard:

Stap 1: Controleer elke tabel op RLS

-- Voer dit uit in Supabase SQL Editor om tabellen zonder RLS te vinden
SELECT schemaname, tablename, rowsecurity 
FROM pg_tables 
WHERE schemaname = 'public';

Elke tabel waar rowsecurity false is, heeft onmiddellijke aandacht nodig.

Stap 2: Zoek je codebase af op geheimen

# Zoek naar veel voorkomende geheimen patronen
grep -rn 'sk-' --include='*.ts' --include='*.tsx' --include='*.js' .
grep -rn 'sk_live' --include='*.ts' --include='*.tsx' --include='*.js' .
grep -rn 'service_role' --include='*.ts' --include='*.tsx' --include='*.js' .
grep -rn 'SUPABASE_SERVICE' --include='*.ts' --include='*.tsx' --include='*.env' .

Stap 3: Schrijf juiste RLS-beleidsregels

Voor elke tabel, schrijf expliciete beleidsregels voor SELECT, INSERT, UPDATE, en DELETE. Gebruik altijd auth.uid()-controles:

-- Template voor een door gebruiker eigendom tabel
ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;

CREATE POLICY "select_own" ON your_table FOR SELECT
  USING (auth.uid() = user_id);

CREATE POLICY "insert_own" ON your_table FOR INSERT
  WITH CHECK (auth.uid() = user_id);

CREATE POLICY "update_own" ON your_table FOR UPDATE
  USING (auth.uid() = user_id)
  WITH CHECK (auth.uid() = user_id);

CREATE POLICY "delete_own" ON your_table FOR DELETE
  USING (auth.uid() = user_id);

Stap 4: Verplaats API-aanroepen server-side

Elke third-party API-aanroep die een secret key vereist, moet in een Supabase Edge Function of aparte backend draaien. Dit is niet onderhandelbaar.

Stap 5: Voeg beveiligingsheaders toe

Als je naar Netlify, Vercel of Cloudflare uitplaatst, voeg headers toe via hun configuratie. Voor Netlify, maak een _headers-bestand. Voor een Next.js-app, voeg ze toe in next.config.js.

Stap 6: Overweeg een frameworkmigratie

Voor alles voorbij een MVP, raden we vaak aan Lovable-gegenereerde React-code in een juiste Next.js- of Astro-project te migreren. Dit geeft je server-side API-routes, juiste omgevingsvariabele-afhandeling, middleware voor auth-controles, en een echte build pipeline. Het is vooraan meer werk, maar de beveiligingshouding is dag en nacht.

Tools voor geautomatiseerde scans

Verschillende tools zijn speciaal ontstaan voor het controleren van door AI gemaakte apps:

Gereedschap Wat het controleert Kosten
Ship Safe (npx ship-safe audit .) RLS, service_role blootstelling, storage buckets, afhankelijkheid CVE's Gratis, open-source
Vibe App Scanner (vibeappscanner.com) Volledige beveiligingsscan voor door AI gebouwde apps Gratis startscan
Snyk Afhankelijkheid kwetsbaarheden, code scanning Gratis tier beschikbaar
Supabase Dashboard → Auth → Policies Visuele RLS-beleid editor Inbegrepen bij Supabase

Ship Safe is wat ik zou beginnen. Het draait lokaal, niets verlaat je machine, en het is speciaal gebouwd voor de Supabase-misconfiguraties die AI-tools creëren:

npx ship-safe audit .

Het zal uitgeschakelde RLS, service_role-sleutels in client-code, open storage buckets, zwakke auth-config, hardcoded geheimen, en afhankelijkheid CVE's markeren.

Veelgestelde vragen

Is de Supabase anon-sleutel veilig om bloot te stellen in frontend-code? Ja -- maar alleen als je juiste RLS-beleidsregels op elke tabel hebt. De anon-sleutel is bedoeld om openbaar te zijn. Het is als een projectidentificatie. De beveiliging komt van RLS-beleidsregels die bepalen wat die sleutel werkelijk kan openen. Zonder RLS geeft de anon-sleutel iedereen volledige databasetoegang.

Schakelt Lovable RLS standaard in wanneer tabellen worden aangemaakt? Nee. Vanaf begin 2026 creëert Lovable Supabase-tabellen zonder RLS standaard in te schakelen. Dit is de enige grootste beveiligingskloof in het platform. Je moet handmatig RLS inschakelen en beleidsregels voor elke tabel schrijven nadat Lovable ze genereert. CVE-2025-48757 was een direct gevolg van dit standaardgedrag.

Hoe controleer ik of mijn Lovable-app blootgestelde geheimen heeft? Open je uitgeplaatste app in een browser, open DevTools (F12), ga naar het Sources-tabblad, en zoek over alle bestanden naar sk-, sk_live, service_role, en alle API-sleutelvoorvoegsels voor services die je gebruikt. Voer ook npx ship-safe audit . lokaal uit op je codebase voor geautomatiseerde detectie.

Kan Lovable's ingebouwde beveiligingsscan RLS-problemen opvangen? De ingebouwde beveiligingsscan controleert niet op RLS-misconfiguraties, ontbrekende beleidsregels, of blootgestelde service keys. Het dekt basis code-niveau problemen, maar mist de database- en infrastructuurkwetsbaarheden die het hoogste risico vertegenwoordigen. Je hebt externe tooling nodig voor een echte beveiligingsbeoordeling.

Wat gebeurde er met CVE-2025-48757? CVE-2025-48757 was een kwetsbaarheidsopenbaarmking die 303 kwetsbare API-eindpunten over 170+ apps gebouwd met Lovable identificeerde. De root cause was Lovable creëerde Supabase-tabellen zonder RLS in te schakelen, waardoor volledige databases voor iedereen met de openbaar beschikbare anon-sleutel toegankelijk werden. Het belichtte de systemische aard van het probleem.

Moet ik van Lovable migreren voor productie-apps? Niet noodzakelijk. Lovable is uitstekend voor snelle prototyping en het bouwen van MVP's. Maar de gegenereerde code heeft aanzienlijke beveiligingsverharding nodig voordat productiegebruik. Veel teams gebruiken Lovable om de initiële versie te bouwen, dan migreren naar een juist framework met server-side rendering, juiste geheimenbeheer, en beveiligingsmiddleware. Dat is een redelijke benadering.

Hoeveel tijd kost het om een Lovable-app voor productie veilig te stellen? Voor een typische app met 10-20 tabellen, verwacht 2-5 dagen gericht werk om alle RLS-beleidsregels te controleren, geheimen server-side te verplaatsen, beveiligingsheaders toe te voegen, invoer te valideren, en alles te testen. Meer complexe apps met storage buckets, real-time abonnementen, en meerdere gebruikersrollen kunnen langer duren. Het is niet onoverkomelijk, maar het is ook niet een taak van één uur.

Zijn andere AI-app builders zoals Bolt of Cursor veiliger dan Lovable? De scan van 200+ sites vond dat beveiligingskwetsbaarheden zich concentreerden in Lovable + Supabase-applicaties in het bijzonder. Bolt, Replit, en Cursor/Cline-gebaseerde apps toonden hetzelfde patroon van RLS-misconfiguraties niet. Dat betekent niet dat ze volkomen veilig zijn -- alle door AI gegenereerde code moet worden beoordeeld -- maar de Lovable-specifieke Supabase-integratie creëert een unieke klasse van databaseblootstelling-kwetsbaarheden die andere gereedschappen niet hebben.