Les normes PSR du PHP-FIG

En bref : les PSR (PHP Standards Recommendations) sont des normes du PHP-FIG, un groupe de projets PHP établis. Elles fixent des règles et des interfaces communes, par exemple PSR-4 pour l'autoloading, PSR-3 pour les loggers, PSR-7 pour les messages HTTP et PSR-11 pour les conteneurs. Chaque PSR a un statut : acceptée, brouillon, obsolète ou abandonnée. Les PSR rendent le code plus interchangeable et plus facile à contrôler, mais ne comblent aucune faille de l'interpréteur PHP comme PHP2Shell.

Qu'est-ce que le PHP-FIG et que sont les PSR ?

PHP-FIG signifie PHP Framework Interop Group. Le groupe décrit lui-même son objectif comme celui de faire progresser PHP par la collaboration et par des normes. Derrière une PSR, il n'y a donc pas un éditeur, mais un accord entre des projets qui veulent garder leurs logiciels compatibles entre eux.

Pour les décideurs, l'intérêt est concret : si une application respecte les interfaces PSR, on peut par exemple remplacer la bibliothèque de journalisation sans toucher à tout le code. Cela réduit la dépendance à l'égard de paquets et de prestataires particuliers.

Le parcours d'une PSR : du pre-draft à accepted

Les statuts du PHP-FIG décrivent un déroulement fixe :

1. Pre-Draft : on vérifie si l'intérêt est suffisant. Un groupe de travail se forme ; après un vote favorable, la proposition reçoit un numéro de PSR.
2. Draft : la proposition est élaborée, les alternatives et les justifications sont consignées dans un méta-document.
3. Review : la communauté teste la spécification avec des implémentations d'essai, pendant au moins quatre semaines et jusqu'à ce que deux implémentations indépendantes et viables existent.
4. Accepted : après un vote favorable, la PSR est adoptée ; le groupe de travail est dissous.

Il existe en outre deux autres états. Deprecated signifie : adoptée, mais plus recommandée, le plus souvent parce qu'une norme plus récente la remplace. Abandoned signifie : on n'y travaille plus.

Toutes les PSR et leur statut

État selon la vue d'ensemble du PHP-FIG au moment de cette page :

Les PSR les plus importantes en pratique

• PSR-4 (autoloading) : associe les noms de classes à des chemins de fichiers et constitue la base de l'autoloader de Composer. Détails sur la page Espaces de noms et autoloading.
• PSR-1 et PER Coding Style : règles communes d'écriture et de mise en forme. Selon le PHP-FIG, PER Coding Style étend et remplace PSR-12 et présuppose PSR-1.
• PSR-3 (logger) : interface de logger unifiée dans l'espace de noms Psr\Log, avec huit niveaux, de emergency à debug.
• PSR-7, PSR-15, PSR-17, PSR-18 (HTTP) : interfaces pour les requêtes et réponses, les middlewares, les fabriques et les clients HTTP. De nombreux frameworks PHP s'appuient dessus ou proposent des passerelles.
• PSR-11 (conteneur) : interface commune pour les conteneurs d'injection de dépendances.
• PSR-6 et PSR-16 (cache) : deux interfaces pour les caches, l'une détaillée et l'une simple.
• PSR-14 et PSR-20 (événements, horloge) : interfaces communes pour les événements et pour l'heure actuelle. Une horloge interchangeable rend testable le code dépendant du temps, par exemple l'expiration de jetons.

Les numéros ne disent d'ailleurs rien de l'importance. Ils sont attribués à l'entrée en phase de brouillon, c'est pourquoi des propositions obsolètes et abandonnées figurent entre des normes importantes et acceptées.

<?php
use Psr\Log\LoggerInterface;

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

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

Ce que les PSR ont à voir avec la sécurité

Plusieurs normes touchent directement à la sécurité. PSR-3 prévoit que les exceptions soient transmises dans le contexte sous la clé exception et que des espaces réservés comme {datei} soient remplacés à partir du contexte. Les valeurs ne doivent pas être échappées au préalable, car le logger ne sait pas où elles seront affichées ensuite. Qui affiche des logs dans une interface web doit les échapper à cet endroit. Plus de détails dans l'article Journaliser en toute sécurité.

PSR-7 décrit les messages HTTP comme des objets immuables et offre avec UploadedFileInterface::moveTo() une voie uniforme pour enregistrer les fichiers téléversés. La spécification exige que le fichier d'origine soit supprimé ensuite. Le contrôle du type de fichier et de l'emplacement de destination reste du ressort de l'application.

Il est remarquable que PSR-9 (Security Advisories) et PSR-10 (Security Reporting Process) aient été abandonnées. Il n'existe donc pas de norme commune pour les alertes de sécurité ; chaque projet règle cela lui-même. La façon dont le projet PHP traite lui-même les failles est décrite sur la page Comment le projet PHP traite les failles de sécurité.

Contre PHP2Shell, les normes n'aident pas : les failles CVE-2026-109618 et CVE-2026-109619 se trouvent dans l'interpréteur. La mise à jour vers PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 et le redémarrage de tous les processus PHP sont obligatoires.

Comment PHP SOS aide-t-il concrètement ?

• Nous vérifions comment votre application journalise et veillons à ce que les exceptions aboutissent dans le log, mais pas les identifiants ni les identifiants de session.
• Nous évaluons la mise en œuvre du traitement des uploads et du HTTP, même lorsqu'ils passent par des bibliothèques PSR-7.
• Nous examinons les développements maison dans le cadre d'un audit de sécurité et test d'intrusion.
• Nous installons les mises à jour de PHP, redémarrons tous les workers et documentons l'état obtenu.

Questions fréquentes

Sources

• PHP-FIG : vue d'ensemble des PSR
• PHP-FIG : workflow des PSR
• PHP-FIG : PER Coding Style
• PHP-FIG : PSR-3 Logger Interface
• PHP-FIG : PSR-7 HTTP Message Interface