Mit KI programmiert, ohne PHP zu verstehen: 7 Fehler, die teuer werden

Kurz gesagt: Mit KI lässt sich in einer Stunde ein PHP-Formular, ein Kundenportal oder ein Backup-Skript erzeugen, das funktioniert. Ob es auch sicher ist, sieht man ihm nicht an. In einer großen Untersuchung von Veracode enthielt KI-generierter Code in 45 % der Testaufgaben eine Sicherheitslücke. Wer den Code nicht lesen kann, merkt das erst, wenn die Seite gehackt ist – oder wenn die Sicherung im Ernstfall nicht zurückgespielt werden kann.

Ich nutze KI selbst jeden Tag. Sie ist schnell, geduldig und kennt jede Funktion. Aber sie schreibt Code, der plausibel aussieht, nicht Code, der geprüft ist. Den Unterschied erkennt nur, wer weiß, wonach er suchen muss. In diesem Beitrag zeige ich die Fehler, die ich in KI-gebautem PHP am häufigsten sehe – und was sie kosten können.

Was die Forschung dazu sagt

• Veracode, GenAI Code Security Report 2025: Über 100 Sprachmodelle lösten 80 Programmieraufgaben. In 45 % der Fälle enthielt der Code eine Sicherheitslücke. Gegen Cross-Site-Scripting (XSS) waren 86 % der Beispiele nicht geschützt.
• Stanford-Studie (Perry u. a., ACM CCS 2023): Teilnehmende mit KI-Assistent schrieben bei vier von fünf Aufgaben häufiger unsicheren Code als die Gruppe ohne KI – und hielten ihren Code gleichzeitig häufiger für sicher.
• Erfundene Pakete (Spracklen u. a.): KI-Modelle empfehlen Bibliotheken, die es gar nicht gibt – bei kommerziellen Modellen im Schnitt mindestens 5,2 %, bei offenen Modellen 21,7 %. Angreifer registrieren solche Namen und füllen sie mit Schadcode („Slopsquatting“).

Das Problem ist also nicht, dass KI schlecht programmiert. Das Problem ist, dass sie sicher klingt – und dass man ohne Erfahrung keinen Grund hat, ihr zu misstrauen.

Fehler 1: Die Datenbankabfrage, die jeder umschreiben kann

Ein Klassiker, den KI immer noch regelmäßig liefert, besonders wenn man nach „einfachem“ Code fragt:

$sql = "SELECT * FROM kunden WHERE email = '" . $_GET['email'] . "'";
$ergebnis = $db->query($sql);

Das funktioniert – und erlaubt jedem Besucher, über die Adresszeile eigene SQL-Befehle einzuschleusen (SQL-Injection). Damit lassen sich Kundendaten auslesen, Passwörter ändern oder Tabellen löschen. Richtig ist eine vorbereitete Abfrage:

$abfrage = $db->prepare('SELECT * FROM kunden WHERE email = ?');
$abfrage->execute([$_GET['email']]);

Der Unterschied ist eine Zeile. Wer ihn nicht kennt, sieht ihn nicht.

Fehler 2: Ausgaben ohne Schutz

Ein Gästebuch, ein Kontaktformular, eine Kundenliste im Adminbereich: Überall, wo Eingaben wieder angezeigt werden, müssen sie maskiert werden. Fehlt das, kann ein Angreifer JavaScript einschleusen, das im Browser Ihrer Mitarbeiter läuft – mit deren Rechten. Genau diese Lücke (XSS) war in der Veracode-Studie die häufigste.

echo $kunde['name'];                                  // unsicher
echo htmlspecialchars($kunde['name'], ENT_QUOTES);   // sicher

Fehler 3: Passwörter, die man zurückrechnen kann

KI greift gern zu md5() oder sha1(), weil das in Millionen alter Tutorials steht. Solche Hashes lassen sich bei gängigen Passwörtern in kürzester Zeit zurückrechnen. PHP hat seit Version 5.5 eine eingebaute, sichere Lösung:

$hash = password_hash($passwort, PASSWORD_DEFAULT);
if (password_verify($eingabe, $hash)) { /* angemeldet */ }

Fehler 4: Der Datei-Upload als offene Tür

„Baue mir einen Upload für Kundendokumente“ – und die KI speichert die Datei unter ihrem Originalnamen im Webordner. Lädt jemand eine Datei namens rechnung.php hoch, liegt danach ein Programm auf Ihrem Server, das jeder aufrufen kann. Genau so kommen viele Hintertüren auf Websites. Aus meiner Praxis: Bei gehackten WordPress-Seiten finde ich regelmäßig PHP-Dateien im Upload-Ordner, die dort nie hätten landen dürfen.

Sicher wird ein Upload erst, wenn Dateityp und Inhalt geprüft werden, die Datei einen neuen Namen bekommt, außerhalb des öffentlichen Ordners landet und PHP dort gar nicht ausgeführt werden kann.

Fehler 5: Zugangsdaten im Code

Datenbankpasswort, API-Schlüssel für Zahlungsanbieter, SMTP-Zugang: KI schreibt sie gern direkt in die Datei, weil es so am schnellsten läuft. Landet diese Datei in einem öffentlichen Git-Repository, in einem Support-Forum oder als config.php.bak im Webordner, sind die Zugänge weg. Dazu passt Fehler Nummer sechs: eingeschaltete Fehlermeldungen (display_errors) auf der Live-Seite, die jedem Besucher Dateipfade und Datenbanknamen verraten.

Fehler 6: Bibliotheken, die es nicht gibt

Fragt man nach einer Lösung für ein Spezialproblem, empfiehlt die KI manchmal ein Composer- oder npm-Paket mit überzeugendem Namen – das nie existiert hat. Wer den Befehl einfach kopiert, installiert im besten Fall nichts, im schlimmsten Fall ein Paket, das ein Angreifer genau unter diesem Namen hinterlegt hat. Prüfen Sie jedes Paket: Wer pflegt es, seit wann gibt es es, wie viele nutzen es?

Fehler 7: Die Sicherung, die im Ernstfall nicht funktioniert

Das ist der teuerste Fehler, weil er erst auffällt, wenn alles andere schon schiefgegangen ist. „Schreib mir ein Backup-Skript“ ergibt schnell etwas, das jede Nacht eine Datei erzeugt. Ob sich daraus die Website wiederherstellen lässt, prüft niemand. Typische Fälle aus der Praxis:

• Die Sicherung liegt im Webordner. Eine Datei wie backup.sql oder backup.zip im öffentlichen Ordner kann jeder herunterladen, der den Namen errät – mit allen Kundendaten. Solche Dateien sind ein beliebtes Ziel automatischer Scanner.
• Die Sicherung liegt auf demselben Server. Wird der Server gehackt, verschlüsselt oder gekündigt, ist die Sicherung mit weg.
• Nur Dateien, keine Datenbank – oder umgekehrt. Die Website ohne Datenbank ist eine leere Hülle, die Datenbank ohne hochgeladene Bilder und Dokumente ebenso.
• Kaputte Umlaute. Ein Datenbank-Export mit falschem Zeichensatz lässt sich zwar einspielen, aber aus „Müller“ wird „Müller“ – in jedem Datensatz.
• Die Sicherung enthält den Angreifer. Wer nach einem Hack das letzte Backup einspielt, holt die Hintertür oft gleich mit zurück, weil sie schon Wochen vorher da war.
• Nie getestet. Eine Sicherung ist erst eine Sicherung, wenn man sie einmal erfolgreich zurückgespielt hat. Davor ist sie eine Hoffnung.

Was ein solcher Fehler kosten kann

Die Rechnung setzt sich aus mehreren Posten zusammen, und keiner davon ist klein:

• Bereinigung: Schadcode finden und entfernen, Lücke schließen, alle Zugänge erneuern. Bei mir beginnt das bei 490 € netto für eine übliche Website – bei individueller Software mit unklarem Code oft deutlich mehr.
• Ausfall: Keine Anfragen, keine Buchungen, keine Bestellungen, solange die Seite offline ist oder Google vor ihr warnt. Sperrt der Hoster das Paket, fallen oft auch die E-Mail-Postfächer aus.
• Datenschutz: Werden personenbezogene Daten abgegriffen, muss die Datenschutzbehörde in der Regel innerhalb von 72 Stunden informiert werden (Art. 33 DSGVO), unter Umständen auch die Betroffenen. Die DSGVO erlaubt Bußgelder bis zu 20 Millionen Euro oder 4 % des weltweiten Jahresumsatzes – im Alltag eines kleinen Betriebs wiegen meist schon Aufwand, Beratung und Vertrauensverlust schwer genug.
• Neuaufbau: Lässt sich keine saubere Sicherung zurückspielen, müssen Inhalte und Daten mühsam rekonstruiert werden – oder sind verloren.

Dem gegenüber steht eine Prüfung durch jemanden, der den Code lesen kann. Sie kostet einen Bruchteil davon.

KI nutzen – aber richtig

Ich rate niemandem, auf KI zu verzichten. Sie ist ein hervorragendes Werkzeug, wenn man sie wie einen schnellen, aber unerfahrenen Kollegen behandelt:

• Nichts live stellen, was Sie nicht verstehen. Lassen Sie sich jede Zeile erklären, bevor sie auf den Server geht.
• Gezielt nach Sicherheit fragen: „Ist dieser Code anfällig für SQL-Injection, XSS oder unsichere Uploads?“ Die Stanford-Studie zeigt: Wer der KI kritisch begegnet, bekommt sichereren Code.
• Jedes Paket prüfen, bevor Sie es installieren.
• Sicherungen außerhalb des Servers aufbewahren und mindestens einmal testweise zurückspielen.
• Vor dem Livegang prüfen lassen – vor allem, wenn Kundendaten, Logins oder Zahlungen im Spiel sind.

Wenn es schon passiert ist

Löschen Sie nichts auf eigene Faust und spielen Sie kein altes Backup ein, bevor klar ist, wann der Angreifer hereingekommen ist. Sichern Sie den aktuellen Zustand und holen Sie sich Hilfe. Mehr dazu unter WordPress gehackt; für individuelle PHP-Anwendungen unter PHP-Entwickler. Damit Updates und Sicherungen gar nicht erst liegen bleiben: WordPress-Wartung.

Passend dazu: Baukasten, KI oder gebaut – der Unterschied zeigt sich im zweiten Jahr.

Stand: Oktober 2026. Quellen: Veracode, 2025 GenAI Code Security Report (Juli 2025); N. Perry, M. Srivastava, D. Kumar, D. Boneh: „Do Users Write More Insecure Code with AI Assistants?“, ACM CCS 2023 (arXiv:2211.03622); J. Spracklen u. a.: „We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs“ (USENIX Security 2025); Art. 33 und Art. 83 DSGVO.