KI-Entwicklungstools erstellen funktionsfähige Anwendungen schnell. Sie entwickeln auch unsichere Backends – mit derselben Sicherheit, demselben sauberen Code und keinerlei Hinweis darauf, dass etwas nicht stimmt. 45 Prozent des von KI generierten Codes scheitert an Sicherheitstests – so lautet das Ergebnis des Veracode GenAI Code Security Reports 2025, für den mehr als 100 Sprachmodelle untersucht wurden. Die Zahl hat sich auch mit größeren Modellen nicht verbessert. Das Problem sind keine unvorsichtigen Entwickler. Das Problem ist, dass KI eine grundlegend andere Definition von „fertig" hat – eine, die nichts damit zu tun hat, was ein Angreifer versuchen würde.
Was „fertig" für eine KI bedeutet – und warum diese Definition gefährlich ist
Wenn ein KI-Coding-Assistent das Grundgerüst eines Backends fertiggestellt hat, hat er einen Test bestanden: Läuft der Code? Der Standardfall funktioniert. Die Oberfläche lädt. Die Daten werden gespeichert. Der Endpunkt antwortet mit 200. Nach dem Kriterium der KI ist die Aufgabe erledigt.
Ein Angreifer stellt andere Fragen: Was passiert, wenn ich fehlerhafte Eingaben sende? Was passiert, wenn ich mich als ein Nutzer authentifiziere und auf die Daten eines anderen zugreife? Was passiert, wenn ich den Admin-Endpunkt direkt aufrufe? Was passiert, wenn ich die Zugangsdaten aus Ihrem JavaScript extrahiere?
Diese beiden Definitionen von „fertig" – die des Entwicklers und die des Angreifers – sind nur dann kompatibel, wenn die Person, die die Software baut, den zweiten Test nach dem ersten durchführt. Die KI führt den zweiten Test nicht durch. Die heutigen Mainstream-Tools haben kein Modell eines Angreifers. Sicherheit ist kein Teil ihrer Erfolgskriterien – es sei denn, man macht es explizit zum Teil des Prompts, und selbst dann sind die Ergebnisse inkonsistent.
Das ist keine Kritik an einem bestimmten Tool. Es ist eine Beschreibung, wie KI-Coding-Systeme konstruktionsbedingt funktionieren. Diese Tools sind darauf trainiert, funktionierenden Code zu produzieren. Sie sind nicht darauf trainiert, Code zu produzieren, der absichtlichem Missbrauch widersteht. Diese Lücke – zwischen funktional und sicher – ist der Kern des Problems.
Was ich gebaut habe – und was ich dabei gefunden habe
Anfang dieses Jahres habe ich ein Image-Generation-Tool gebaut: ein Node.js-Backend, einen PostgreSQL-basierten verwalteten Datenbankdienst, ein Frontend für Nutzer-Uploads und Prompt-Eingaben. Standardaufbau. Die Art von Projekt, die ein KI-gestützter Workflow in wenigen Stunden aufbaut.
Die KI hat die gesamte Datenbankschicht erstellt – Tabellen, Abfragen, API-Endpunkte, Authentifizierungsflow. Es funktionierte. Jede Funktion lief genau wie vorgesehen. Nutzer konnten sich registrieren, Prompts einreichen, Bilder generieren, ihren Verlauf abrufen. Sauberer Code, sinnvolle Bezeichnungen, lesbare Struktur.
Was die KI nicht getan hat:
Row-Level Security war nicht aktiviert. Die Datenbank war so konfiguriert, dass jeder authentifizierte Nutzer jede Zeile in jeder Tabelle abfragen konnte. Nutzer A hätte den Generierungsverlauf, gespeicherte Prompts und alle anderen Daten von Nutzer B durch eine gezielte Anfrage auslesen können. Die KI hat die Tabellen korrekt erstellt. Sie hat nur versäumt, die Zugriffsrichtlinien hinzuzufügen, die einschränken, was jeder authentifizierte Nutzer sehen und ändern kann.
Der Service Key – die Zugangsdaten auf Adminebene, die alle Zugriffskontrollen umgehen – war im Frontend-Code. Der verwaltete Datenbankdienst stellt zwei Arten von Zugangsdaten aus: einen anonymen Key (sicher für die clientseitige Verwendung, respektiert Zugriffsrichtlinien) und einen Service Key (ausschließlich für den Server, umgeht alle Richtlinien). Die KI verwendete durchgehend den Service Key, weil er sofort funktioniert – ohne dass Zugriffsrichtlinien vorhanden sein müssen. Er landete im Client-Bundle, wo ihn jeder Nutzer hätte extrahieren können.
Es gab keine serverseitige Eingabevalidierung. Das Frontend validierte Nutzereingaben. Die API-Endpunkte nicht. Jede Anfrage, die direkt an die API gesendet wurde – unter Umgehung des Frontends – wurde ohne jede Prüfung verarbeitet.
Nichts davon war versteckt. Ich wurde nicht hinters Licht geführt. Der Code war genau das, was er zu sein schien. Er war nur strukturell unsicher – auf eine Weise, die erst sichtbar wird, wenn man wie jemand denkt, der das System brechen will, und nicht wie jemand, der es gebaut hat.
Die vier Muster, die in fast jedem KI-generierten Backend auftauchen
Wiz Research hat 2025 Tausende von Anwendungen analysiert, die mit KI-Coding-Tools erstellt wurden, und vier primäre Schwachstellenkategorien identifiziert. Sie stimmen exakt mit dem überein, was ich gefunden habe – und treten konsistent über verschiedene Tools, Entwickler und Projekttypen hinweg auf.
1. Fehlende oder falsch konfigurierte Zugriffsrichtlinien
Row-Level Security – der Mechanismus, der einschränkt, auf welche Datenbankzeilen ein Nutzer zugreifen kann – ist in den meisten verwalteten PostgreSQL-Diensten optional. KI erstellt Tabellen und Abfragen, die ohne diese Richtlinien funktionieren. Das Hinzufügen erfordert, unberechtigte Zugriffsmuster vorauszudenken – was außerhalb des Standardumfangs der KI liegt.
Ein Sicherheitsaudit von 1.645 Anwendungen, die mit einer populären KI-Coding-Plattform erstellt wurden, fand 2025 heraus, dass 170 davon Nutzerdaten preisgaben – darunter Namen, E-Mail-Adressen, Finanzdaten und API-Keys. Die Ursache in jedem Fall: Row-Level Security fehlte oder war falsch konfiguriert. Die Plattform hatte Monate zuvor ein eigenes Sicherheits-Scan-Feature eingeführt. Dieses prüfte, ob Richtlinien vorhanden waren – nicht, ob sie korrekt verfasst waren. Falsches Sicherheitsgefühl verschlimmerte das ursprüngliche Problem.
2. Service Keys im clientseitigen Code
Die Unterscheidung zwischen einem veröffentlichbaren Key (sicher für das Frontend, respektiert Zugriffsregeln) und einem Service Key (ausschließlich für den Server, umgeht alle Zugriffsregeln) ist ein Konzept, das die KI versteht, wenn man danach fragt – und ignoriert, wenn sie Code schreibt. Der Service Key ist der, der sofort funktioniert. Er landet im Frontend, weil er den Standardfall ohne weitere Konfiguration zum Laufen bringt.
Anfang 2026 wurde festgestellt, dass eine mit KI-Unterstützung erstellte Social-App 1,5 Millionen API-Token und 35.000 E-Mail-Adressen preisgegeben hatte. Der Service Key – Datenbankzugriff auf Adminebene – war im clientseitigen JavaScript vorhanden. Jeder, der die Anwendung geladen hatte, hätte ihn extrahieren und die gesamte Datenbank lesen oder schreiben können.
3. Keine Authentifizierung an Endpunkten
Wenn der Prompt lautet „Erstelle einen Endpunkt, der den Rechnungsstatus aktualisiert", erstellt die KI den Endpunkt. Sie legt nicht fest, wer ihn aufrufen darf. Apiiro hat zwischen Dezember 2024 und Juni 2025 in KI-generierten Codebasen eine Verzehnfachung der APIs ohne Autorisierung verzeichnet. Fehlende Endpunkt-Authentifizierung ist mittlerweile die häufigste neue Sicherheitslücke in KI-generiertem Code.
4. Ausschließlich clientseitige Eingabevalidierung
React-Formularvalidierung, clientseitige Prüfungen, UI-Einschränkungen – das erstellt die KI zuverlässig. Was sie ohne explizite Anweisung nicht erstellt, ist dieselbe Validierung auf API-Ebene. Jeder Angreifer, der die API direkt aufruft, umgeht alle Prüfungen im Frontend. Die Anwendung wirkt sicher, wenn sie normal genutzt wird. Sie ist es nicht.
Warum der überzeugende Output der KI Ihren Kontrollinstinkt unterdrückt
Dies ist der kontraintuitive Befund einer peer-reviewten Stanford-Studie aus 2022, der seitdem nicht widerlegt wurde: Entwickler, die KI-Coding-Assistenten verwendeten, produzierten mehr Sicherheitslücken als Entwickler, die ohne KI programmierten – und waren dabei überzeugter, dass ihr Code sicher sei.
Der Mechanismus ist entscheidend. KI generiert sauberen, gut kommentierten, lesbaren Code. Sie verwendet konsistente Bezeichnungen. Sie strukturiert Dateien sinnvoll. Sie besteht den visuellen Prüftest, den ein Entwicklerauge anwendet, bevor es weitermacht. Nichts am Output signalisiert, dass etwas nicht stimmt. Kein Kommentar neben der fehlenden Zugriffsrichtlinie. Kein Hinweis, dass der Service Key den Server nicht verlassen darf.
Die überzeugende Präsentation des KI-Outputs ist kein Nebenaspekt des Sicherheitsproblems. Sie ist Teil davon. Der Code wirkt fertig, weil das Kriterium der KI für „fertig" erfüllt ist. Das Muster-Matching des Entwicklers – die Suche nach unvollständigem oder verdächtigem Code – findet nichts. Also wird die Überprüfung übersprungen, abgekürzt oder auf unbestimmte Zeit verschoben.
Deshalb gilt der Stanford-Befund auch für erfahrene Entwickler. Es ist keine Wissenslücke. Es ist ein Problem der Vertrauenskalibrierung. KI kommuniziert Sicherheit durch die Textur ihres Outputs. Entwickler lesen diese Textur. Der Instinkt zur Überprüfung wird durch die scheinbare Vollständigkeit des Gelieferten unterdrückt.
Warum der Review-Schritt verschwindet
Code-Review existiert, weil Code schreiben und Code überprüfen unterschiedliche kognitive Modi erfordern. Schreiben optimiert dafür, etwas zum Laufen zu bringen. Überprüfen optimiert dafür, zu finden, was schiefgehen könnte. Diese Perspektiven sind nicht kompatibel – man kann sie nicht gleichzeitig einnehmen.
In der traditionellen Entwicklung ist die Lücke zwischen Schreiben und Überprüfen strukturell. Andere Personen, andere Zeit, anderer Kontext. Der Review-Schritt wird durch den Workflow erzwungen.
In der KI-gestützten Entwicklung kollabiert diese Lücke. Man beschreibt, was man will. Die KI baut es. Es funktioniert. Der nächste Prompt nimmt bereits Form an. Der Workflow ist dialogartig – iterativ, schnell, von Schwung getragen. Review ist keine separate Phase. Es fühlt sich an wie innehalten, um einem Mitarbeiter zu misstrauen, der gerade exakt das geliefert hat, worum man gebeten hat.
Das ist kein Disziplinproblem, das bessere Entwickler vermeiden. Es ist ein Workflow-Problem, das das Medium erzeugt. Je schneller und dialogartiger der Loop, desto mehr wird Review als Unterbrechung statt als Prozess erlebt.
Apiioros Daten zeigen einen Anstieg architektonischer Designfehler in KI-generierten Codebasen um 153 Prozent im Jahr 2025. Das sind keine Bugs – kleine Fehler, die überall entstehen können. Es sind strukturelle Entscheidungen darüber, wo Zugangsdaten gespeichert werden, wer welche Daten lesen kann und was die API als vertrauenswürdig betrachtet. Entscheidungen, die die KI getroffen hat – und kein Mensch überprüft hat.
Was die Zahlen sagen
Die Forschung zur Sicherheit von KI-generiertem Code ist mittlerweile umfangreich genug, um als konsistenter Befund aus mehreren unabhängigen Quellen zu gelten — dem Veracode GenAI Code Security Report 2025, Wiz Research, Apiiro, dem Georgetown-CSET-Policy-Brief und unabhängigen Security-Vendor-Analysen. Die folgenden Zahlen entstammen diesen Quellen, nicht einer einzigen kanonischen Studie; Richtung und Größenordnung sind über alle Quellen hinweg konsistent.
Der Veracode-Report 2025 testete mehr als 100 Sprachmodelle. 45 Prozent des KI-generierten Codes enthält Sicherheitslücken. KI-generierter Code weist 2,74-mal häufiger Cross-Site-Scripting-Schwachstellen auf und 1,91-mal häufiger unsichere Objektreferenzen als von Menschen geschriebener Code. Die Fehlerrate für XSS – über alle getesteten Modelle hinweg – beträgt 86 Prozent. Das Georgetown-CSET-Policy-Brief vom November 2024 kam unabhängig davon auf dieselbe XSS-Fehlerrate.
Apiiro verzeichnete zwischen Dezember 2024 und Juni 2025 eine Verzehnfachung neuer Sicherheitsbefunde pro Monat in KI-generierten Codebasen. Privilege-Escalation-Pfade stiegen um 322 Prozent. Architektonische Designfehler um 153 Prozent.
Ein Scan von rund 5.600 mit KI-Tools erstellten Anwendungen fand 2025 mehr als 2.000 Schwachstellen und über 400 exponierte Secrets. Broken Access Control – die OWASP-Kategorie A01:2025 – verzeichnete im selben Jahr einen Anstieg gemeldeter Vorfälle um 40 Prozent.
Eine IT-Pro-Analyse aus 2025 stellte fest, dass KI-generierter Code für jeden fünften Unternehmens-Breach verantwortlich ist. 69 Prozent der Sicherheitsverantwortlichen berichteten, ernsthafte Schwachstellen in KI-generiertem Code gefunden zu haben.
Diese Zahlen beschreiben keine Randgruppe nachlässiger Entwickler. Sie beschreiben den Durchschnitts-Output der aktuellen Generation von KI-Coding-Tools – über ein breites Spektrum von Anwendungsfällen und Erfahrungsniveaus hinweg.
Wer heute Software baut
Für den größten Teil der Softwaregeschichte gehörte zur Gruppe der Menschen, die eine funktionierende Webanwendung deployen konnten, per Definition ein ausreichendes technisches Grundwissen – etwa dass ein Service Key nicht in clientseitigem JavaScript stehen darf. Das Erstellen der Anwendung erforderte dieses Wissen.
KI-Coding-Tools haben den Einstiegspunkt verändert. Nicht-Entwickler – Gründer, Marketing-Verantwortliche, Produktmanager, Designer – erstellen und deployen heute Produktionsanwendungen, die echte Nutzerdaten verarbeiten. Das ist ein echter Fähigkeitssprung mit realem Wert. Es ist auch eine strukturelle Sicherheitsverschiebung mit realen Konsequenzen.
Derselbe Scan fand über 400 exponierte Secrets in Apps dieser breiteren Entwicklergruppe. Die meisten dieser Entwickler haben keinen Sicherheitsschritt wissentlich übersprungen. Sie haben keine bewusste Risikoentscheidung getroffen. Sie hatten kein mentales Modell, das die Frage „Was passiert, wenn jemand auf die Daten eines anderen Nutzers zugreift?" als relevante Überlegung vor dem Deployment enthält.
Das lässt sich nicht durch bessere Dokumentation oder mehr Sicherheitswarnungen lösen. Es ist eine strukturelle Verschiebung darin, wer Software baut – zu einer Zeit, in der die Tools, die diese Verschiebung ermöglichen, ihre eigenen Sicherheitsgrenzen nicht kommunizieren. Das Volumen internetverbundener Software mit architektonischen Sicherheitslücken wächst – nicht weil mehr nachlässige Menschen Code schreiben, sondern weil eine neue Entwicklergruppe Software mit Tools erstellt, die die Arbeit überzeugend abschließen und nichts darüber sagen, was sie ausgelassen haben.
Was Sie prüfen sollten, bevor Sie ein KI-generiertes Backend in Produktion bringen
Vier Fragen decken die häufigsten Risikomuster in KI-generiertem Code ab:
Ist Row-Level Security für jede Tabelle aktiviert, die Nutzerdaten speichert? Nicht nur vorhanden – korrekt konfiguriert. Eine Richtlinie, die existiert, aber falsch geschrieben ist, bietet keinen Schutz. Testen Sie es: Erstellen Sie zwei Testnutzer, schreiben Sie mit einem Daten, und versuchen Sie, diese mit dem anderen über eine direkte Datenbankabfrage auszulesen.
Wo befinden sich Ihre Zugangsdaten – und ist der Service Key irgendwo im clientseitigen Code? Öffnen Sie Ihre gebauten Frontend-Dateien und suchen Sie nach einem Key, der im Dashboard Ihres Datenbankdienstes unter „Service"- oder „Secret"-Zugangsdaten erscheint. Wenn er dort ist, ist er öffentlich zugänglich.
Erzwingt jeder API-Endpunkt Authentifizierung auf Server-Ebene – nicht nur im Frontend? Rufen Sie Ihre Endpunkte direkt mit einem Tool wie Postman oder curl auf, ohne Ihre UI und ohne gültige Authentifizierung. Was geben sie zurück?
Gibt es serverseitige Eingabevalidierung für jeden Endpunkt, der Nutzereingaben akzeptiert? Frontend-Validierung ist ein UX-Anliegen. Serverseitige Validierung ist ein Sicherheitsanliegen. Sie sind nicht austauschbar. Die API sollte fehlerhafte oder übermäßig große Eingaben ablehnen – unabhängig davon, was die UI erlaubt.
Das ist nicht umfassend. Es sind die vier Muster, die am häufigsten in KI-generiertem Code vorkommen, der ohne Sicherheitsüberprüfung in Produktion geht.
Das eigentliche Problem
Nicht Geschwindigkeit. Nicht Nachlässigkeit. Nicht eine Generation von Entwicklern, die es besser hätten wissen sollen.
Das eigentliche Problem: KI definiert „fertig" als funktional. Sicherheit erfordert eine andere Definition von fertig – eine, die einschließt, was passiert, wenn das System von jemandem genutzt wird, der es brechen will. KI wendet diese Definition nicht an. Die heutigen Mainstream-Tools haben kein Modell eines Angreifers. Und ihr überzeugender, sauberer, gut strukturierter Output unterdrückt aktiv den Instinkt des Entwicklers, nach dem zu suchen, was fehlt.
Der Review-Schritt ist nicht optional. Die Präsentation der Arbeit als abgeschlossen ist kein Beweis dafür, dass die Arbeit abgeschlossen ist.
Diese Unterscheidung – zwischen funktional und sicher – liegt weiterhin in der Verantwortung des Entwicklers. KI hat daran nichts geändert. Sie hat die Lücke nur erheblich schwerer sichtbar gemacht.