Kurz gesagt: Ein Sicherheits-Code-Review für PHP ist das gezielte Lesen von Quelltext mit einer Frage: Wo können fremde Eingaben etwas tun, das sie nicht dürfen? Bewährt sind zwei Formen, ein Review jeder Änderung und ein Grundreview des ganzen Projekts, gestützt auf statische Analyse mit PHPStan oder Psalm. Lücken im PHP-Interpreter wie PHP2Shell findet ein Review nicht, wohl aber die vielen Fehler, die im eigenen Code entstehen.
Warum gerade jetzt in den eigenen Code schauen?
PHP2Shell hat in der letzten Oktoberwoche 2026 vor allem Admins beschäftigt. Patchen, neu starten, nachweisen: Die Arbeit lag auf dem Server. Für Entwicklungsteams bleibt danach eine unbequeme Frage. Wenn ein Angreifer über eine andere Lücke Code ausführen kann, was findet er in unserer Anwendung vor? Und wie viele dieser Lücken haben wir selbst geschrieben?
Die OWASP Top 10 zeigen seit Jahren, dass die meisten Schwachstellen in Webanwendungen nicht exotisch sind. Fehlende Zugriffskontrolle, Injection und unsichere Konfiguration stehen weit oben. Das sind Fehler, die ein geübter Blick im Quelltext findet, lange bevor ein Angreifer sie ausprobiert.
Dazu kommt ein praktischer Grund. Viele Unternehmen lassen ihre Server gerade ohnehin prüfen, patchen und härten. Wer die eigene Anwendung im selben Zug ansieht, schließt die Lücke zwischen Betrieb und Entwicklung. Ein gehärteter Server mit verwundbarer Anwendung bleibt angreifbar, und eine sauber geschriebene Anwendung auf ungepatchtem PHP ebenso.
Grundreview oder Änderungsreview?
Das OWASP Cheat Sheet zum Secure Code Review unterscheidet zwei Arten, die sich in der Praxis ergänzen:
| Art | Wann | Umfang | Ziel |
|---|---|---|---|
| Grundreview (Baseline) | neues Projekt, großes Release, nach einem Vorfall | ganzes Projekt, nach Risiko gewichtet | Bestand an Schwachstellen erfassen |
| Änderungsreview (Diff) | jeder Pull Request | nur geänderter Code | neue Fehler verhindern |
Ein Grundreview nach einem Vorfall ist besonders wertvoll. Wer gerade einen Server bereinigt hat, sollte wissen, ob die Anwendung weitere Einfallstore bietet. Das Änderungsreview hält den Stand danach sauber, weil jede Änderung vor dem Zusammenführen auch unter Sicherheitsgesichtspunkten gelesen wird.
Code-Review in PHP: Wo sich Sicherheitsfehler häufen
In PHP-Projekten lohnt ein gezielter Blick auf bestimmte Funktionen und Muster. Sie sind nicht verboten, aber jede Fundstelle verdient die Frage, ob fremde Daten hineingelangen können.
| Muster im Code | Mögliches Risiko | Vertiefung |
|---|---|---|
| SQL per String-Verkettung mit Variablen | SQL-Injection | SQL-Injection in PHP verhindern |
unserialize() auf Daten von außen |
Objektinjektion | Unsichere Deserialisierung in PHP |
include oder require mit variablem Pfad |
Einbinden fremder Dateien | Local und Remote File Inclusion verhindern |
exec(), system(), shell_exec(), proc_open() |
Befehlsausführung | Command Injection |
Ausgabe ohne htmlspecialchars() |
Cross-Site-Scripting | kontextgerechtes Escaping |
== bei Tokens oder Hashes |
Typumwandlung umgeht Prüfungen | hash_equals(), strikte Vergleiche |
eval(), extract() auf Eingaben |
Code- oder Variableninjektion | meist ersatzlos streichen |
Ein schneller erster Überblick gelingt mit einer einfachen Suche. Sie ersetzt kein Review, zeigt aber, wo man anfangen sollte:
# Fundstellen riskanter Funktionen im eigenen Code (vendor ausgeschlossen)
grep -rnE "\b(unserialize|eval|extract|shell_exec|exec|system|passthru|proc_open)\s*\(" src/ app/ 2>/dev/null
Mindestens ebenso wichtig ist, was im Code fehlt. Prüft jeder Controller, ob der angemeldete Nutzer genau diesen Datensatz sehen oder ändern darf? Werden Uploads auf Typ und Ablageort beschränkt? Solche Lücken findet keine Suche nach Funktionsnamen, nur das Lesen des Ablaufs.
Werkzeuge, die das Review tragen
Statische Analyse prüft Code, ohne ihn auszuführen. PHPStan und Psalm finden Typfehler, nicht erreichbaren Code und falsche Annahmen über Rückgabewerte. Psalm bietet zusätzlich eine Taint-Analyse, die verfolgt, ob Daten aus Anfragen ungeprüft an kritische Stellen fließen. Beide lassen sich stufenweise verschärfen, sodass auch ältere Projekte einsteigen können. Einen Überblick gibt Statische Analyse: PHPStan und Psalm.
# Statische Analyse im Projekt, Stufe schrittweise erhöhen
vendor/bin/phpstan analyse src --level=5
# Taint-Analyse mit Psalm
vendor/bin/psalm --taint-analysis
Werkzeuge liefern Hinweise, keine Urteile. Jeder Treffer braucht eine Bewertung, und ein leerer Bericht heißt nicht, dass die Anwendung sicher ist.
Ebenso wichtig wie das Finden ist das Festhalten. Jeder Befund sollte mit Fundstelle, kurzer Beschreibung, Einschätzung des Risikos, empfohlener Behebung und Status erfasst werden, am besten direkt im Ticketsystem des Teams. So lässt sich nachvollziehen, was behoben, was bewusst akzeptiert und was noch offen ist. Nach der Behebung lohnt ein zweiter Blick: Ist die Ursache beseitigt oder nur das eine Symptom? Taucht dasselbe Muster an anderen Stellen im Code auf? Ein Fehler, der einmal gemacht wurde, steckt erfahrungsgemäß selten nur an einer Stelle.
Eine Prüfliste für das eigene Team
Für Änderungsreviews hat sich eine kurze, feste Liste bewährt. Sie gehört in die Vorlage für Pull Requests:
- Woher kommen alle Daten, die diese Änderung verarbeitet, und werden sie serverseitig geprüft?
- Werden Datenbankabfragen ausschließlich mit Platzhaltern gebaut?
- Ist jede Ausgabe für ihren Kontext escaped, also HTML, Attribut, JavaScript oder URL?
- Prüft der Code die Berechtigung für genau dieses Objekt, nicht nur die Anmeldung?
- Gelangen Passwörter, Tokens oder personenbezogene Daten in Logs oder Fehlermeldungen?
- Stehen Geheimnisse im Code oder in versionierten Dateien?
- Wurden neue Abhängigkeiten aufgenommen, und sind sie gepflegt?
Lassen Sie sicherheitskritische Teile wie Anmeldung, Rechteverwaltung, Zahlungsabläufe und Uploads immer von einer zweiten Person lesen, die nicht am Code beteiligt war. Der fremde Blick findet Annahmen, die der Autor für selbstverständlich hält.
Wie hilft PHP SOS konkret?
- Wir führen mit spezialisierten Partnern ein Grundreview Ihrer PHP-Anwendung durch, gewichtet nach den Teilen mit dem höchsten Risiko.
- Wir richten PHPStan oder Psalm passend zum Stand Ihres Projekts ein und schreiben die Prüfliste für Ihre Pull Requests.
- Wir verbinden das Review mit einem Blick auf Server und Konfiguration, denn viele Lücken entstehen erst im Zusammenspiel.
- Wo eine Prüfung von außen gewünscht ist, ergänzen wir das Review durch Sicherheitsaudit und Penetrationstest.
Fazit: Ein Code-Review ist die günstigste Stelle, Sicherheitsfehler zu beheben, nämlich bevor sie ausgeliefert werden. Wer jede Änderung mit einer kurzen Liste prüft und das Projekt gelegentlich vollständig durchsieht, verkleinert die Angriffsfläche dauerhaft.
Häufige Fragen
Was ist der Unterschied zwischen Code-Review und Penetrationstest?
Ein Code-Review liest den Quelltext und findet Fehler, bevor sie ausgeliefert werden. Ein Penetrationstest greift die laufende Anwendung von außen an. Beide ergänzen sich: Das Review findet Ursachen, der Test zeigt, was tatsächlich ausnutzbar ist.
Findet ein Code-Review Lücken wie PHP2Shell?
Nein. PHP2Shell steckt im PHP-Interpreter, nicht im Anwendungscode. Dagegen hilft nur ein PHP-Update mit Neustart. Ein Review findet Fehler im eigenen Code, etwa Injection, fehlende Berechtigungsprüfungen oder unsichere Deserialisierung.
Reichen PHPStan oder Psalm für ein Sicherheits-Review?
Sie sind eine gute Grundlage und finden viele Fehler automatisch. Logikfehler, fehlende Berechtigungsprüfungen und falsche Annahmen über Abläufe erkennt aber nur ein Mensch, der weiß, was die Anwendung tun soll.
Wie lange dauert ein Sicherheits-Code-Review?
Das hängt vom Umfang ab. Ein Review jeder Änderung im Pull Request kostet wenig Zeit. Ein vollständiges Review eines gewachsenen Projekts ist ein eigenes Vorhaben, das man nach Risiko auf die wichtigsten Teile begrenzt.