PSR-standaarden van de PHP-FIG

Kort gezegd: PSR's (PHP Standards Recommendations) zijn standaarden van de PHP-FIG, een groep gevestigde PHP-projecten. Ze leggen gemeenschappelijke regels en interfaces vast, zoals PSR-4 voor autoloading, PSR-3 voor loggers, PSR-7 voor HTTP-berichten en PSR-11 voor containers. Elke PSR heeft een status: geaccepteerd, ontwerp, verouderd of opgegeven. PSR's maken code uitwisselbaarder en gemakkelijker te controleren, maar dichten geen lekken in de PHP-interpreter zoals PHP2Shell.

Wat is de PHP-FIG en wat zijn PSR's?

PHP-FIG staat voor PHP Framework Interop Group. De groep omschrijft haar doel zelf als het verder brengen van PHP door samenwerking en standaarden. Achter een PSR staat dus geen fabrikant, maar een afstemming tussen projecten die hun software onderling compatibel willen houden.

Voor beslissers is het nut tastbaar: houdt een toepassing zich aan PSR-interfaces, dan kan bijvoorbeeld de logbibliotheek worden vervangen zonder de hele code aan te raken. Dat verlaagt de afhankelijkheid van afzonderlijke pakketten en dienstverleners.

De weg van een PSR: van pre-draft tot accepted

De statuten van de PHP-FIG beschrijven een vast verloop:

1. Pre-draft: Er wordt vastgesteld of er genoeg belangstelling is. Een werkgroep vormt zich, na een geslaagde stemming krijgt het voorstel een PSR-nummer.
2. Draft: Het voorstel wordt uitgewerkt, alternatieven en motiveringen komen in een metadocument.
3. Review: De gemeenschap test de specificatie met proefimplementaties, minimaal vier weken lang en totdat er twee onafhankelijke, werkbare implementaties zijn.
4. Accepted: Na een geslaagde stemming is de PSR aangenomen; de werkgroep wordt ontbonden.

Daarnaast zijn er twee andere toestanden. Deprecated betekent: aangenomen, maar niet meer aanbevolen, meestal omdat een nieuwere standaard hem vervangt. Abandoned betekent: er wordt niet meer aan gewerkt.

Alle PSR's met status

Stand volgens het overzicht van de PHP-FIG op het moment van deze pagina:

De belangrijkste PSR's voor de praktijk

• PSR-4 (autoloading): beeldt klassenamen af op bestandspaden en is de basis van de Composer-autoloader. Details op de pagina Namespaces en autoloading.
• PSR-1 en PER Coding Style: gemeenschappelijke regels voor schrijfwijze en opmaak. PER Coding Style breidt PSR-12 volgens de PHP-FIG uit en vervangt hem, en veronderstelt PSR-1.
• PSR-3 (logger): uniforme logger-interface in de namespace Psr\Log met acht niveaus van emergency tot debug.
• PSR-7, PSR-15, PSR-17, PSR-18 (HTTP): interfaces voor verzoeken en antwoorden, middleware, factories en HTTP-clients. Veel PHP-frameworks bouwen hierop voort of bieden bruggen aan.
• PSR-11 (container): gemeenschappelijke interface voor dependency-injection-containers.
• PSR-6 en PSR-16 (cache): twee interfaces voor tussengeheugens, een uitgebreide en een eenvoudige.
• PSR-14 en PSR-20 (events, klok): gemeenschappelijke interfaces voor gebeurtenissen en voor de actuele tijd. Een uitwisselbare klok maakt tijdsafhankelijke code, bijvoorbeeld het verlopen van tokens, goed testbaar.

De nummers zeggen overigens niets over het belang. Ze worden toegekend bij het ingaan van de ontwerpfase, daarom staan verouderde en opgegeven voorstellen tussen belangrijke, geaccepteerde standaarden.

<?php
use Psr\Log\LoggerInterface;

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

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

Wat PSR's met beveiliging te maken hebben

Meerdere standaarden raken de beveiliging rechtstreeks. PSR-3 bepaalt dat exceptions onder de sleutel exception in de context worden doorgegeven en dat plaatshouders zoals {datei} uit de context worden vervangen. Waarden mogen daarbij niet vooraf worden geëscaped, omdat de logger niet weet waar ze later worden weergegeven. Wie logs in een webinterface toont, moet daar escapen. Meer daarover in het artikel Veilig loggen.

PSR-7 beschrijft HTTP-berichten als onveranderlijke objecten en biedt met UploadedFileInterface::moveTo() een uniforme manier om geüploade bestanden op te slaan. De specificatie eist dat het oorspronkelijke bestand daarna is verwijderd. De controle van bestandstype en bestemming blijft een taak van de toepassing.

Opmerkelijk is dat PSR-9 (Security Advisories) en PSR-10 (Security Reporting Process) zijn opgegeven. Een gemeenschappelijke standaard voor beveiligingsmeldingen bestaat dus niet; elk project regelt dat zelf. Hoe het PHP-project zelf met lekken omgaat, beschrijft de pagina Hoe het PHP-project beveiligingslekken behandelt.

Tegen PHP2Shell helpen standaarden niet: de lekken CVE-2026-109618 en CVE-2026-109619 zitten in de interpreter. Verplicht is de update naar PHP 8.5.12, 8.4.27, 8.3.36 of 8.2.35 en de herstart van alle PHP-processen.

Hoe helpt PHP SOS concreet?

• Wij controleren hoe uw toepassing logt en zorgen ervoor dat exceptions in het log terechtkomen, maar geen toegangsgegevens of sessie-ID's.
• Wij beoordelen hoe upload- en HTTP-verwerking zijn uitgevoerd, ook als ze via PSR-7-bibliotheken lopen.
• Wij onderzoeken eigen ontwikkelingen in het kader van een beveiligingsaudit en penetratietest.
• Wij voeren PHP-updates door, starten alle workers opnieuw en documenteren de status.

Veelgestelde vragen

Bronnen

• PHP-FIG: PSR-overzicht
• PHP-FIG: PSR-workflow
• PHP-FIG: PER Coding Style
• PHP-FIG: PSR-3 Logger Interface
• PHP-FIG: PSR-7 HTTP Message Interface