# PSR-standaarden van de PHP-FIG

> PSR-standaarden van de PHP-FIG: alle PSR's van 0 tot 22 met status, de belangrijkste voor de praktijk en wat PSR-3, PSR-4 en PSR-7 voor de beveiliging betekenen.

Bron: https://phpsos.de/nl/php/psr-standards/  
Stand: 25-10-2026  
Aanbieder: PHP SOS, PHP-noodhulp en serverbeveiliging. Directe hulp via WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wij%20hebben%20hulp%20nodig%20met%20onze%20PHP-server.%20Bedrijf%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**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:

| Nr. | Titel | Status |
|---|---|---|
| PSR-0 | Autoloading Standard | verouderd |
| PSR-1 | Basic Coding Standard | geaccepteerd |
| PSR-2 | Coding Style Guide | verouderd |
| PSR-3 | Logger Interface | geaccepteerd |
| PSR-4 | Autoloading Standard | geaccepteerd |
| PSR-5 | PHPDoc Standard | ontwerp |
| PSR-6 | Caching Interface | geaccepteerd |
| PSR-7 | HTTP Message Interface | geaccepteerd |
| PSR-8 | Huggable Interface | opgegeven |
| PSR-9 | Security Advisories | opgegeven |
| PSR-10 | Security Reporting Process | opgegeven |
| PSR-11 | Container Interface | geaccepteerd |
| PSR-12 | Extended Coding Style Guide | geaccepteerd |
| PSR-13 | Hypermedia Links | geaccepteerd |
| PSR-14 | Event Dispatcher | geaccepteerd |
| PSR-15 | HTTP Handlers | geaccepteerd |
| PSR-16 | Simple Cache | geaccepteerd |
| PSR-17 | HTTP Factories | geaccepteerd |
| PSR-18 | HTTP Client | geaccepteerd |
| PSR-19 | PHPDoc tags | ontwerp |
| PSR-20 | Clock | geaccepteerd |
| PSR-21 | Internationalization | ontwerp |
| PSR-22 | Application Tracing | ontwerp |

## 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](https://phpsos.de/nl/php/namespaces-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](https://phpsos.de/nl/php/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
<?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](https://phpsos.de/nl/blog/sicher-loggen-php/).

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](https://phpsos.de/nl/php/php-sicherheitsprozess/).

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](https://phpsos.de/nl/leistungen/sicherheitsaudit-penetrationstest/).
- Wij voeren PHP-updates door, starten alle workers opnieuw en documenteren de status.


## Veelgestelde vragen

**Wat betekent PSR?**  
PSR staat voor PHP Standards Recommendation. De aanbevelingen worden door de PHP-FIG, de PHP Framework Interop Group, opgesteld en afgestemd. Ze zijn vrijwillig, maar worden door veel frameworks en bibliotheken toegepast.

**Geldt PSR-12 nog?**  
PSR-12 staat bij de PHP-FIG nog steeds als geaccepteerd vermeld. De PHP-FIG heeft met PER Coding Style echter een opvolger gepubliceerd die PSR-12 volgens eigen zeggen uitbreidt en vervangt. Actueel is daar versie 3.1.

**Is er een PSR voor beveiligingsmeldingen?**  
Er waren twee voorstellen: PSR-9 voor security advisories en PSR-10 voor het proces voor het melden van beveiligingslekken. Beide staan bij de PHP-FIG als opgegeven vermeld. Projecten regelen hun meldproces daarom zelf.

**Moet mijn project zich aan PSR's houden?**  
Nee, er is geen verplichting. PSR-4 voor autoloading en de interfaces zoals PSR-3 of PSR-7 maken het gebruik van externe pakketten en het wisselen van dienstverleners echter aanzienlijk eenvoudiger.

## Bronnen

- [PHP-FIG: PSR-overzicht](https://www.php-fig.org/psr/)
- [PHP-FIG: PSR-workflow](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/)