Gli standard PSR di PHP-FIG

In breve: i PSR (PHP Standards Recommendation) sono standard di PHP-FIG, un gruppo di progetti PHP affermati. Stabiliscono regole e interfacce comuni, ad esempio PSR-4 per l'autoloading, PSR-3 per i logger, PSR-7 per i messaggi HTTP e PSR-11 per i container. Ogni PSR ha uno stato: accettato, bozza, deprecato o abbandonato. I PSR rendono il codice più intercambiabile e più facile da verificare, ma non chiudono vulnerabilità nell'interprete PHP come PHP2Shell.

Che cos'è PHP-FIG e che cosa sono i PSR?

PHP-FIG sta per PHP Framework Interop Group. Il gruppo descrive il proprio obiettivo come far progredire PHP attraverso la collaborazione e gli standard. Dietro un PSR non c'è dunque un produttore, ma un accordo tra progetti che vogliono mantenere compatibile il proprio software.

Per chi decide il vantaggio è concreto: se un'applicazione rispetta le interfacce PSR, si può ad esempio sostituire la libreria di logging senza toccare l'intero codice. Ciò riduce la dipendenza da singoli pacchetti e fornitori di servizi.

Il percorso di un PSR: da Pre-Draft ad Accepted

Lo statuto di PHP-FIG descrive un iter fisso:

1. Pre-Draft: si chiarisce se c'è interesse sufficiente. Si forma un gruppo di lavoro e, dopo una votazione positiva, la proposta riceve un numero PSR.
2. Draft: la proposta viene elaborata, alternative e motivazioni confluiscono in un meta-documento.
3. Review: la comunità testa la specifica con implementazioni di prova, per almeno quattro settimane e finché non esistono due implementazioni indipendenti e valide.
4. Accepted: dopo una votazione positiva il PSR è approvato; il gruppo di lavoro si scioglie.

Esistono inoltre altri due stati. Deprecated significa: approvato, ma non più raccomandato, di solito perché lo sostituisce uno standard più recente. Abandoned significa: non ci si lavora più.

Tutti i PSR con lo stato

Stato secondo la panoramica di PHP-FIG al momento di questa pagina:

I PSR più importanti nella pratica

• PSR-4 (autoloading): associa i nomi delle classi ai percorsi dei file ed è la base dell'autoloader di Composer. Dettagli nella pagina Namespace e autoloading.
• PSR-1 e PER Coding Style: regole comuni per la grafia e la formattazione. Secondo PHP-FIG, PER Coding Style estende e sostituisce PSR-12 e presuppone PSR-1.
• PSR-3 (logger): interfaccia di logger uniforme nel namespace Psr\Log con otto livelli da emergency a debug.
• PSR-7, PSR-15, PSR-17, PSR-18 (HTTP): interfacce per richieste e risposte, middleware, factory e client HTTP. Molti framework PHP si basano su di esse o offrono dei ponti.
• PSR-11 (container): interfaccia comune per i container di dependency injection.
• PSR-6 e PSR-16 (cache): due interfacce per le memorie intermedie, una completa e una semplice.
• PSR-14 e PSR-20 (eventi, orologio): interfacce comuni per gli eventi e per l'ora corrente. Un orologio sostituibile rende ben testabile il codice dipendente dal tempo, ad esempio la scadenza dei token.

I numeri, a proposito, non dicono nulla sull'importanza. Vengono assegnati all'ingresso nella fase di bozza, per questo proposte deprecate e abbandonate stanno tra standard importanti e accettati.

<?php
use Psr\Log\LoggerInterface;

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

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

Che cosa c'entrano i PSR con la sicurezza

Diversi standard toccano direttamente la sicurezza. PSR-3 stabilisce che le eccezioni vengano passate nel contesto con la chiave exception e che segnaposto come {datei} vengano sostituiti con valori del contesto. I valori non devono essere neutralizzati in anticipo, perché il logger non sa dove verranno mostrati in seguito. Chi visualizza i log in un'interfaccia web deve neutralizzarli in quel punto. Altro nell'articolo Registrare i log in modo sicuro.

PSR-7 descrive i messaggi HTTP come oggetti immutabili e con UploadedFileInterface::moveTo() offre un modo uniforme per salvare i file caricati. La specifica richiede che il file originale venga poi rimosso. La verifica del tipo di file e della destinazione resta compito dell'applicazione.

Degno di nota è che PSR-9 (Security Advisories) e PSR-10 (Security Reporting Process) siano stati abbandonati. Non esiste quindi uno standard comune per le segnalazioni di sicurezza; ogni progetto lo regola da sé. Come il progetto PHP stesso gestisce le vulnerabilità lo descrive la pagina Come il progetto PHP tratta le vulnerabilità di sicurezza.

Contro PHP2Shell gli standard non aiutano: le vulnerabilità CVE-2026-109618 e CVE-2026-109619 si trovano nell'interprete. È obbligatorio l'aggiornamento a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35 e il riavvio di tutti i processi PHP.

Come aiuta concretamente PHP SOS?

• Verifichiamo come la Sua applicazione registra i log e ci assicuriamo che le eccezioni finiscano nel log, ma non credenziali o identificativi di sessione.
• Valutiamo come sono implementati l'elaborazione degli upload e quella HTTP, anche quando passano attraverso librerie PSR-7.
• Esaminiamo gli sviluppi interni nell'ambito di un audit di sicurezza e penetration test.
• Installiamo gli aggiornamenti di PHP, riavviamo tutti i worker e documentiamo lo stato.

Domande frequenti

Fonti

• PHP-FIG: panoramica dei PSR
• PHP-FIG: flusso di lavoro dei PSR
• PHP-FIG: PER Coding Style
• PHP-FIG: PSR-3 Logger Interface
• PHP-FIG: PSR-7 HTTP Message Interface