Die 7 häufigsten Security-Lücken in Lovable & Bolt Apps

Du hast eine App mit Lovable oder Bolt gebaut. Sie funktioniert, sie sieht gut aus, deine Testnutzer sind begeistert. Aber unter der Oberfläche lauern Probleme, die du nicht siehst — weil sie sich nicht durch Abstürze oder Fehlermeldungen zeigen.

Sie zeigen sich, wenn jemand gezielt nach Schwachstellen sucht. Oder wenn persönliche Daten deiner Nutzer plötzlich öffentlich zugänglich sind.

Ich habe dutzende AI-gebaute Apps geprüft. Diese sieben Sicherheitslücken tauchen in fast jeder einzelnen auf. Nicht weil die Gründer schlampig waren — sondern weil AI-Tools diese Probleme systematisch produzieren.

Lücke 1: Offene Supabase-Tabellen

Was das bedeutet: Supabase ist die Datenbank, die Lovable und Bolt standardmäßig verwenden. Jede Tabelle hat eine Sicherheitsfunktion namens Row Level Security (RLS). Wenn RLS deaktiviert oder falsch konfiguriert ist, kann jeder mit der Supabase-URL auf alle Daten in dieser Tabelle zugreifen.

Wie häufig: In einer Untersuchung von 1.645 Lovable-Apps hatten 170 eine Schwachstelle, über die persönliche Daten offenlagen. Das sind über 10 %.

Was passieren kann: Ein Angreifer findet deine Supabase-URL (die oft im Frontend-Code steht), fragt die Tabelle ab und bekommt alle Nutzerdaten: Namen, E-Mails, vielleicht Adressen oder Zahlungsinformationen.

Wie du es prüfst: Öffne das Supabase-Dashboard, gehe zu Authentication > Policies. Wenn bei einer Tabelle "No policies created" steht und RLS aktiviert ist, blockiert Supabase standardmäßig alle Zugriffe. Wenn RLS deaktiviert ist, ist die Tabelle offen.

Wie es gefixt wird: Für jede Tabelle eine RLS-Policy erstellen, die genau definiert: Wer darf lesen? Wer darf schreiben? Wer darf löschen? Das dauert pro Tabelle wenige Minuten — aber es muss korrekt gemacht werden.

Lücke 2: API-Keys im Quellcode

Was das bedeutet: Deine App kommuniziert mit externen Diensten: Supabase, Stripe, SendGrid, OpenAI. Jeder dieser Dienste hat einen API-Key — ein Passwort, das den Zugang ermöglicht. AI-Tools schreiben diese Keys gerne direkt in den Quellcode.

Warum das ein Problem ist: Wenn dein Code auf GitHub liegt (und Lovable exportiert nach GitHub), kann jeder diese Keys finden. Ein Stripe Secret Key erlaubt es, Zahlungen auszulösen. Ein Supabase Service Key umgeht alle RLS-Policies.

Wie häufig: Fast jede AI-gebaute App, die ich geprüft habe, hatte mindestens einen Key im Code. Oft sind es drei oder mehr.

Wie du es prüfst: Suche in deinem Code nach typischen Mustern: sk_live_, sk_test_, supabase, apikey, secret. Wenn du Ergebnisse findest, die wie lange Zeichenketten aussehen, hast du hartcodierte Secrets.

Wie es gefixt wird: Alle Keys in Umgebungsvariablen verschieben (.env-Datei lokal, Environment Variables beim Hosting-Provider). Dann den Code ändern, damit er die Keys aus den Umgebungsvariablen liest statt aus dem Code. Und: Kompromittierte Keys rotieren — den alten ungültig machen, einen neuen erstellen.

Lücke 3: Fehlende Autorisierung

Was das bedeutet: Authentifizierung prüft, ob jemand eingeloggt ist. Autorisierung prüft, ob dieser eingeloggte Nutzer das tun darf, was er gerade versucht. AI-Tools implementieren oft nur die erste Hälfte.

Ein Beispiel: Deine App zeigt Projekte an unter /projekte/123. Nutzer A ist eingeloggt und sieht sein Projekt. Was passiert, wenn Nutzer A die URL auf /projekte/456 ändert — das Projekt von Nutzer B? Wenn die Antwort "er sieht es" ist, fehlt Autorisierung.

Wie häufig: Bei der Mehrheit der Apps, die ich prüfe, kann ein eingeloggter Nutzer auf Daten anderer Nutzer zugreifen. Das ist die häufigste übersehene Lücke.

Wie du es prüfst: Erstelle zwei Testaccounts. Logge dich mit Account A ein, kopiere die URL einer Seite mit Daten. Logge dich mit Account B ein, füge die URL ein. Siehst du die Daten von Account A? Dann fehlt Autorisierung.

Wie es gefixt wird: Jeder API-Endpunkt und jede Datenbankabfrage muss prüfen: Gehören diese Daten dem aktuellen Nutzer? Das bedeutet: WHERE user_id = aktuellerNutzer in jeder Abfrage. Klingt einfach, muss aber konsequent umgesetzt werden.

Lücke 4: Server-Side Request Forgery (SSRF)

Was das bedeutet: Dein Server lässt sich dazu bringen, Anfragen an interne Systeme zu schicken, die von außen nicht erreichbar sein sollten. Ein Angreifer kann dadurch auf interne APIs, Metadaten-Dienste oder andere Server in deiner Infrastruktur zugreifen.

Wie häufig: Die Sicherheitsfirma Tenzai testete 2025 fünf große Vibe-Coding-Tools. Jedes einzelne produzierte SSRF-Schwachstellen. Ausnahmslos.

Warum das passiert: Wenn deine App URLs verarbeitet — zum Beispiel um eine Vorschau zu generieren oder ein Bild zu laden — prüft AI-generierter Code selten, ob die URL auf einen erlaubten Dienst zeigt. Ein Angreifer kann statt einer normalen URL eine interne Adresse angeben.

Wie es gefixt wird: Eingabe-Validierung für alle URLs, die der Server abruft. Whitelisting erlaubter Domains. Blockierung von internen IP-Bereichen und Metadaten-Endpunkten.

Lücke 5: Fehlende Security-Headers

Was das bedeutet: Security-Headers sind Anweisungen, die dein Server an den Browser schickt. Sie sagen dem Browser: "Lade keine Skripte von fremden Seiten" (Content-Security-Policy), "Erlaube kein Einbetten in iFrames" (X-Frame-Options), "Erzwinge HTTPS" (Strict-Transport-Security).

Wie häufig: Null von 15 getesteten Vibe-Coding-Apps hatten Security-Headers implementiert. Null.

Warum das ein Problem ist: Ohne diese Headers ist deine App anfällig für Cross-Site-Scripting (XSS), Clickjacking und andere Angriffe, die moderne Browser eigentlich verhindern könnten — wenn du sie darum bittest.

Wie es gefixt wird: Je nach Hosting-Provider und Framework werden Security-Headers in der Server-Konfiguration oder in Middleware gesetzt. Für Vercel ist das eine vercel.json-Datei, für Netlify ein _headers-File. Fünf Zeilen Konfiguration — aber die müssen da sein.

Lücke 6: SQL-Injection und unsichere Datenbankabfragen

Was das bedeutet: Wenn Nutzereingaben ungefiltert in Datenbankabfragen landen, kann ein Angreifer die Abfrage manipulieren. Statt seinen Namen einzugeben, gibt er einen Datenbank-Befehl ein — und die Datenbank führt ihn aus.

Ein einfaches Beispiel: Ein Suchfeld, das den Suchbegriff direkt in eine SQL-Abfrage einbaut. Statt "Projektname" gibt jemand '; DROP TABLE projekte; -- ein. Wenn die Abfrage nicht geschützt ist, wird die Tabelle gelöscht.

Wie häufig: Supabase schützt über seinen Client davor, wenn du die Standard-API nutzt. Aber sobald du eigene Server-Funktionen schreibst — und AI-Tools tun das häufig — fällt dieser Schutz weg.

Wie es gefixt wird: Prepared Statements verwenden. Nie Nutzereingaben direkt in Queries einbauen. Input-Validierung auf Server-Seite. Das sind Grundlagen, die ein erfahrener Entwickler automatisch implementiert — AI-Tools aber nicht.

Lücke 7: Fehlende Rate-Limits

Was das bedeutet: Deine API-Endpunkte akzeptieren unbegrenzt viele Anfragen. Ein Angreifer kann tausende Login-Versuche pro Sekunde durchführen (Brute-Force), tausende E-Mails über dein Kontaktformular verschicken oder deinen Server durch schiere Masse an Anfragen überlasten.

Wie häufig: Ich habe noch keine AI-gebaute App gesehen, die Rate-Limiting implementiert hatte. Keine einzige.

Warum das passiert: Rate-Limiting ist kein Feature, das du siehst. Deine App funktioniert ohne es genauso gut — bis jemand es ausnutzt.

Wie es gefixt wird: Auf Server-Ebene oder als Middleware wird definiert: Maximal X Anfragen pro Minute pro IP-Adresse. Für Login-Endpunkte strenger (z.B. 5 Versuche pro Minute), für öffentliche Seiten lockerer. Die meisten Hosting-Provider und Frameworks bieten eingebaute Lösungen dafür.

Was diese Lücken gemeinsam haben

Alle sieben Lücken teilen drei Eigenschaften:

Sie sind unsichtbar. Du siehst sie nicht, wenn du deine App benutzt. Alles funktioniert — bis jemand gezielt nach Schwächen sucht.

Sie sind systematisch. Es sind nicht zufällige Fehler. AI-Tools produzieren diese Probleme konsistent, weil sie auf Funktionalität optimieren, nicht auf Sicherheit.

Sie sind behebbar. Keine dieser Lücken erfordert einen Neubau. Ein erfahrener Entwickler schließt sie in Tagen, nicht Wochen. In meinem Artikel Vibe Code Cleanup: Was ein Developer mit deinem AI-Code macht beschreibe ich den genauen Ablauf.

Wie du jetzt vorgehst

Du musst kein Sicherheitsexperte werden. Du musst nur zwei Dinge tun:

1. Prüfe, was du selbst prüfen kannst. Die Tests bei Lücke 1, 2 und 3 kannst du selbst durchführen. Das dauert 30 Minuten und gibt dir ein erstes Bild.

2. Lass den Rest professionell prüfen. SSRF, Security-Headers, SQL-Injection und Rate-Limiting erfordern technisches Know-how. Ein professioneller Security-Audit findet in ein bis zwei Tagen alles — und du bekommst einen klaren Plan, was zu tun ist.

Willst du wissen, welche dieser Lücken deine App hat? Schick mir den Link. 30 Minuten Erstgespräch, kostenlos, ohne Verpflichtung.

Erstgespräch vereinbaren