KI-generierte Websites: was du wirklich bekommst.

Prompt-to-App-Werkzeuge produzieren inzwischen in Minuten etwas, das wie eine fertige Website aussieht, und sie abzutun wäre albern — wir nutzen KI selbst intensiv, auch auf dieser Website. Genauer hinsehen sollte man beim Abstand zwischen „sieht fertig aus“ und „darauf lässt sich ein Unternehmen betreiben“, denn unabhängige Sicherheitsforschung aus 2025 und 2026 hat diesen Abstand nun gemessen statt darüber zu streiten.

Was die Forschung gemessen hat

Veracode testete über 100 Sprachmodelle in Java, JavaScript, Python und C#; Java fiel mit über 70 % durch. Die Zahlen von Apiiro, USENIX und Snyk stehen so in der unter Quellen verlinkten Research Note der Cloud Security Alliance. Vergleich die letzte Zeile mit der ersten: Die Vertrauenslücke ist wohl der wichtigste Befund.

Was diese Werkzeuge wirklich gut können

Um eine Idee zu validieren, bevor echtes Geld fließt, sind sie ausgezeichnet, und wir empfehlen sie. Ein klickbarer Prototyp, der beweist, dass Leute die Sache wollen; ein internes Tool für drei Kollegen; eine Kampagnenseite, die in sechs Wochen endet — das Risikoprofil ist klein und die Geschwindigkeit unerreicht. Niemand sollte eine Agentur bezahlen, um herauszufinden, ob eine Idee trägt.

Sie sind auch ein legitimer erster Entwurf in echten Projekten. Ein generiertes Komponentengerüst, das ein Entwickler dann liest, umbaut und testet, ist schneller als ein leeres File. Die Unterscheidung ist nicht KI gegen Mensch, sondern geprüft gegen ungeprüft.

Wie der Code darunter typischerweise aussieht

Zwei Muster kehren wieder. Erstens plausible Unsicherheit: Der Code läuft, die Funktion funktioniert, und die Eingabe wird nie validiert. Cross-Site-Scripting- und Injection-Fehler dominieren die Veracode-Ergebnisse, weil die unsichere und die sichere Variante für jemanden, der den Unterschied nicht lesen kann, gleich vernünftig aussehen — und das Werkzeug sagt selbstbewusst, es sei fertig.

Zweitens Autorisierung, die nie wirklich umgesetzt wurde. Zugriffskontrolle ist das, was prompt-getriebene Builds am häufigsten überspringen, weil sichtbar nichts bricht, wenn sie fehlt: Die Anwendung funktioniert für den Testenden perfekt, und die Datenbank gibt jeden Datensatz an jeden heraus, der fragt. Dieser Fehler ist in einer Demo unsichtbar und in der Produktion vollständig.

Die Kosten, die später kommen

Halluzinierte Abhängigkeiten sind die unterschätzte Gefahr. Rund ein Fünftel der generierten Proben importiert Pakete, die es nicht gibt, und weil sich die erfundenen Namen vorhersagbar wiederholen, registrieren Angreifer sie — ein Build, der im April funktionierte, kann im Juli feindlichen Code ziehen, ohne dass sich eine Zeile geändert hat. Hartcodierte Zugangsdaten sind der andere Dauerbefund, direkt ins Repository eingecheckt, weil das Modell irgendetwas einsetzen musste.

Dann die strukturelle Rechnung. Eine Codebasis, die durch Prompten bis zum Verschwinden der Fehlermeldung entsteht, sammelt doppelte Logik und keine kohärente Architektur, wodurch jede weitere Änderung teurer wird als die vorige. Genau dort bleiben Projekte stecken: nicht beim Launch, sondern beim dritten Feature-Wunsch.

Wie wir KI bei Arbeit einsetzen, die bleiben soll

Sie schreibt Entwürfe, erzeugt Boilerplate, schlägt Testfälle vor und beschleunigt Refactorings — und jede Zeile liest jemand, der sie auch selbst hätte schreiben können. Eingaben werden bewusst validiert, Autorisierung wird entworfen statt generiert, Abhängigkeiten werden gegen das echte Registry geprüft, und Secrets liegen in der Environment-Konfiguration und nie in einem Commit. Nichts davon ist exotische Praxis — es ist die Praxis, die KI-gestützter Output am häufigsten vermisst, und genau das beschreibt die 45 %-Zahl.

Die unangenehme Formulierung: KI hebt die Obergrenze dafür, wie viel Code ein guter Entwickler liefert, und hebt die Untergrenze dafür, wie viel Schaden ein ungeprüfter Prozess anrichtet. Sie nimmt das Tippen ab, nicht das Urteil.

Was du fragen solltest, bevor du eine KI-gebaute Website kaufst

Fünf Fragen bringen dich fast ans Ziel. Besitzt du den Quellcode und kannst du ihn exportieren, oder läuft er nur auf der Plattform des Anbieters? Hat ein Mensch die sicherheitsrelevanten Teile geprüft, konkret Eingabeverarbeitung und Zugriffskontrolle? Gibt es Authentifizierung auf allem, was Kundendaten berührt — in der Datenbank erzwungen und nicht nur in der Oberfläche versteckt? Sind die Abhängigkeiten echt, aktuell und patchbar? Und wer repariert es morgens um 9, wenn es bricht?

Ist eine dieser Antworten unklar, ist die Website ein Prototyp, egal wie fertig sie aussieht. Das kann genau das Richtige sein — kalkulier und plan sie dann aber als Prototyp und lass sie prüfen, bevor sie etwas hält, dessen Leak dir peinlich wäre. Die Sicherheitshälfte derselben Frage steht in was die Studien 2026 über KI-generierten Code fanden.

Quellen

Die Zahlen oben stammen aus diesen veröffentlichten Studien, geprüft im Juli 2026.

• Veracode — 2025 GenAI Code Security Report ↗

  Über 100 LLMs getestet in Java, JavaScript, Python und C#: 45 % der generierten Proben brachten eine OWASP-Top-10-Schwachstelle ein, das 2,74-Fache von menschlich geschriebenen Äquivalenten, mit 86 % und 88 % Fehlerquote bei XSS und Log Injection. Größere Modelle waren nicht wesentlich besser.

• Cloud Security Alliance — Vibe Coding's Security Debt: The AI-Generated CVE Surge ↗

  Research Note, die die Apiiro-Daten zu Commits und Befunden (+322 % Rechteausweitung, +153 % Architekturfehler), den USENIX-Security-2025-Befund zu halluzinierten Paketen (~20 %, davon 43 % der erfundenen Namen reproduzierbar), Snyks Entwicklerbefragung und die CVE-Zuordnung von Georgia Tech zusammenführt.

• OWASP — Top 10 Web Application Security Risks ↗

  Die Klassifikation, gegen die beide Studien oben bewerten — die Referenzliste dafür, was „hat eine Schwachstelle eingeführt“ in diesen Prozentzahlen konkret bedeutet.