In jeder Sprache klafft eine Lücke zwischen dem, was heute korrekt ist, und dem, worüber am meisten geschrieben wurde. In PHP ist diese Lücke ungewöhnlich groß, weil sich die Sprache zwischen 5.x und 8.x enorm verändert hat, während das Internet jedes Tutorial aufbewahrt hat, das unterwegs entstanden ist.
Für die KI-gestützte Entwicklung hat das eine konkrete, vorhersehbare Folge: Generiertes PHP neigt zu den Idiomen jener Ära, aus der das meiste veröffentlichte Material stammt — und das ist nicht die Ära, in der Sie arbeiten. Der Code sieht konventionell aus, genau darin liegt das Problem, und er trägt gelegentlich Annahmen mit sich, die schon seit mehreren Major-Versionen nicht mehr sicher sind.
Das ist kein Argument gegen den Einsatz dieser Werkzeuge. Es ist ein Argument dafür, zu wissen, worauf man achten muss — bei PHP ist das eine kurze und stabile Liste.
Warum ausgerechnet PHP
Drei Dinge verstärken sich gegenseitig.
- Die Menge an altem Material ist enorm. PHP war über ein Jahrzehnt lang die Standardsprache des Web, und in dieser Zeit entstanden unzählige Tutorials, Forenantworten und Blogbeiträge — die meisten davon nie aktualisiert.
- Die Sprache hat sich stärker verändert als die meisten. Skalare Typen, Rückgabetypen, Enums, readonly Properties, Constructor Promotion, First-Class Callables und ein deutlich strengeres Fehlermodell kamen alle erst, nachdem der Großteil dieses Materials geschrieben war.
- Der alte Code läuft weiterhin. Anders als in Sprachen, in denen ein Breaking Release das Ökosystem nach vorn gezwungen hat, läuft sehr viel Code aus der PHP-5-Ära bis heute — dadurch bleiben die alten Muster nicht nur in historischem, sondern auch in aktuellem Material präsent.
Das Ergebnis ist eine Verteilung mit Übergewicht auf Mustern, die syntaktisch gültig und sofort lauffähig sind — und so, wie heute niemand mehr PHP schreiben sollte.
Die Muster, auf die Sie achten sollten
1. Per String zusammengebaute Abfragen
Das folgenreichste Muster. Ein Jahrzehnt lang haben Tutorials den Datenbankzugriff so gezeigt, dass Variablen in einen Abfrage-String konkateniert werden, und dieses Muster ist tief verankert. Generierter Code nutzt oft korrekt einen Query Builder und fällt dann für genau den einen Fall, den der Builder umständlich macht, in rohe String-Interpolation zurück — ein dynamisches ORDER BY, eine berechnete Spaltenliste, eine IN-Klausel.
Es funktioniert, es besteht die Tests, und es ist ein Injection-Vektor. Prüfen Sie jede rohe Abfrage in generiertem Code so, als hätte sie ein Fremder geschrieben — im Grunde ist genau das der Fall.
2. Lose Vergleiche und Type Juggling
PHP 8 hat das Schlimmste am Vergleichsverhalten zwischen String und Zahl behoben, doch generierter Code greift weiterhin zu ==, wo === hingehört — besonders in Prüfungen zur Authentifizierung und Autorisierung, wo die Folgen am größten sind. Altes Material nutzte lose Vergleiche bedenkenlos, weil sie meistens funktionierten.
3. Manuelles Escaping statt der Mittel des Frameworks
Selbstgebautes Escaping, manuell gesetzte Header, eigene Funktionen zur Sanitisierung. In der Zeit vor den Frameworks war das nötig; heute ist es ein Weg, Schutzmechanismen zu umgehen, die Ihr Framework korrekt bereitstellt. Generierter Code, der Ausgaben selbst escaped, obwohl das Templating der Codebasis das bereits tut, ist ein Signal dafür, dass das Modell zu einem älteren Idiom gegriffen hat.
4. Veraltete Kryptografie und Passwortverarbeitung
Alles, was mit Hashing, Tokens oder Zufallswerten zu tun hat, verdient besondere Aufmerksamkeit. Altes Material zeigt Vorgehensweisen, die damals gängige Empfehlung waren und heute schlicht falsch sind. Modernes PHP bietet dafür durchweg korrekte, einfache Mittel; generierter Code greift nicht zuverlässig darauf zurück.
5. Ungeprüfter Zugriff auf Superglobals
Request-Daten direkt auslesen und ohne Prüfung verwenden — in einem Framework, das eine Validierungsschicht mitbringt. Kein anderes Muster weist so zuverlässig darauf hin, dass die Ausgabe aus Material aus der Zeit vor den Frameworks stammt.
6. Signaturen ohne Typen
Keine Sicherheitslücke, aber eine schleichende Erosion. Generierter Code lässt Parameter- und Rückgabetypen häufig weg, und jede Auslassung nimmt Ihrer statischen Analyse eine Prüfung. Über ein paar hundert generierte Funktionen hinweg verliert eine Codebasis messbar an Typabdeckung, ohne dass eine einzelne Änderung falsch aussähe.
Warum es das Review übersteht
Das Problem ist nicht, dass der Code verdächtig aussieht. Das Problem ist, dass er gewöhnlich aussieht.
- Er ist stilistisch konsistent. Generierter Code ist schon von seiner Entstehung her konventionell — und genau darauf ist ein Reviewer, der nach Auffälligkeiten sucht, nicht eingestellt.
- Er funktioniert. Für die Eingaben, mit denen getestet wurde, ist das Verhalten korrekt.
- Der Reviewer prüft einen Diff, kein Design. Ein Injection-Risiko in einer Methode mit fünfzehn Zeilen liest sich wie fünfzehn gewöhnliche Zeilen.
- Die Menge überholt die Aufmerksamkeit. Pro Reviewer-Stunde entsteht mehr Code als früher, und die Qualität des Reviews sinkt mit der Menge genau so, wie man es erwarten würde.
Das Risiko verstärkt sich: Am größten ist es in alten Codebasen — also genau dort, wo Teams am häufigsten zu KI-Unterstützung greifen, weil ihnen der Code fremd ist. Das Modell erzeugt plausiblen Code im Legacy-Stil, der sich dem umgebenden Legacy-Stil anpasst, und nichts wirkt fehl am Platz.
Wie Sie sich davor schützen
Fast alles davon ist maschinell erkennbar. Also sollte die Verteidigung auch maschinell erzwungen werden, statt der Aufmerksamkeit von Reviewern überlassen zu bleiben.
- Statische Analyse auf hohem Level, blockierend in CI. PHPStan oder Psalm finden fehlende Typen, unsichere Annahmen und einen guten Teil des Problems mit losen Vergleichen, bevor ein Mensch sie zu sehen bekommt.
- Ein Ruleset für Taint-Analyse oder Sicherheit, das gezielt darauf ausgelegt ist, per String zusammengebaute Abfragen zu finden.
- declare(strict_types=1) überall, damit Type Juggling laut scheitert statt still.
- Scans von Abhängigkeiten und Schwachstellen in CI, denn generierter Code schlägt gelegentlich ein Paket vor, das nicht mehr gepflegt wird, oder eine Version mit bekannten Schwachstellen.
- Eine kurze Review-Checkliste für generierten Code — rohe Abfragen, Vergleiche in Auth-Pfaden, alles Kryptografische, alles, was Request-Daten direkt ausliest.
- Ein zweiter Reviewer für Änderungen an der Sicherheitsgrenze, unabhängig davon, wer oder was sie geschrieben hat.
Und die strukturelle Lösung, die sich auch auf alles andere auszahlt: bringen Sie die Codebasis auf den aktuellen Stand. Eine moderne PHP-Version mit strikten Typen, ein gepflegtes Framework und eine hohe Abdeckung durch statische Analyse verkleinern den Raum für plausibel wirkenden, aber falschen Code drastisch — die meisten alten Idiome lassen sich nicht kompilieren, kommen nicht durch die Analyse oder scheitern sichtbar.
Das ist dasselbe Argument, das wir in der Review-Policy für KI-gestützte Laravel-Entwicklung zur Lesbarkeit einer Codebasis machen — und ein weiterer Grund, warum die Frage nach der Version in ist PHP noch die richtige Wahl schwerer wiegt als die Frage nach der Sprache.
Die Governance-Position
Für einen CTO oder VP of Engineering, der dazu eine belastbare Position braucht:
- Verbieten Sie es nicht. Teams nutzen diese Werkzeuge ohnehin, und ein Verbot ersetzt eine überprüfbare Praxis durch eine verdeckte.
- Verlangen Sie Offenlegung, damit Reviewer wissen, welche Diffs die Checkliste verdienen.
- Erzwingen Sie mechanisch, was sich mechanisch erzwingen lässt. Jede Regel, die Sie aus einem Richtliniendokument in einen CI-Job verschieben, hängt nicht länger von Aufmerksamkeit ab.
- Halten Sie Menschen an der Sicherheitsgrenze. Authentifizierung, Autorisierung, Zahlungen, personenbezogene Daten.
- Finanzieren Sie die Modernisierung. Die wirksamste einzelne Maßnahme gegen schlechten generierten Code ist eine Codebasis, in der schlechter Code die Toolchain nicht übersteht.
Diese Arbeit leisten wir in unserer PHP-Entwicklung und unserer individuellen PHP-Modernisierung, und sie hängt direkt mit der größeren Frage zusammen, wo KI sich ihren Platz in der Umsetzung wirklich verdient — unsere KI-Integration und unser KI-Engineering-Team decken diese Seite ab.
Häufige Fragen
Enthält KI-generiertes PHP Sicherheitslücken?
Es kann sie enthalten, und die Lücken sind eher vorhersehbar als zufällig: per String zusammengebaute Abfragen, lose Vergleiche in Pfaden der Authentifizierung, veraltete Empfehlungen zur Kryptografie und ungeprüfte Request-Daten. Alle haben dieselbe Ursache — ein Jahrzehnt veröffentlichtes Material, das älter ist als die Sicherheitsfeatures des modernen PHP.
Warum ist das in PHP schlimmer als in anderen Sprachen?
Weil sich PHP zwischen 5.x und 8.x stärker verändert hat als die meisten Sprachen, während eine enorme Menge nie aktualisierter Veröffentlichungen bestehen blieb — und weil sehr viel Code aus der PHP-5-Ära bis heute läuft. Die Verteilung dessen, was geschrieben wurde, ist damit deutlich stärker zur Vergangenheit verschoben als in jüngeren Ökosystemen.
Wie erkennen wir das im Code Review?
Verlassen Sie sich nicht auf das Review allein — der Code sieht gewöhnlich aus, und genau das übersehen Reviewer, die nach Auffälligkeiten suchen. Erzwingen Sie strikte Typen und hohe Level der statischen Analyse in CI, ergänzen Sie ein Ruleset für Sicherheit, das per String zusammengebaute Abfragen findet, und führen Sie eine kurze Checkliste für die vier oder fünf konkreten Muster.
Sollten wir KI-Coding-Tools bei Legacy-PHP nicht mehr einsetzen?
Nein, aber behandeln Sie Legacy-Codebasen als den riskanteren Fall. Generierter Code, der sich dem umgebenden Legacy-Stil anpasst, ist am schwersten zu erkennen. Erst die Modernisierung — aktuelle Version, strikte Typen, statische Analyse — macht KI-Unterstützung dort sicher und nicht nur schnell.
Gilt das auch für Frameworks wie Laravel und Symfony?
In geringerem Maß, weil die Konventionen der Frameworks stark und gut vertreten sind. Dasselbe Problem tritt aber als Idiome älterer Framework-Versionen auf — veraltete Helper, überholte Validierungssyntax, Muster, die längst durch Bordmittel ersetzt wurden. Die Verteidigung ist dieselbe: Erzwingen Sie sie in der Toolchain.
Lassen Sie die Toolchain die Arbeit machen
Wir richten die statische Analyse, die Sicherheitsregeln und die CI-Gates ein, die diese Klasse von Problemen automatisch scheitern lassen, statt sie von der Aufmerksamkeit eines Reviewers abhängig zu machen. Sprechen Sie mit unserem Team; wir antworten innerhalb eines Werktags.