# Analisi statica: PHPStan e Psalm > PHPStan e Psalm spiegati: livelli di regole, baseline, taint analysis e che cosa l'analisi statica può e non può fare per applicazioni PHP sicure. Fonte: https://phpsos.de/it/php/statische-analyse/ 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:** l'analisi statica verifica il codice PHP senza eseguirlo e trova così errori di tipo, variabili non definite, codice morto e chiamate su valori eventualmente vuoti. I due strumenti più diffusi sono PHPStan (livelli di regole da 0 a 10) e Psalm (livelli di errore da 1 a 8, con in più una taint analysis per i flussi di dati non sicuri). Trovano errori nella Sua applicazione, non nell'interprete PHP; contro vulnerabilità come PHP2Shell aiuta solo l'aggiornamento di PHP. ## Che cos'è l'analisi statica? Un test esegue il codice e ne confronta il risultato. L'analisi statica, invece, legge il codice come un revisore molto scrupoloso e deduce da tipi, valori di ritorno e chiamate dove qualcosa può andare storto. Trova errori anche in rami che nessun test raggiunge mai. Per chi decide l'utilità è semplice: gli errori trovati prima della messa online costano una frazione di quelli che i clienti notano. Per gli sviluppatori è un compagno costante, che gira nell'ambiente di sviluppo e nella pipeline CI. Se l'analisi dà l'allarme per una modifica, questa non viene accettata finché l'errore non è corretto. Così non si accumula nuovo retaggio, mentre quello esistente viene smaltito gradualmente. Insieme ai [test con PHPUnit e Pest](https://phpsos.de/it/php/php-testen/) costituisce il fondamento della qualità del codice. ## PHPStan: livelli di regole da 0 a 10 PHPStan si installa come dipendenza di sviluppo e per funzionare richiede PHP dalla 7.4: ```bash composer require --dev phpstan/phpstan vendor/bin/phpstan analyse src tests ``` Senza altre indicazioni PHPStan controlla solo lo stretto necessario. Il rigore lo regola attraverso undici livelli, ciascuno dei quali include quelli sottostanti: | Livello | Che cosa viene controllato in più (selezione) | |---|---| | 0 | classi e funzioni sconosciute, numero errato di argomenti, variabili sempre non definite | | 3 | tipi di ritorno e tipi assegnati alle proprietà | | 5 | tipi degli argomenti nelle chiamate di funzioni e metodi | | 6 | indicazioni di tipo mancanti | | 8 | chiamate di metodi e accessi a proprietà su valori che possono essere null | | 10 | gestione più rigorosa di `mixed`, anche con tipi mancanti | Con `--level max` gira sempre il livello più alto. La documentazione avverte però che un aggiornamento di PHPStan può allora portare molte nuove segnalazioni. Un tipico riscontro dal livello 8: ```php name(); // PHPStan: chiamata su un valore che può essere null } ``` ## Introdurre PHPStan senza ondata di errori: la baseline Nei progetti cresciuti nel tempo, a un livello alto PHPStan segnala spesso centinaia di punti. La baseline risolve il problema: salva in un file tutte le segnalazioni esistenti, e da lì in poi PHPStan segnala solo i nuovi errori. ```bash vendor/bin/phpstan analyse --level 6 src tests --generate-baseline ``` Il file generato `phpstan-baseline.neon` lo includa nella configurazione: ```neon includes: - phpstan-baseline.neon parameters: level: 6 paths: - src - tests ``` Così il retaggio rimane documentato in modo visibile, mentre il nuovo codice deve essere pulito fin dall'inizio. ## Psalm e la taint analysis Psalm persegue obiettivi simili a PHPStan. I livelli vanno al contrario: 1 è il più rigoroso, 8 il più indulgente, il predefinito è 2. Psalm richiede PHP dalla 8.2 e si configura così: ```bash composer require --dev vimeo/psalm ./vendor/bin/psalm --init ./vendor/bin/psalm --taint-analysis ``` La taint analysis è particolarmente interessante per la sicurezza. «Taint» significa contaminazione: Psalm contrassegna i dati provenienti da fonti che un aggressore può controllare, come `$_GET`, `$_POST`, `$_COOKIE`, `$_REQUEST` o `php://input`. Poi verifica se questi dati arrivano senza protezione in punti pericolosi, i cosiddetti sink: output con `echo`, `include`, `header` o query SQL. Tra le categorie integrate figurano, tra le altre, `sql`, `html`, `shell`, `include`, `eval`, `ssrf` e `unserialize`. ```php