PSR-standarder från PHP-FIG

Kort sagt: PSR (PHP Standards Recommendations) är standarder från PHP-FIG, en grupp etablerade PHP-projekt. De fastställer gemensamma regler och gränssnitt, till exempel PSR-4 för autoloading, PSR-3 för loggare, PSR-7 för HTTP-meddelanden och PSR-11 för containrar. Varje PSR har en status: accepterad, utkast, föråldrad eller övergiven. PSR gör kod mer utbytbar och lättare att granska, men stänger inga luckor i PHP-tolken som PHP2Shell.

Vad är PHP-FIG och vad är PSR?

PHP-FIG står för PHP Framework Interop Group. Gruppen beskriver själv sitt mål som att föra PHP framåt genom samarbete och standarder. Bakom en PSR står alltså ingen tillverkare, utan en överenskommelse mellan projekt som vill hålla sin programvara kompatibel med varandra.

För beslutsfattare är nyttan konkret: Håller sig en applikation till PSR-gränssnitt går det att byta ut till exempel loggbiblioteket utan att röra hela koden. Det minskar beroendet av enskilda paket och leverantörer.

En PSR:s väg: från Pre-Draft till Accepted

PHP-FIG:s stadgar beskriver ett fast förlopp:

1. Pre-Draft: Man klarlägger om intresset räcker. En arbetsgrupp bildas, och efter lyckad omröstning får förslaget ett PSR-nummer.
2. Draft: Förslaget utarbetas, alternativ och motiveringar förs in i ett metadokument.
3. Review: Gemenskapen testar specifikationen med provimplementeringar, i minst fyra veckor och tills två oberoende, hållbara implementeringar finns.
4. Accepted: Efter lyckad omröstning är PSR:n antagen; arbetsgruppen upplöses.

Vid sidan av det finns två ytterligare tillstånd. Deprecated betyder: antagen men inte längre rekommenderad, oftast för att en nyare standard ersätter den. Abandoned betyder: Man arbetar inte längre med den.

Alla PSR med status

Läget enligt PHP-FIG:s översikt vid tidpunkten för den här sidan:

De viktigaste PSR i praktiken

• PSR-4 (autoloading): kopplar klassnamn till filsökvägar och är grunden för Composers autoloader. Detaljer på sidan Namnrymder och autoloading.
• PSR-1 och PER Coding Style: gemensamma regler för stavning och formatering. PER Coding Style utökar och ersätter enligt PHP-FIG PSR-12 och förutsätter PSR-1.
• PSR-3 (loggare): enhetligt loggargränssnitt i namnrymden Psr\Log med åtta nivåer från emergency till debug.
• PSR-7, PSR-15, PSR-17, PSR-18 (HTTP): gränssnitt för förfrågningar och svar, middleware, fabriker och HTTP-klienter. Många PHP-ramverk bygger på dem eller erbjuder bryggor.
• PSR-11 (container): gemensamt gränssnitt för dependency-injection-containrar.
• PSR-6 och PSR-16 (cache): två gränssnitt för mellanlagring, ett utförligt och ett enkelt.
• PSR-14 och PSR-20 (händelser, klocka): gemensamma gränssnitt för händelser och för aktuell tid. En utbytbar klocka gör tidsberoende kod, till exempel att token löper ut, lätt att testa.

Numren säger för övrigt ingenting om betydelsen. De delas ut när ett förslag går in i utkastfasen, därför står föråldrade och övergivna förslag mellan viktiga, accepterade standarder.

<?php
use Psr\Log\LoggerInterface;

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

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

Vad PSR har med säkerhet att göra

Flera standarder berör säkerheten direkt. PSR-3 fastställer att exceptions överlämnas under nyckeln exception i kontexten och att platshållare som {datei} ersätts från kontexten. Värden ska då inte maskeras i förväg, eftersom loggaren inte vet var de visas senare. Den som visar loggar i ett webbgränssnitt måste maskera där. Mer om det i inlägget Logga säkert.

PSR-7 beskriver HTTP-meddelanden som oföränderliga objekt och erbjuder med UploadedFileInterface::moveTo() ett enhetligt sätt att spara uppladdade filer. Specifikationen kräver att originalfilen därefter är borttagen. Kontrollen av filtyp och målplats förblir applikationens uppgift.

Anmärkningsvärt är att PSR-9 (Security Advisories) och PSR-10 (Security Reporting Process) har övergivits. Någon gemensam standard för säkerhetsmeddelanden finns alltså inte; varje projekt reglerar det själv. Hur PHP-projektet självt hanterar luckor beskriver sidan Så hanterar PHP-projektet säkerhetsluckor.

Mot PHP2Shell hjälper standarder inte: Sårbarheterna CVE-2026-109618 och CVE-2026-109619 ligger i tolken. Det som krävs är uppdateringen till PHP 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 och omstart av alla PHP-processer.

Hur hjälper PHP SOS konkret?

• Vi kontrollerar hur er applikation loggar och ser till att exceptions hamnar i loggen men inga inloggningsuppgifter eller sessions-id:n.
• Vi bedömer hur uppladdnings- och HTTP-hanteringen är genomförd, även när den går via PSR-7-bibliotek.
• Vi undersöker egenutvecklad kod inom ramen för en säkerhetsgranskning och penetrationstest.
• Vi installerar PHP-uppdateringar, startar om alla workers och dokumenterar läget.

Vanliga frågor

Källor

• PHP-FIG: PSR-översikt
• PHP-FIG: PSR-arbetsflöde
• PHP-FIG: PER Coding Style
• PHP-FIG: PSR-3 Logger Interface
• PHP-FIG: PSR-7 HTTP Message Interface