Die Statistik wird oft in zwei Hälften zitiert, wobei die Menschen zuverlässig die beruhigende Hälfte wählen. LLMs produzieren in etwa 90 % der Fälle Code, der erfolgreich kompiliert. Die andere Hälfte: etwa 45 % dieses Codes enthalten Schwachstellen der OWASP Top 10 Klasse, der Industriestandard-Liste der häufigsten schwerwiegenden Sicherheitslücken (z. B. umgehbare Logins und Injection-Bugs). Es lohnt sich, präzise zu sein, was das bedeutet und was nicht, bevor man entweder in Panik gerät oder die Warnung ignoriert.
Was die Zahl nicht bedeutet
Es ist nicht die Behauptung, dass 45 % der KI-gebauten Apps gehackt werden oder dass generierter Code grundsätzlich schlechter ist; auch menschliche Entwickler schreiben vulnerablen Code, weshalb die OWASP-Liste existiert. Und es ist kein Argument dafür, dass KI-Coding-Tools nutzlos sind, da ein Entwickler, der den Output prüft, vieles davon im normalen Arbeitsablauf abfängt.
Was es bedeutet: Werfen Sie bei jeder Generierung eine Münze – das sind in etwa die Chancen, dass der Code eine Schwachstelle aus dem bekanntesten Katalog der Branche enthält, während er perfekt kompiliert und in der Demo funktioniert. Die Schwachstelle hat keinen Einfluss auf das sichtbare Verhalten. Das ist die Falle.
Warum funktionierender Code kein sicherer Code ist
KI-Modelle optimieren auf schnellen visuellen Erfolg, weil das der Prompt verlangt hat und das ist es, was der Entwickler durch Hinsehen verifizieren kann. Sicherheit ist genau die Eigenschaft, die man im Vorschaufenster nicht sieht, und die dokumentierten Fehlermuster folgen diesem Gradienten. Zugriffskontrollen werden im Browser statt auf dem Server implementiert, sodass ein Nutzer die Prüfung umgehen kann, indem er den Code auf seinem eigenen Rechner modifiziert; die App sieht in beiden Fällen identisch aus. Datenbankberechtigungen werden zu weit gefasst, damit beim ersten Versuch alles klappt, wodurch Daten exponiert werden, falls ein anderer Teil der App kompromittiert wird. Secrets werden hartcodiert in Dateien geschrieben, weil die Verwaltung von Umgebungsvariablen genau die Art von unsichtbarer lästiger Arbeit ist, die sowohl Modelle als auch Anfänger auslassen – und diese Anmeldedaten landen dann in öffentlichen GitHub-Repos. Und Utility-Flows mit echter Sicherheitsrelevanz (Passwortwiederherstellung, OTP-Verifizierung, Session-Management) werden schlicht nicht gebaut, weil sie niemand in einer Demo vorführt.
Die Vertrauensstellung des Entwicklers verschärft die Situation. Ein nicht-technischer Betreiber kann den generierten Code nicht lesen, um dies zu prüfen, und manuelle Tests prüfen den Idealfall (Happy Path), nicht den Bypass. Die App, die „perfekt funktioniert“, und die App, die die Datensätze jedes Kunden leakt, können dieselbe App sein.
Was zu prüfen ist, bevor echte Nutzer sich einloggen
Ein minimales Audit in einfachen Worten. Erstens, serverseitige Erzwingung: Bestätigen Sie, dass das, was ein Nutzer sehen kann, auf dem Server oder in Datenbankregeln entschieden wird und nicht durch das Ausblenden von Buttons in der UI. Zweitens, Datenbank-Status: Regeln sollten standardmäßig den Zugriff verweigern und ihn nur eng gefasst gewähren; bei Tools mit Supabase-Backend wie Lovable bedeutet das, die RLS-Policies tatsächlich zu lesen, statt darauf zu vertrauen, dass der Prompt sie korrekt erstellt hat. Drittens, Secrets-Hygiene: Durchsuchen Sie das Repo nach hartcodierten Keys und Connection-Strings, besonders wenn das Projekt jemals mit einem öffentlichen Repository synchronisiert wurde. Viertens, die vergessenen Flows: Prüfen Sie, ob Passwort-Reset, Session-Expiry und Signup-Beschränkungen existieren und funktionieren. Fünftens, der Zweitnutzer-Test: Erstellen Sie zwei Konten und versuchen Sie, von der Session eines Nutzers auf die Daten des anderen zuzugreifen, unter anderem durch direktes Editieren der URLs. Nichts davon ist exotisch; all das ist genau das, was die Generierung auslässt.
Und beachten Sie die Wartungsklausel: Dies ist keine einmalige Prüfung. Jede Neugenerierung ist ein erneutes Würfeln mit denselben Chancen. Ein Fix-Loop bei einem auth-relevanten Feature bedeutet also, die Ebene, die Sie bereits geprüft haben, erneut zu verifizieren – und für die Runde zu bezahlen, die diese Verifizierung ermöglicht. Diese Last der erneuten Prüfung ist eine Seite des Day Two Problems: Das Audit, das Sie heute durchführen, ist das Audit, das Sie nach der nächsten Änderung erneut durchführen müssen.
Die ehrliche Weggabelung
Diese Audit-Liste ist der tatsächliche Preis für die 45-Prozent-Zahl, und es gibt genau zwei Wege, ihn zu bezahlen. Die Review übernehmen: Sie oder ein Entwickler, dem Sie vertrauen, prüft den generierten Code in jeder Runde und behandelt die KI wie einen schnellen Junior, dessen Sicherheitsarbeit grundsätzlich kontrolliert werden muss. Für Entwickler ist das eine vertretbare Position, für alle anderen eine Fiktion. Oder die Ebene komplett eliminieren: Bauen Sie Business-Apps wie Portale und interne Tools auf einer Plattform wie Softr auf. Hier sind Authentifizierung, Berechtigungen und Datenzugriffsregeln visuell konfigurierte Plattform-Infrastruktur und kein pro Projekt generierter Code – so betrifft die 45-Prozent-Lotterie die wichtigste Ebene gar nicht erst. Keine vertretbare Position ist die beliebte dritte Option: Generieren, kurz auf das Demo schauen und deployen. Dass es diese Statistik überhaupt gibt, liegt daran, dass die meisten Menschen genau das tun.