Verliert Deine Vibe-Gecodete App Daten und Frisst Sie Dein Budget?

Am Morgen nach dem Launch öffnest du dein Dashboard und erwartest deine ersten Nutzer. Stattdessen findest du eine Cloud-Rechnung mit drei zusätzlichen Nullen, oder schlimmer, eine Nachricht von einem Fremden, der dir mitteilt, dass deine gesamte Nutzertabelle in einem öffentlichen Telegram-Kanal liegt.

Das ist keine seltene Horrorgeschichte mehr. Es ist das stille, wiederkehrende Fehlermuster des „Vibe Codings” — echte Produkte zu bauen, indem man KI-Tools wie Claude Code, Cursor und Windsurf so lange promptet, bis die Oberfläche gut aussieht und die Funktion läuft. Diese Tools sind wirklich hervorragend darin, schnell funktionierenden Code zu schreiben. Was sie nicht automatisch gut können, ist wie ein Sicherheitsingenieur zu denken, weil du sie das nie darum gebeten hast.

Die Oberfläche kann produktionsreif wirken, während die Architektur darunter weit offensteht. Im Folgenden sind fünf Fehler, die wir am häufigsten sehen, wenn KI-unterstützte Codebasen auf das echte Internet treffen, warum jeder davon schnell teuer wird, und genau wie du sie vor der Veröffentlichung schließt.

Der unbequeme Teil: Keiner dieser fünf Fehler erfordert einen Hacker. Ein neugieriger Besucher, der in seinem Browser F12 drückt, ein gelangweilter Bot, der zufällige Domains scannt, oder ein einzelner vergessener Hintergrundtab reicht aus, um jeden davon auszulösen. Das macht sie so verbreitet — und so vermeidbar — in KI-generierten Codebasen.

Warum Vibe-Gecodete Apps Härter Getroffen Werden als Traditionell Gebaute

Wenn ein Entwickler eine API-Integration von Hand schreibt, ist Sicherheit eine bewusste Entscheidung im Moment: „Soll dieser Schlüssel auf dem Server oder dem Client liegen?” Wenn ein KI-Assistent denselben Code schreibt, optimiert er für „funktioniert das, wenn ich es teste”, nicht für „hält das stand, wenn ein Fremder es untersucht”.

Dieser Unterschied ist das gesamte Problem. KI-generierter Code läuft einwandfrei in der Vorschau, einwandfrei bei deiner Kundendemo, und läuft weiterhin einwandfrei bis zum Launch, wenn jemand mit nichts weiter als der F12-Konsole seines Browsers eine Fünf-Sekunden-Prüfung durchführt.

Fehler 1: Hartcodierte API-Schlüssel in Deinem Frontend-Code

Dies ist die häufigste Art, wie ein Gründer in der Frühphase mit einem leergeräumten OpenAI- oder Anthropic-Konto aufwacht.

Bittest du einen KI-Assistenten, „sich mit der OpenAI-API zu verbinden” oder „einen Supabase-Client hinzuzufügen”, schreibt er den Schlüssel oft direkt in eine React-Komponente, eine Next.js-Seite oder eine clientseitige .js-Datei, weil das der schnellste Weg ist, die Funktion zum Laufen zu bringen. Es kompiliert. Es funktioniert in der Vorschau. Du veröffentlichst es.

Das Problem ist, dass alles, was an den Browser gesendet wird, von jedem, der deine Website besucht, heruntergeladen werden kann. Ein Besucher drückt F12, öffnet den Tab Sources oder Network, und dein sk-...-Schlüssel oder dein Supabase-service_role-Schlüssel liegt dort im Klartext. Ein einziger offengelegter Schlüssel reicht oft aus, um ein ganzes Monatsbudget für KI in Minuten leerzuräumen, und wenn es dein service_role-Schlüssel ist, kann der Angreifer jede Berechtigung umgehen, die deine Datenbank eigentlich durchsetzen sollte.

So behebst du es tatsächlich:

• Rufe niemals eine kostenpflichtige oder privilegierte API direkt aus clientseitigem Code auf. Leite sie über einen Backend-Endpunkt oder eine Serverless-Funktion, die du kontrollierst.
• Speichere echte Geheimnisse in serverseitigen Umgebungsvariablen, niemals in etwas, das in den Frontend-Build gebündelt wird. In Supabase gehört nur der öffentliche anon-Schlüssel in den Frontend-Code.
• Rotiere jeden Schlüssel sofort, wenn du feststellst, dass er jemals offengelegt wurde, auch nur kurzzeitig, in einem öffentlichen Repo oder einem bereitgestellten Bundle.

Fehler 2: Row Level Security bei Supabase oder Firebase Deaktiviert Gelassen

Dies ist der Fehler, der aus „wir hatten einen Bug” ein „wir hatten eine Datenpanne” macht.

Supabase und Firebase geben dir beide eine echte, direkt über den Browser erreichbare Datenbank, was mächtig ist, um schnell zu bauen. Aber diese Macht kommt mit einer Bedingung: Row Level Security (RLS) muss konfiguriert werden, um festzulegen, wer welche Zeilen lesen und schreiben darf. KI-Coding-Assistenten führen dich häufig durch die Einrichtung mit RLS in einem freizügigen oder vollständig öffentlichen Zustand, weil eine öffentliche Richtlinie der schnellste Weg ist, deine Funktion während der Entwicklung „einfach funktionieren” zu lassen.

Der Haken ist, dass eine öffentliche RLS-Richtlinie nicht nur bedeutet, dass eingeloggte Nutzer mehr lesen können, als sie sollten. Es bedeutet, dass jeder — ganz ohne Login — eine Browser-Konsole öffnen und jede Zeile jeder offengelegten Tabelle abrufen kann, indem er eine rohe Fetch-Anfrage direkt an die öffentliche API-URL deiner Datenbank sendet. Deine gesamte Nutzerliste, jede Bestellung, jede private Nachricht — alles abrufbar mit einer Anfrage, die weniger Zeit zum Schreiben braucht als dieser Satz.

So behebst du es tatsächlich:

• Behandle RLS als verpflichtend, nicht optional, bevor echte Nutzerdaten in die Datenbank gelangen. Aktiviere es für jede Tabelle, die nicht vollständig öffentlich sein soll.
• Schreibe Richtlinien, die auf auth.uid() (Supabase) oder die entsprechende authentifizierte Prüfung (Firebase) beschränkt sind, damit ein Nutzer nur seine eigenen Zeilen berühren kann.
• Teste Richtlinien als anonyme, nicht authentifizierte Anfrage, nicht nur aus deiner eigenen eingeloggten Browsersitzung, in der du möglicherweise erhöhte Rechte hast, ohne es zu merken.
• Überprüfe RLS jedes Mal erneut, wenn eine neue Tabelle hinzugefügt wird, da sie nicht automatisch von Regeln erfasst wird, die du für andere Tabellen geschrieben hast.

Den praktischen Entscheidungsprozess dazu behandeln wir ausführlicher in unserem Leitfaden darüber, wann Row-Level Security zu einem Supabase-SaaS-MVP hinzugefügt werden sollte, einschließlich wie man es schrittweise einführt, ohne die frühe Entwicklungsgeschwindigkeit zu blockieren.

Fehler 3: Endlose Render-Schleifen, die Still API-Anfragen Verbrennen

Dieser sieht zunächst nicht wie ein Sicherheitsfehler aus. Er sieht wie ein Abrechnungsfehler aus, und bis du ihn bemerkst, steht der Schaden bereits auf deiner Rechnung.

Reacts useEffect-Hook wird jedes Mal erneut ausgeführt, wenn sich etwas in seinem Dependency-Array ändert. KI-Assistenten machen bei diesem Array manchmal Fehler: Ein Objekt oder eine Funktion wird bei jedem Render neu erstellt, der Effekt löst erneut aus, das verursacht ein State-Update, was ein weiteres Render auslöst, was den Effekt erneut auslöst. Die Schleife wiederholt sich so schnell, wie der Browser sie ausführen kann.

Enthält dieser Effekt zufällig einen API-Aufruf, eine Supabase-Abfrage oder einen Aufruf an ein kostenpflichtiges KI-Modell, bekommst du nicht eine Anfrage pro Seitenaufruf. Du bekommst Hunderte oder Tausende, oft von einem einzigen Tab, den ein einzelner Nutzer nachts im Hintergrund offen vergessen hat.

Realer Fall: Ein einziger inaktiver Browser-Tab erzeugte über 2.000 API-Anfragen, bevor es jemand bemerkte, einfach weil ein useEffect-Dependency-Array bei jedem Render auf ein neu erstelltes Objekt statt auf einen stabilen Wert verwies. Multipliziere das mit einer Handvoll vergessener Tabs bei deinen frühen Nutzern, und aus einem kleinen Bug wird eine Rechnung, die du einem Mitgründer erklären musst.

So behebst du es tatsächlich:

• Gib immer ein vollständiges, korrektes Dependency-Array für jedes useEffect an — fehlende Abhängigkeiten und instabile Referenzen (neue Objekte, Arrays oder Funktionen, die inline erstellt werden) sind die zwei häufigsten Ursachen dieser Schleife.
• Nutze den Network-Tab deines Browsers beim Testen und achte auf eine Anfragenzahl, die auf einer Seite weiter ansteigt, mit der du nicht aktiv interagierst.
• Füge Rate Limiting oder eine Überwachung der Anfragenzahl zu jedem Endpunkt hinzu, der eine kostenpflichtige Drittanbieter-API berührt, damit eine außer Kontrolle geratene Frontend-Schleife an eine Wand statt an eine offene Rechnung stößt.
• Richte Nutzungswarnungen und feste Ausgabenlimits direkt in deinen OpenAI-, Anthropic- und Cloud-Anbieter-Dashboards ein. Das stoppt den Bug nicht, aber es verhindert, dass der Bug zu einer 1000€-Überraschung wird.

Fehler 4: Admin- und Interne Routen Ohne Echte Authentifizierung Veröffentlicht

Dieser Fehler versteckt sich mitten in der Öffentlichkeit, weil die Funktion für dich, die einzige Person, die weiß, dass die URL existiert, perfekt funktioniert.

Bittest du einen KI-Assistenten um „ein Admin-Dashboard zur Nutzerverwaltung” oder „eine interne API zur Aktualisierung des Bestellstatus”, baut er die Seite oft korrekt, überspringt dabei aber die Authentifizierungsprüfung, weil du nie explizit danach gefragt hast. Das Ergebnis ist eine voll funktionsfähige /admin-, /internal-api- oder /debug-Route auf deiner Produktions-Domain ohne jegliches Login-Tor, die darauf setzt, dass niemand die URL errät.

Verschleierung ist keine Sicherheit. Automatisierte Bots durchsuchen routinemäßig gängige Pfade wie /admin, /api/internal und /.env auf jeder Domain, die sie finden, ohne die geringste Ahnung, was dein Produkt überhaupt macht. Antwortet die Route, ohne zu fragen, wer fragt, wird sie irgendwann gefunden — und wer sie findet, bekommt denselben Zugriff wie du.

So behebst du es tatsächlich:

• Verlange Authentifizierung und Rollenprüfungen für jede Route, die nicht vollständig öffentlich sein soll, einschließlich solcher, die du „nur für dich selbst” während der Entwicklung gebaut hast.
• Verlasse dich nie auf eine ungelistete oder schwer zu erratende URL als einzigen Schutz — behandle jede Route als auffindbar.
• Teste jede Admin- und interne Route genauso, wie du RLS getestet hast: als ausgeloggte, nicht authentifizierte Anfrage, nicht aus deiner eigenen bereits eingeloggten Browsersitzung.
• Frage deinen KI-Assistenten direkt: „Prüft diese Route Authentifizierung und Rolle, bevor Daten zurückgegeben werden?“, statt anzunehmen, dass sie es tut.

Fehler 5: Kein Rate Limiting auf Kostenpflichtigen oder Sensiblen Endpunkten

Dies ist der Fehler, der einen neugierigen Besucher — oder einen Bot, der deine API zufällig gefunden hat — zu deinem größten Kostenpunkt des Monats macht.

Selbst mit gesicherten Schlüsseln und aktiviertem RLS ist ein Endpunkt, der unbegrenzte Anfragen aus unbegrenzten Quellen akzeptiert, immer noch ein offener Hahn. KI-generierter Backend-Code wird häufig funktional, aber ungedrosselt ausgeliefert: Ein Endpunkt, der ein kostenpflichtiges KI-Modell aufruft oder in deine Datenbank schreibt, verarbeitet jede Anfrage, die er erhält, so schnell er sie erhält, ohne jegliches Konzept von „zu viel, zu schnell”, es sei denn, jemand hat das explizit eingebaut.

Anders als die außer Kontrolle geratene useEffect-Schleife (ein versehentlicher Bug in deinem eigenen Frontend) kommt dieses Risiko von außen: ein Scraper oder ein Bot, der absichtlich auf deinen öffentlichen Endpunkt einhämmert, genau weil nichts ihn davon abhält.

So behebst du es tatsächlich:

• Füge Rate Limiting auf Endpunkt- oder API-Gateway-Ebene für jede Route hinzu, die dich Geld pro Aufruf kostet oder sensible Daten berührt, mit einer Begrenzung der Anfragen pro IP oder pro Nutzer innerhalb eines Zeitfensters.
• Verlange Authentifizierung, bevor eine teure Operation läuft — eine nicht authentifizierte Anfrage sollte niemals einen kostenpflichtigen KI-Aufruf oder einen Massen-Datenbankschreibvorgang auslösen können.
• Nutze das eingebaute Drosseln deiner Hosting-Plattform oder deines API-Gateways (Vercel, Cloudflare, Supabase Edge Functions und API-Gateways wie Kong oder AWS API Gateway unterstützen dies alle), statt es selbst zu bauen.
• Überwache Anfragenspitzen von einer einzelnen IP oder Nutzer-ID — ein plötzlicher, anhaltender Ausbruch ist ein Signal, das eine Warnung wert ist, nicht nur eine Abrechnungszeile, die du später bemerkst.

Schnellvergleich: Was Jeder Fehler Dich Tatsächlich Kostet

Fehler	Was Offengelegt Wird	Typischer Auslöser	Schnellste Lösung
Hartcodierte API-Schlüssel	KI-/API-Guthaben, kostenpflichtige Nutzung	Schlüssel vom KI-Assistenten in Frontend-Code eingefügt	Aufrufe zu einem Backend-Endpunkt verschieben, Schlüssel rotieren
Deaktivierte Row Level Security	Gesamter Datenbankinhalt	Öffentliche/freizügige RLS-Richtlinie von der Einrichtung übrig	RLS aktivieren, Richtlinien auf auth.uid() beschränken
Endlose useEffect-Schleifen	Cloud-/API-Abrechnung	Fehlendes oder instabiles Dependency-Array	Dependency-Array reparieren, Rate Limits und Ausgabenlimits hinzufügen
Nicht authentifizierte Admin-/interne Routen	Voller Admin-Zugriff, interne Daten	Route ohne Auth-Prüfung gebaut	Auth- und Rollenprüfungen zu jeder Route hinzufügen
Kein Rate Limiting auf kostenpflichtigen Endpunkten	Cloud-/API-Abrechnung, Datenbanklast	Endpunkt offen für unbegrenzte Anfragen gelassen	Rate Limiting hinzufügen und Auth vor teuren Aufrufen verlangen

Das 5-Minuten-Selbst-Audit, das Du Jetzt Sofort Durchführen Kannst

Du brauchst kein Sicherheitsteam, um das meiste davon zu erfassen. Gehe vor deinem nächsten Deploy diese Prüfungen selbst durch:

• Öffne die DevTools auf deiner Live-Website (F12 → Tab Sources oder Network) und suche nach sk-, service_role oder einem String, der wie eine Datenbankverbindungs-URL aussieht. Findest du einen, rotiere ihn sofort und verschiebe diesen Aufruf serverseitig.
• Öffne dein Supabase- oder Firebase-Dashboard und prüfe den RLS-Status jeder Tabelle. Alles, was neben einer Tabelle mit echten Nutzerdaten „öffentlich” oder „deaktiviert” anzeigt, ist eine Tabelle, die jeder jetzt abfragen kann.
• Öffne deinen Network-Tab auf einer Seite mit einem useEffect und lasse sie 30 Sekunden lang inaktiv. Steigt die Anfragenzahl weiter an, ohne dass du etwas anklickst, hast du eine Schleife, keine Funktion.
• Prüfe deine OpenAI-, Anthropic- und Cloud-Abrechnungs-Dashboards auf Nutzungswarnungen. Hast du kein festes Ausgabenlimit gesetzt, tu es, bevor du diesen Satz zu Ende liest, nicht danach.
• Versuche, deine Admin-, internen oder Debug-Routen in einem Inkognito-Fenster zu laden, während du ausgeloggt bist. Kannst du die Seite noch sehen oder Daten davon abrufen, hat diese Route keine echte Authentifizierung.
• Prüfe, ob deine kostenpflichtigen oder sensiblen Endpunkte irgendein Rate Limiting konfiguriert haben. Könnte ein Skript denselben Endpunkt 10.000 Mal hintereinander aufrufen, ohne verlangsamt oder blockiert zu werden, dann hat er keines.

Fünf Minuten jetzt sind billiger als jedes Szenario, das dieser Artikel beschreibt.

Das Ist Kein Grund, Mit KI-Coding-Tools Aufzuhören

Nichts davon bedeutet, dass Claude Code, Cursor oder Windsurf unsichere Tools sind, oder dass KI-unterstützte Entwicklung vermieden werden sollte. Sie sind wirklich in der Lage, produktionsreifen Code zu erzeugen, einschließlich sicherer Muster, wenn die Person, die sie lenkt, auf die richtigen Dinge achtet. Die Tools sind nicht der Schwachpunkt. Die Veröffentlichung ohne sicherheitsorientierte Prüfung ist es.

Behandle jede KI-generierte Funktion so, wie du einen Pull Request eines Junior-Entwicklers behandeln würdest: wahrscheinlich in Ordnung, aber es verdient einen zweiten Blick auf alles, was Geheimnisse, Datenbankberechtigungen oder kostenpflichtige API-Aufrufe berührt, bevor es live geht. Diese Prüfung dauert einen Nachmittag. Eine 1000€-Rechnung oder eine offengelegte Datenbank zu bereinigen dauert deutlich länger und kann weit mehr als Geld kosten, sobald das Vertrauen der Kunden auf dem Spiel steht.

Steckst du bereits tief in einem vibe-gecodeten Build und suchst einen strukturierten Weg, diese Lücken zu schließen, bevor echte Nutzer eintreffen, führt dich unsere Checkliste dazu, was nach dem Vibe-Coding deines MVPs zu tun ist, Schritt für Schritt durch Test-, Sicherheits- und Skalierungsschritte. Es lohnt sich auch, deine Hosting-Einrichtung gegen gängige Cloud-Hosting-Fehler zu prüfen, die die Infrastrukturrechnung eines Startups aufblähen, da Abrechnungsüberraschungen selten aus nur einer Quelle stammen. Und hat dein KI-Assistent jemals vorgeschlagen, ein Paket zu installieren, das du nicht erkannt hast, lies, warum KI-Coding-Tools manchmal gefälschte Pakete erfinden, bevor du diesen Installationsbefehl ausführst.

Häufig gestellte Fragen

Warum ist meine Cloud-Rechnung nach dem Launch meiner App plötzlich auf über 1000€ gestiegen?

Die häufigsten Ursachen sind ein hartcodierter API-Schlüssel, der kopiert und von jemand anderem missbraucht wurde, eine außer Kontrolle geratene Schleife im Frontend-Code, die tausende doppelte Anfragen sendet, eine öffentliche Datenbank, die externen Skripten ununterbrochenen Datenzugriff ermöglichte, oder ein kostenpflichtiger Endpunkt ohne Rate Limiting, den ein Bot gefunden und überlastet hat. Jede dieser Ursachen vervielfacht nutzungsbasierte Kosten sehr schnell, oft über Nacht.

Ist es sicher, Cursor, Claude Code oder Windsurf zum Bau eines echten Produkts zu verwenden?

Ja, diese Tools sind sicher in der Anwendung und können die Entwicklung deutlich beschleunigen. Das Risiko liegt nicht im Tool selbst, sondern darin, ohne Prüfung sicherheitsrelevanter Bereiche wie Geheimnisspeicherung, Datenbankzugriffsregeln und Effekt-Abhängigkeiten zu veröffentlichen, die KI-Assistenten standardmäßig nicht immer richtig handhaben.

Was ist Row Level Security und warum ist es für vibe-gecodete Apps wichtig?

Row Level Security (RLS) ist eine Datenbankfunktion in Tools wie Supabase und Firebase, die einschränkt, welche Zeilen ein Benutzer lesen oder schreiben darf. Bleibt RLS im standardmäßig offenen Zustand, kann jeder mit deiner öffentlichen API-URL deine gesamte Datenbank direkt über eine Browser-Konsole abfragen, ganz ohne Login.

Wie erkenne ich, ob meine API-Schlüssel in meinem Frontend-Code offengelegt sind?

Öffne deine Live-Website, drücke F12, um die Browser-DevTools zu öffnen, und prüfe den Tab Sources oder Network auf einen Schlüssel, der mit sk-, service_role oder einem vollständigen Datenbankverbindungsstring beginnt. Wenn du ihn dort sehen kannst, kann es jeder andere Besucher deiner Website auch.

Kann ein useEffect-Bug wirklich tausende zusätzliche API-Kosten verursachen?

Ja. Ein fehlendes oder falsches Dependency-Array in einem React-useEffect-Hook kann dazu führen, dass eine Komponente sich ständig neu rendert und ihren API-Aufruf immer wieder auslöst. Unbemerkt auf einer Seite, die Nutzer in einem Hintergrundtab offen lassen, kann dies tausende Anfragen pro Sitzung erzeugen, mit einem entsprechenden Sprung in der nutzungsbasierten Abrechnung.

Muss ich vor dem Launch eines vibe-gecodeten MVPs einen Sicherheitsexperten engagieren?

Für ein frühes MVP nicht unbedingt, aber du brauchst jemanden mit Software-Engineering-Urteilsvermögen, der Architekturrisiken prüft, bevor echte Nutzer und echte Zahlungsmethoden auf das Produkt treffen. Eine kurze Prüfung mit Fokus auf Geheimnisse, Datenbankregeln und API-Nutzungsmuster erfasst das meiste, was teure Überraschungen verursacht.

Wie prüfe ich, ob meine Admin- oder internen Routen tatsächlich geschützt sind?

Öffne die Route in einem Inkognito- oder privaten Browserfenster, während du vollständig ausgeloggt bist. Wenn du die Seite trotzdem sehen oder Daten davon abrufen kannst, gibt es keine echte Authentifizierungsprüfung, und die Route ist für jeden erreichbar, der die URL findet, einschließlich automatisierter Scanner, die nach gängigen Admin-Pfaden suchen.

Was ist Rate Limiting und warum braucht ein kleines MVP das?

Rate Limiting begrenzt, wie viele Anfragen ein einzelner Nutzer oder eine IP-Adresse innerhalb eines bestimmten Zeitfensters an einen Endpunkt senden kann. Selbst ein kleines MVP braucht dies bei jedem Endpunkt, der Geld pro Aufruf kostet oder sensible Daten berührt, denn ohne Rate Limiting kann ein Skript oder Bot diesen Endpunkt beliebig oft aufrufen und eine einzige ungeschützte Route in eine unbegrenzte Rechnung verwandeln.