# Standardy PSR grupy PHP-FIG

> Standardy PSR grupy PHP-FIG: wszystkie PSR od 0 do 22 ze statusem, najważniejsze w praktyce i znaczenie PSR-3, PSR-4 i PSR-7 dla bezpieczeństwa.

Źródło: https://phpsos.de/pl/php/psr-standards/  
Stan: 25.10.2026  
Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6

**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:

| Nr | Tytuł | Status |
|---|---|---|
| PSR-0 | Autoloading Standard | przestarzały |
| PSR-1 | Basic Coding Standard | zaakceptowany |
| PSR-2 | Coding Style Guide | przestarzały |
| PSR-3 | Logger Interface | zaakceptowany |
| PSR-4 | Autoloading Standard | zaakceptowany |
| PSR-5 | PHPDoc Standard | szkic |
| PSR-6 | Caching Interface | zaakceptowany |
| PSR-7 | HTTP Message Interface | zaakceptowany |
| PSR-8 | Huggable Interface | porzucony |
| PSR-9 | Security Advisories | porzucony |
| PSR-10 | Security Reporting Process | porzucony |
| PSR-11 | Container Interface | zaakceptowany |
| PSR-12 | Extended Coding Style Guide | zaakceptowany |
| PSR-13 | Hypermedia Links | zaakceptowany |
| PSR-14 | Event Dispatcher | zaakceptowany |
| PSR-15 | HTTP Handlers | zaakceptowany |
| PSR-16 | Simple Cache | zaakceptowany |
| PSR-17 | HTTP Factories | zaakceptowany |
| PSR-18 | HTTP Client | zaakceptowany |
| PSR-19 | PHPDoc tags | szkic |
| PSR-20 | Clock | zaakceptowany |
| PSR-21 | Internationalization | szkic |
| PSR-22 | Application Tracing | szkic |

## 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](https://phpsos.de/pl/php/namespaces-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](https://phpsos.de/pl/php/php-frameworks/) 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
<?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](https://phpsos.de/pl/blog/sicher-loggen-php/).

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](https://phpsos.de/pl/php/php-sicherheitsprozess/).

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](https://phpsos.de/pl/leistungen/sicherheitsaudit-penetrationstest/).
- Instalujemy aktualizacje PHP, restartujemy wszystkie workery i dokumentujemy stan.


## Częste pytania

**Co oznacza PSR?**  
PSR to skrót od PHP Standards Recommendation. Zalecenia opracowuje i uzgadnia PHP-FIG, czyli PHP Framework Interop Group. Są dobrowolne, ale wdraża je wiele frameworków i bibliotek.

**Czy PSR-12 jest nadal obowiązujący?**  
PSR-12 jest w PHP-FIG nadal prowadzony jako zaakceptowany. PHP-FIG opublikowała jednak jako następcę PER Coding Style, który według własnych słów rozszerza i zastępuje PSR-12. Aktualna jest tam wersja 3.1.

**Czy istnieje PSR dla zgłaszania luk bezpieczeństwa?**  
Były dwie propozycje: PSR-9 dla Security Advisories i PSR-10 dla procesu zgłaszania luk bezpieczeństwa. Obie są w PHP-FIG prowadzone jako porzucone. Projekty regulują więc proces zgłaszania samodzielnie.

**Czy mój projekt musi przestrzegać PSR?**  
Nie, nie ma takiego obowiązku. PSR-4 dla autoloadingu oraz interfejsy takie jak PSR-3 czy PSR-7 wyraźnie ułatwiają jednak użycie obcych pakietów i zmianę usługodawców.

## Źródła

- [PHP-FIG: przegląd PSR](https://www.php-fig.org/psr/)
- [PHP-FIG: przebieg prac nad PSR](https://www.php-fig.org/bylaws/psr-workflow/)
- [PHP-FIG: PER Coding Style](https://www.php-fig.org/per/coding-style/)
- [PHP-FIG: PSR-3 Logger Interface](https://www.php-fig.org/psr/psr-3/)
- [PHP-FIG: PSR-7 HTTP Message Interface](https://www.php-fig.org/psr/psr-7/)
