PSR-Standards der PHP-FIG

Kurz gesagt: PSRs (PHP Standards Recommendations) sind Standards der PHP-FIG, einer Gruppe etablierter PHP-Projekte. Sie legen gemeinsame Regeln und Schnittstellen fest, etwa PSR-4 für das Autoloading, PSR-3 für Logger, PSR-7 für HTTP-Nachrichten und PSR-11 für Container. Jeder PSR hat einen Status: akzeptiert, Entwurf, veraltet oder aufgegeben. PSRs machen Code austauschbarer und leichter prüfbar, schließen aber keine Lücken im PHP-Interpreter wie PHP2Shell.

Was ist die PHP-FIG und was sind PSRs?

PHP-FIG steht für PHP Framework Interop Group. Die Gruppe beschreibt ihr Ziel selbst damit, PHP durch Zusammenarbeit und Standards voranzubringen. Hinter einem PSR steht also kein Hersteller, sondern eine Abstimmung zwischen Projekten, die ihre Software untereinander kompatibel halten wollen.

Für Entscheider ist der Nutzen greifbar: Hält sich eine Anwendung an PSR-Schnittstellen, lässt sich etwa die Logging-Bibliothek austauschen, ohne den ganzen Code anzufassen. Das senkt die Abhängigkeit von einzelnen Paketen und Dienstleistern.

Der Weg eines PSR: von Pre-Draft bis Accepted

Die Satzung der PHP-FIG beschreibt einen festen Ablauf:

1. Pre-Draft: Es wird geklärt, ob genug Interesse besteht. Eine Arbeitsgruppe bildet sich, nach erfolgreicher Abstimmung erhält der Vorschlag eine PSR-Nummer.
2. Draft: Der Vorschlag wird ausgearbeitet, Alternativen und Begründungen kommen in ein Meta-Dokument.
3. Review: Die Gemeinschaft testet die Spezifikation mit Probe-Implementierungen, mindestens vier Wochen lang und bis zwei unabhängige, tragfähige Umsetzungen vorliegen.
4. Accepted: Nach erfolgreicher Abstimmung ist der PSR angenommen; die Arbeitsgruppe löst sich auf.

Daneben gibt es zwei weitere Zustände. Deprecated bedeutet: angenommen, aber nicht mehr empfohlen, meist weil ein neuerer Standard ihn ersetzt. Abandoned bedeutet: Es wird nicht mehr daran gearbeitet.

Alle PSRs mit Status

Stand laut Übersicht der PHP-FIG zum Zeitpunkt dieser Seite:

Die wichtigsten PSRs für die Praxis

• PSR-4 (Autoloading): bildet Klassennamen auf Dateipfade ab und ist die Grundlage des Composer-Autoloaders. Details auf der Seite Namespaces und Autoloading.
• PSR-1 und PER Coding Style: gemeinsame Regeln für Schreibweise und Formatierung. PER Coding Style erweitert und ersetzt laut PHP-FIG den PSR-12 und setzt PSR-1 voraus.
• PSR-3 (Logger): einheitliche Logger-Schnittstelle im Namespace Psr\Log mit acht Stufen von emergency bis debug.
• PSR-7, PSR-15, PSR-17, PSR-18 (HTTP): Schnittstellen für Anfragen und Antworten, Middleware, Fabriken und HTTP-Clients. Viele PHP-Frameworks bauen darauf auf oder bieten Brücken an.
• PSR-11 (Container): gemeinsame Schnittstelle für Dependency-Injection-Container.
• PSR-6 und PSR-16 (Cache): zwei Schnittstellen für Zwischenspeicher, eine ausführliche und eine einfache.
• PSR-14 und PSR-20 (Events, Uhr): gemeinsame Schnittstellen für Ereignisse und für die aktuelle Zeit. Eine austauschbare Uhr macht zeitabhängigen Code, etwa das Ablaufen von Tokens, gut testbar.

Die Nummern sagen übrigens nichts über die Bedeutung aus. Sie werden beim Eintritt in die Entwurfsphase vergeben, deshalb stehen veraltete und aufgegebene Vorschläge zwischen wichtigen, akzeptierten Standards.

<?php
use Psr\Log\LoggerInterface;

final class Bestellimport
{
    public function __construct(private LoggerInterface $log) {}

    public function importieren(string $datei): void
    {
        try {
            // ... Datei verarbeiten ...
        } catch (\Throwable $e) {
            $this->log->error('Import von {datei} fehlgeschlagen', [
                'datei'     => basename($datei),
                'exception' => $e,
            ]);
        }
    }
}

Was PSRs mit Sicherheit zu tun haben

Mehrere Standards berühren die Sicherheit direkt. PSR-3 legt fest, dass Exceptions unter dem Schlüssel exception im Kontext übergeben werden und Platzhalter wie {datei} aus dem Kontext ersetzt werden. Werte sollen dabei nicht vorab maskiert werden, weil der Logger nicht weiß, wo sie später angezeigt werden. Wer Logs in einer Weboberfläche anzeigt, muss dort maskieren. Mehr dazu im Beitrag Sicher loggen.

PSR-7 beschreibt HTTP-Nachrichten als unveränderliche Objekte und bietet mit UploadedFileInterface::moveTo() einen einheitlichen Weg, hochgeladene Dateien zu speichern. Die Spezifikation verlangt, dass die Originaldatei danach entfernt ist. Die Prüfung von Dateityp und Zielort bleibt Aufgabe der Anwendung.

Bemerkenswert ist, dass PSR-9 (Security Advisories) und PSR-10 (Security Reporting Process) aufgegeben wurden. Einen gemeinsamen Standard für Sicherheitsmeldungen gibt es damit nicht; jedes Projekt regelt das selbst. Wie das PHP-Projekt selbst mit Lücken umgeht, beschreibt die Seite Wie das PHP-Projekt Sicherheitslücken behandelt.

Gegen PHP2Shell helfen Standards nicht: Die Lücken CVE-2026-109618 und CVE-2026-109619 liegen im Interpreter. Pflicht ist das Update auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 und der Neustart aller PHP-Prozesse.

Wie hilft PHP SOS konkret?

• Wir prüfen, wie Ihre Anwendung loggt, und stellen sicher, dass Exceptions im Log landen, aber keine Zugangsdaten oder Sitzungskennungen.
• Wir bewerten, wie Upload- und HTTP-Verarbeitung umgesetzt sind, auch wenn sie über PSR-7-Bibliotheken laufen.
• Wir untersuchen Eigenentwicklungen im Rahmen eines Sicherheitsaudits und Penetrationstests.
• Wir spielen PHP-Updates ein, starten alle Worker neu und dokumentieren den Stand.

Häufige Fragen

Quellen

• PHP-FIG: PSR-Übersicht
• PHP-FIG: PSR-Workflow
• PHP-FIG: PER Coding Style
• PHP-FIG: PSR-3 Logger Interface
• PHP-FIG: PSR-7 HTTP Message Interface