# Standardy PSR od PHP-FIG

> Standardy PSR od PHP-FIG: všechna PSR od 0 do 22 se stavem, nejdůležitější pro praxi a co znamenají PSR-3, PSR-4 a PSR-7 pro bezpečnost.

Zdroj: https://phpsos.de/cs/php/psr-standards/  
Stav: 25.10.2026  
Poskytovatel: PHP SOS, Nouzová pomoc pro PHP a bezpečnost serverů. Okamžitá pomoc přes WhatsApp: https://wa.me/491736494914?text=Dobr%C3%BD%20den%2C%20PHP%20SOS%2C%20pot%C5%99ebujeme%20pomoc%20s%20na%C5%A1%C3%ADm%20PHP%20serverem.%20Firma%3A%20%E2%80%A6%20Web%3A%20%E2%80%A6

**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:

| Č. | Název | Stav |
|---|---|---|
| PSR-0 | Autoloading Standard | zastaralé |
| PSR-1 | Basic Coding Standard | přijaté |
| PSR-2 | Coding Style Guide | zastaralé |
| PSR-3 | Logger Interface | přijaté |
| PSR-4 | Autoloading Standard | přijaté |
| PSR-5 | PHPDoc Standard | návrh |
| PSR-6 | Caching Interface | přijaté |
| PSR-7 | HTTP Message Interface | přijaté |
| PSR-8 | Huggable Interface | opuštěné |
| PSR-9 | Security Advisories | opuštěné |
| PSR-10 | Security Reporting Process | opuštěné |
| PSR-11 | Container Interface | přijaté |
| PSR-12 | Extended Coding Style Guide | přijaté |
| PSR-13 | Hypermedia Links | přijaté |
| PSR-14 | Event Dispatcher | přijaté |
| PSR-15 | HTTP Handlers | přijaté |
| PSR-16 | Simple Cache | přijaté |
| PSR-17 | HTTP Factories | přijaté |
| PSR-18 | HTTP Client | přijaté |
| PSR-19 | PHPDoc tags | návrh |
| PSR-20 | Clock | přijaté |
| PSR-21 | Internationalization | návrh |
| PSR-22 | Application Tracing | návrh |

## 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](https://phpsos.de/cs/php/namespaces-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](https://phpsos.de/cs/php/php-frameworks/) 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
<?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í](https://phpsos.de/cs/blog/sicher-loggen-php/).

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](https://phpsos.de/cs/php/php-sicherheitsprozess/).

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](https://phpsos.de/cs/leistungen/sicherheitsaudit-penetrationstest/).
- Nasazujeme aktualizace PHP, restartujeme všechny workery a dokumentujeme stav.


## Časté dotazy

**Co znamená PSR?**  
PSR znamená PHP Standards Recommendation. Doporučení vypracovává a odsouhlasuje PHP-FIG, tedy PHP Framework Interop Group. Jsou dobrovolná, ale mnoho frameworků a knihoven je dodržuje.

**Platí PSR-12 ještě?**  
PSR-12 je u PHP-FIG nadále vedeno jako přijaté. PHP-FIG ale vydala s PER Coding Style nástupce, který podle vlastního vyjádření PSR-12 rozšiřuje a nahrazuje. Aktuální je tam verze 3.1.

**Existuje PSR pro bezpečnostní oznámení?**  
Byly dva návrhy, PSR-9 pro Security Advisories a PSR-10 pro proces hlášení bezpečnostních zranitelností. Oba jsou u PHP-FIG vedeny jako opuštěné. Projekty si proto proces hlášení upravují samy.

**Musí můj projekt dodržovat PSR?**  
Ne, žádná povinnost neexistuje. PSR-4 pro autoloading a rozhraní jako PSR-3 nebo PSR-7 ale výrazně usnadňují nasazení cizích balíčků a výměnu dodavatelů.

## Zdroje

- [PHP-FIG: Přehled PSR](https://www.php-fig.org/psr/)
- [PHP-FIG: Pracovní postup 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/)
