# Gli standard PSR di PHP-FIG

> Gli standard PSR di PHP-FIG: tutti i PSR da 0 a 22 con lo stato, i più importanti nella pratica e che cosa significano PSR-3, PSR-4 e PSR-7 per la sicurezza.

Fonte: https://phpsos.de/it/php/psr-standards/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

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

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

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

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

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](https://phpsos.de/it/leistungen/sicherheitsaudit-penetrationstest/).
- Installiamo gli aggiornamenti di PHP, riavviamo tutti i worker e documentiamo lo stato.


## Domande frequenti

**Che cosa significa PSR?**  
PSR sta per PHP Standards Recommendation. Le raccomandazioni sono elaborate e votate da PHP-FIG, la PHP Framework Interop Group. Sono volontarie, ma vengono adottate da molti framework e librerie.

**PSR-12 vale ancora?**  
PSR-12 è tuttora indicato da PHP-FIG come accettato. PHP-FIG ha però pubblicato con PER Coding Style un successore che, secondo quanto dichiarato, estende e sostituisce PSR-12. Attualmente lì è alla versione 3.1.

**Esiste un PSR per le segnalazioni di sicurezza?**  
C'erano due proposte, PSR-9 per i Security Advisories e PSR-10 per il processo di segnalazione delle vulnerabilità. Entrambe sono indicate da PHP-FIG come abbandonate. I progetti regolano quindi da soli il proprio processo di segnalazione.

**Il mio progetto deve rispettare i PSR?**  
No, non c'è alcun obbligo. PSR-4 per l'autoloading e le interfacce come PSR-3 o PSR-7 facilitano però in modo evidente l'uso di pacchetti esterni e il cambio di fornitori di servizi.

## Fonti

- [PHP-FIG: panoramica dei PSR](https://www.php-fig.org/psr/)
- [PHP-FIG: flusso di lavoro dei PSR](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/)