Standardy PSR od PHP-FIG

Stručně: PSR (PHP Standards Recommendations) jsou standardy skupiny PHP-FIG, tedy sdružení zavedených projektů PHP. Stanovují společná pravidla a rozhraní, například PSR-4 pro autoloading, PSR-3 pro loggery, PSR-7 pro zprávy HTTP a PSR-11 pro kontejnery. Každé PSR má stav: přijaté, návrh, zastaralé nebo opuštěné. PSR činí kód zaměnitelnějším a snáze kontrolovatelným, ale neuzavírají zranitelnosti v interpretu PHP, jako je PHP2Shell.

Co je PHP-FIG a co jsou PSR?

PHP-FIG znamená PHP Framework Interop Group. Skupina sama popisuje svůj cíl tak, že chce rozvíjet PHP spoluprací a standardy. Za PSR tedy nestojí výrobce, ale dohoda mezi projekty, které chtějí svůj software udržet vzájemně kompatibilní.

Pro rozhodovatele je přínos hmatatelný: pokud se aplikace drží rozhraní PSR, lze například vyměnit knihovnu pro logování, aniž by se muselo sahat do celého kódu. To snižuje závislost na jednotlivých balíčcích a dodavatelích.

Cesta PSR: od Pre-Draft po Accepted

Stanovy PHP-FIG popisují pevný postup:

1. Pre-Draft: zjišťuje se, zda je dostatečný zájem. Vytvoří se pracovní skupina a po úspěšném hlasování dostane návrh číslo PSR.
2. Draft: návrh se rozpracuje, alternativy a zdůvodnění se uvedou v metadokumentu.
3. Review: komunita testuje specifikaci pomocí zkušebních implementací, nejméně čtyři týdny a dokud nevzniknou dvě nezávislé, životaschopné implementace.
4. Accepted: po úspěšném hlasování je PSR přijato; pracovní skupina se rozpustí.

Kromě toho existují dva další stavy. Deprecated znamená: přijato, ale už se nedoporučuje, většinou proto, že ho nahradil novější standard. Abandoned znamená: už se na něm nepracuje.

Všechna PSR se stavem

Stav podle přehledu PHP-FIG v době vzniku této stránky:

Nejdůležitější PSR pro praxi

• PSR-4 (autoloading): přiřazuje názvy tříd cestám k souborům a je základem autoloaderu Composeru. Podrobnosti na stránce Jmenné prostory a autoloading.
• PSR-1 a PER Coding Style: společná pravidla pro zápis a formátování. PER Coding Style podle PHP-FIG PSR-12 rozšiřuje a nahrazuje a předpokládá PSR-1.
• PSR-3 (logger): jednotné rozhraní loggeru ve jmenném prostoru Psr\Log s osmi úrovněmi od emergency po debug.
• PSR-7, PSR-15, PSR-17, PSR-18 (HTTP): rozhraní pro požadavky a odpovědi, middleware, továrny a klienty HTTP. Na nich staví mnoho frameworků PHP nebo nabízí mosty.
• PSR-11 (kontejner): společné rozhraní pro kontejnery dependency injection.
• PSR-6 a PSR-16 (cache): dvě rozhraní pro mezipaměť, podrobné a jednoduché.
• PSR-14 a PSR-20 (události, hodiny): společná rozhraní pro události a pro aktuální čas. Zaměnitelné hodiny činí kód závislý na čase, například vypršení platnosti tokenů, dobře testovatelným.

Čísla mimochodem nevypovídají o významu. Přidělují se při vstupu do fáze návrhu, proto stojí zastaralé a opuštěné návrhy mezi důležitými, přijatými standardy.

<?php
use Psr\Log\LoggerInterface;

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

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

Co mají PSR společného s bezpečností

Několik standardů se bezpečnosti dotýká přímo. PSR-3 stanoví, že se výjimky předávají v kontextu pod klíčem exception a že se zástupné znaky jako {datei} nahrazují hodnotami z kontextu. Hodnoty se přitom nemají předem escapovat, protože logger neví, kde se později zobrazí. Kdo zobrazuje logy ve webovém rozhraní, musí escapovat tam. Více v článku Bezpečné logování.

PSR-7 popisuje zprávy HTTP jako neměnné objekty a s UploadedFileInterface::moveTo() nabízí jednotný způsob, jak ukládat nahrané soubory. Specifikace vyžaduje, aby byl původní soubor poté odstraněn. Kontrola typu souboru a cílového místa zůstává úkolem aplikace.

Pozoruhodné je, že PSR-9 (Security Advisories) a PSR-10 (Security Reporting Process) byla opuštěna. Společný standard pro bezpečnostní oznámení tak neexistuje; každý projekt si to upravuje sám. Jak s zranitelnostmi nakládá samotný projekt PHP, popisuje stránka Jak projekt PHP řeší bezpečnostní zranitelnosti.

Proti PHP2Shell standardy nepomáhají: zranitelnosti CVE-2026-109618 a CVE-2026-109619 leží v interpretu. Povinná je aktualizace na PHP 8.5.12, 8.4.27, 8.3.36 nebo 8.2.35 a restart všech procesů PHP.

Jak konkrétně pomáhá PHP SOS?

• Zkontrolujeme, jak vaše aplikace loguje, a zajistíme, aby výjimky končily v logu, ale ne přístupové údaje nebo identifikátory relací.
• Posoudíme, jak je implementováno nahrávání a zpracování HTTP, i když probíhá přes knihovny PSR-7.
• Vlastní vývoj prověřujeme v rámci bezpečnostního auditu a penetračního testu.
• Nasazujeme aktualizace PHP, restartujeme všechny workery a dokumentujeme stav.

Časté dotazy

Zdroje

• PHP-FIG: Přehled PSR
• PHP-FIG: Pracovní postup PSR
• PHP-FIG: PER Coding Style
• PHP-FIG: PSR-3 Logger Interface
• PHP-FIG: PSR-7 HTTP Message Interface