Standardy PSR grupy PHP-FIG

Krótko: PSR (PHP Standards Recommendations) to standardy PHP-FIG, grupy uznanych projektów PHP. Ustalają wspólne reguły i interfejsy, na przykład PSR-4 dla autoloadingu, PSR-3 dla loggerów, PSR-7 dla komunikatów HTTP i PSR-11 dla kontenerów. Każdy PSR ma status: zaakceptowany, szkic, przestarzały lub porzucony. PSR sprawiają, że kod jest bardziej wymienny i łatwiejszy do sprawdzenia, ale nie zamykają luk w interpreterze PHP, takich jak PHP2Shell.

Czym jest PHP-FIG i czym są PSR?

PHP-FIG to skrót od PHP Framework Interop Group. Grupa sama opisuje swój cel jako rozwijanie PHP przez współpracę i standardy. Za PSR nie stoi więc żaden producent, lecz uzgodnienie między projektami, które chcą utrzymać wzajemną zgodność swojego oprogramowania.

Dla osób podejmujących decyzje korzyść jest wymierna: jeśli aplikacja trzyma się interfejsów PSR, można wymienić na przykład bibliotekę logowania, nie dotykając całego kodu. Zmniejsza to zależność od poszczególnych pakietów i usługodawców.

Droga PSR: od Pre-Draft do Accepted

Statut PHP-FIG opisuje stały przebieg:

1. Pre-Draft: Wyjaśnia się, czy jest dość zainteresowania. Powstaje grupa robocza, a po udanym głosowaniu propozycja otrzymuje numer PSR.
2. Draft: Propozycja jest opracowywana, a alternatywy i uzasadnienia trafiają do metadokumentu.
3. Review: Społeczność testuje specyfikację za pomocą próbnych implementacji, co najmniej przez cztery tygodnie i do czasu, aż powstaną dwie niezależne, solidne implementacje.
4. Accepted: Po udanym głosowaniu PSR zostaje przyjęty; grupa robocza się rozwiązuje.

Poza tym są jeszcze dwa inne stany. Deprecated oznacza: przyjęty, ale już niezalecany, zwykle dlatego, że zastępuje go nowszy standard. Abandoned oznacza: nie prowadzi się już nad nim prac.

Wszystkie PSR ze statusem

Stan według przeglądu PHP-FIG w chwili powstania tej strony:

Najważniejsze PSR w praktyce

• PSR-4 (autoloading): odwzorowuje nazwy klas na ścieżki plików i jest podstawą autoloadera Composera. Szczegóły na stronie Przestrzenie nazw i autoloading.
• PSR-1 i PER Coding Style: wspólne reguły pisowni i formatowania. PER Coding Style rozszerza i według PHP-FIG zastępuje PSR-12 oraz zakłada PSR-1.
• PSR-3 (logger): jednolity interfejs loggera w przestrzeni nazw Psr\Log z ośmioma poziomami od emergency do debug.
• PSR-7, PSR-15, PSR-17, PSR-18 (HTTP): interfejsy dla żądań i odpowiedzi, middleware, fabryk i klientów HTTP. Wiele frameworków PHP na nich bazuje lub oferuje mosty.
• PSR-11 (kontener): wspólny interfejs dla kontenerów wstrzykiwania zależności.
• PSR-6 i PSR-16 (cache): dwa interfejsy pamięci podręcznej, szczegółowy i prosty.
• PSR-14 i PSR-20 (zdarzenia, zegar): wspólne interfejsy dla zdarzeń i dla bieżącego czasu. Wymienny zegar czyni kod zależny od czasu, na przykład wygasanie tokenów, dobrze testowalnym.

Numery nie mówią zresztą nic o znaczeniu. Nadaje się je przy wejściu w fazę szkicu, dlatego przestarzałe i porzucone propozycje stoją między ważnymi, zaakceptowanymi standardami.

<?php
use Psr\Log\LoggerInterface;

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

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

Co PSR mają wspólnego z bezpieczeństwem

Kilka standardów dotyka bezpieczeństwa bezpośrednio. PSR-3 ustala, że wyjątki przekazuje się w kontekście pod kluczem exception, a symbole zastępcze takie jak {datei} są podmieniane wartościami z kontekstu. Wartości nie powinny przy tym być wcześniej maskowane, ponieważ logger nie wie, gdzie zostaną później wyświetlone. Kto wyświetla logi w interfejsie webowym, musi tam maskować. Więcej w artykule Bezpieczne logowanie.

PSR-7 opisuje komunikaty HTTP jako obiekty niezmienne i za pomocą UploadedFileInterface::moveTo() oferuje jednolity sposób zapisywania przesłanych plików. Specyfikacja wymaga, aby oryginalny plik został po tym usunięty. Sprawdzenie typu pliku i miejsca docelowego pozostaje zadaniem aplikacji.

Godne uwagi jest to, że PSR-9 (Security Advisories) i PSR-10 (Security Reporting Process) porzucono. Wspólnego standardu komunikatów o bezpieczeństwie więc nie ma; każdy projekt reguluje to samodzielnie. Jak z lukami radzi sobie sam projekt PHP, opisuje strona Jak projekt PHP traktuje luki bezpieczeństwa.

Przeciw PHP2Shell standardy nie pomagają: luki CVE-2026-109618 i CVE-2026-109619 leżą w interpreterze. Obowiązkowa jest aktualizacja do PHP 8.5.12, 8.4.27, 8.3.36 lub 8.2.35 i restart wszystkich procesów PHP.

Jak konkretnie pomaga PHP SOS?

• Sprawdzamy, jak Państwa aplikacja loguje, i dbamy o to, aby wyjątki trafiały do logu, ale bez danych dostępowych i identyfikatorów sesji.
• Oceniamy, jak zrealizowano przetwarzanie przesyłanych plików i HTTP, także gdy odbywa się ono przez biblioteki PSR-7.
• Badamy własne rozwiązania w ramach audytu bezpieczeństwa i testu penetracyjnego.
• Instalujemy aktualizacje PHP, restartujemy wszystkie workery i dokumentujemy stan.

Częste pytania

Źródła

• PHP-FIG: przegląd PSR
• PHP-FIG: przebieg prac nad PSR
• PHP-FIG: PER Coding Style
• PHP-FIG: PSR-3 Logger Interface
• PHP-FIG: PSR-7 HTTP Message Interface