A PHP-FIG PSR-szabványai

Röviden: A PSR-ek (PHP Standards Recommendations) a PHP-FIG szabványai, amely bevett PHP-projektek csoportja. Közös szabályokat és interfészeket határoznak meg, például a PSR-4-et az autoloadinghoz, a PSR-3-at a loggerekhez, a PSR-7-et a HTTP-üzenetekhez és a PSR-11-et a konténerekhez. Minden PSR-nek státusza van: elfogadott, tervezet, elavult vagy felhagyott. A PSR-ek cserélhetőbbé és könnyebben ellenőrizhetővé teszik a kódot, de nem zárják be a PHP-értelmezőben lévő réseket, mint a PHP2Shell.

Mi a PHP-FIG, és mik a PSR-ek?

A PHP-FIG a PHP Framework Interop Group rövidítése. A csoport maga úgy írja le a célját, hogy az együttműködéssel és szabványokkal viszi előre a PHP-t. Egy PSR mögött tehát nem gyártó áll, hanem olyan projektek egyeztetése, amelyek szoftverüket egymással kompatibilisen akarják tartani.

A döntéshozók számára a haszon kézzelfogható: ha egy alkalmazás betartja a PSR-interfészeket, például a naplózó programkönyvtár kicserélhető anélkül, hogy az egész kódhoz hozzá kellene nyúlni. Ez csökkenti az egyes csomagoktól és szolgáltatóktól való függőséget.

Egy PSR útja a Pre-Drafttól az Accepted-ig

A PHP-FIG alapszabálya szilárd folyamatot ír le:

1. Pre-Draft: Tisztázzák, van-e elég érdeklődés. Munkacsoport alakul, sikeres szavazás után a javaslat PSR-számot kap.
2. Draft: A javaslatot kidolgozzák, az alternatívák és az indoklások egy meta-dokumentumba kerülnek.
3. Review: A közösség próbamegvalósításokkal teszteli a specifikációt, legalább négy hétig, és amíg két független, életképes megvalósítás nem áll rendelkezésre.
4. Accepted: Sikeres szavazás után a PSR elfogadott; a munkacsoport feloszlik.

Emellett két további állapot létezik. A Deprecated azt jelenti: elfogadott, de már nem ajánlott, többnyire azért, mert egy újabb szabvány felváltja. Az Abandoned azt jelenti: már nem dolgoznak rajta.

Az összes PSR státusszal

A PHP-FIG áttekintése szerinti állapot az oldal keletkezésének időpontjában:

A gyakorlatban legfontosabb PSR-ek

• PSR-4 (autoloading): osztályneveket képez le fájlútvonalakra, és a Composer-autoloader alapja. Részletek a Névterek és autoloading oldalon.
• PSR-1 és PER Coding Style: közös szabályok az írásmódra és a formázásra. A PER Coding Style a PHP-FIG szerint kiterjeszti és felváltja a PSR-12-t, és előfeltételezi a PSR-1-et.
• PSR-3 (logger): egységes logger-interfész a Psr\Log névtérben, nyolc szinttel az emergency-től a debug-ig.
• PSR-7, PSR-15, PSR-17, PSR-18 (HTTP): interfészek a kérésekhez és válaszokhoz, a middleware-hez, a gyárakhoz és a HTTP-kliensekhez. Sok PHP-keretrendszer ezekre épül, vagy hidakat kínál hozzájuk.
• PSR-11 (konténer): közös interfész a dependency injection konténerekhez.
• PSR-6 és PSR-16 (gyorsítótár): két interfész az átmeneti tárakhoz, egy részletes és egy egyszerű.
• PSR-14 és PSR-20 (események, óra): közös interfészek az eseményekhez és az aktuális időhöz. Egy cserélhető óra jól tesztelhetővé teszi az időfüggő kódot, például a tokenek lejáratát.

A számok egyébként nem mondanak semmit a jelentőségről. A tervezeti fázisba lépéskor osztják ki őket, ezért az elavult és felhagyott javaslatok fontos, elfogadott szabványok között állnak.

<?php
use Psr\Log\LoggerInterface;

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

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

Mi köze a PSR-eknek a biztonsághoz?

Több szabvány közvetlenül érinti a biztonságot. A PSR-3 előírja, hogy a kivételeket a kontextusban az exception kulcs alatt kell átadni, és a {datei} típusú helyőrzőket a kontextusból helyettesítik. Az értékeket nem szabad előre maszkolni, mert a logger nem tudja, hol jelennek meg később. Aki a naplókat webes felületen jeleníti meg, ott maszkolni kell. Erről többet a Biztonságos naplózás cikkben talál.

A PSR-7 a HTTP-üzeneteket megváltoztathatatlan objektumokként írja le, és az UploadedFileInterface::moveTo() révén egységes utat kínál a feltöltött fájlok mentéséhez. A specifikáció megköveteli, hogy az eredeti fájl utána el legyen távolítva. A fájltípus és a célhely ellenőrzése az alkalmazás feladata marad.

Figyelemre méltó, hogy a PSR-9 (Security Advisories) és a PSR-10 (Security Reporting Process) felhagyottá vált. A biztonsági közleményekre tehát nincs közös szabvány; minden projekt maga szabályozza. Hogyan kezeli maga a PHP-projekt a réseket, azt a Hogyan kezeli a PHP-projekt a biztonsági réseket oldal írja le.

A PHP2Shell ellen a szabványok nem segítenek: a CVE-2026-109618 és a CVE-2026-109619 rések az értelmezőben vannak. Kötelező a frissítés a PHP 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35 verzióra, és az összes PHP-folyamat újraindítása.

Hogyan segít konkrétan a PHP SOS?

• Megvizsgáljuk, hogyan naplóz az alkalmazása, és gondoskodunk arról, hogy a kivételek a naplóba kerüljenek, de hozzáférési adatok vagy munkamenet-azonosítók ne.
• Értékeljük, hogyan valósul meg a feltöltések és a HTTP-feldolgozás, akkor is, ha PSR-7-programkönyvtárakon keresztül fut.
• Saját fejlesztéseit a biztonsági audit és penetrációs teszt keretében vizsgáljuk meg.
• Telepítjük a PHP-frissítéseket, újraindítjuk az összes workert, és dokumentáljuk az állapotot.

Gyakori kérdések

Források

• PHP-FIG: PSR-áttekintés
• PHP-FIG: PSR-munkafolyamat
• PHP-FIG: PER Coding Style
• PHP-FIG: PSR-3 Logger Interface
• PHP-FIG: PSR-7 HTTP Message Interface