In breve: per i permessi dei file sul server web vale un principio: l'utente con cui gira PHP può leggere il proprio codice, ma non modificarlo. Il permesso di scrittura spetta solo alle cartelle di upload, cache e temporanee, e lì non si esegue PHP. Permessi come 777 non hanno posto su un server di produzione.
Perché i permessi dei file fanno la differenza dopo un'intrusione
Quando gli aggressori eseguono codice su un server tramite una vulnerabilità, quel codice gira con i permessi del processo PHP. Ciò che può fare questo utente, può farlo anche l'aggressore. Proprio qui si decide se un'intrusione diventa una backdoor permanente.
Con PHP2Shell questo scenario è diventato molto concreto a ottobre 2026. Le vulnerabilità CVE-2026-109618 e CVE-2026-109619 consentono l'esecuzione di codice dannoso senza autenticazione. Sono corrette dal 21/10/2026 in PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Buoni permessi dei file non impediscono un attacco, ma impediscono che il codice introdotto di nascosto riscriva in modo permanente la Sua applicazione.
In molte installazioni tutto il codice appartiene all'utente del server web, affinché gli aggiornamenti funzionino con un clic. È comodo, ma è proprio la configurazione che gli aggressori cercano.
Il principio di base: separare proprietario e utente di esecuzione
È sensata una suddivisione in due ruoli. Un proprietario, ad esempio un utente di deploy, possiede i file e installa gli aggiornamenti. Il processo PHP gira con un altro utente ed è autorizzato solo in lettura tramite il gruppo.
| Area | Proprietario : gruppo | Permessi file | Permessi cartelle |
|---|---|---|---|
| Codice del programma | deploy : seite1 | 640 | 750 |
| Configurazione con password | deploy : seite1 | 640 | – |
| Upload, cache, temp | seite1 : seite1 | 640 | 750 |
| Log | root o seite1 | 640 | 750 |
Il server web stesso, ad esempio Nginx, con PHP-FPM ha bisogno solo dell'accesso in lettura ai file statici come immagini e CSS. Lo ottiene tramite il gruppo o una regola di accesso mirata. Chi gestisce più siti assegna a ciascuno un proprio utente di esecuzione; come ciò si combina con i pool è spiegato nella guida open_basedir e isolamento per sito.
Verificare i permessi dei file sul server web
Prima di cambiare qualcosa, si faccia un quadro della situazione. I comandi seguenti non modificano nulla.
# Con quale utente girano i processi PHP?
ps -eo user,cmd | grep -E "[p]hp-fpm|[a]pache2|[h]ttpd" | sort | uniq -c
# File e cartelle scrivibili da tutti
find /var/www -perm -o+w -ls
# File che appartengono all'utente del server web (esempio www-data)
find /var/www -user www-data -type f -name "*.php" | head -50
# Permessi dei file di configurazione
ls -la /var/www/*/wp-config.php /var/www/*/.env 2>/dev/null
Le voci scrivibili da tutti sono quasi sempre un errore. I file PHP che appartengono all'utente di esecuzione mostrano che questo può modificare il proprio codice. Sono sospetti anche i singoli file il cui proprietario o i cui permessi differiscono da quelli dei file vicini. Può essere un indizio di file introdotti di nascosto, come descritto nella guida Riconoscere e rimuovere le webshell.
Correggere i permessi: passo dopo passo
Modifichi i permessi solo dopo un backup e, se possibile, prima in un ambiente di test. Se c'è il sospetto di un'intrusione, metta prima al sicuro le tracce, perché proprietario e timestamp sono allora elementi di prova.
SITE=/var/www/seite1
# Proprietario: utente di deploy, gruppo: utente di esecuzione
sudo chown -R deploy:seite1 "$SITE"
# Cartelle 750, file 640
sudo find "$SITE" -type d -exec chmod 750 {} +
sudo find "$SITE" -type f -exec chmod 640 {} +
# Solo in queste cartelle PHP può scrivere (adattare i percorsi all'applicazione)
sudo chown -R seite1:seite1 "$SITE/public/uploads" "$SITE/var/cache"
Verifichi poi il sito completamente: home page, login, moduli, upload di immagini, cache. Quali cartelle un'applicazione debba poter scrivere è indicato nei requisiti di sistema del produttore sulla sua pagina ufficiale.
Un chmod -R 777 per risolvere rapidamente un problema apre il server a ogni utente locale e a ogni processo introdotto di nascosto. Corregga invece proprietario e gruppo.
Impedire l'esecuzione di PHP nelle cartelle scrivibili
I permessi di scrittura sono pericolosi solo a metà se lì non può girare alcun codice. Blocchi l'esecuzione di PHP nelle cartelle di upload e di cache a livello di server web. Per Apache nella configurazione del VirtualHost:
<Directory "/var/www/seite1/public/uploads">
<FilesMatch "\.(php|phtml|phar)$">
Require all denied
</FilesMatch>
</Directory>
Per Nginx basta un blocco location che rifiuta le richieste a file PHP in queste cartelle. La regola va nella configurazione del server, non in un .htaccess nella cartella di upload, che un aggressore con permessi di scrittura potrebbe modificare di nuovo.
In aggiunta vale la pena dare un'occhiata all'umask dell'utente di deploy, in modo che i nuovi file non vengano creati automaticamente con permessi troppo aperti. Un valore di 027 porta a 640 per i file e 750 per le cartelle. Sui server propri questa responsabilità è interamente Sua; che cos'altro ne faccia parte è descritto in Mettere in sicurezza da soli root server e vServer.
Casi particolari: pannelli di hosting, shared hosting e deployment
Non ogni server si lascia configurare come da manuale. I pannelli di hosting come Plesk o cPanel creano utenti e permessi propri e in alcune azioni li ripristinano. Modifichi lì i permessi possibilmente tramite le funzioni del pannello oppure verifichi dopo gli aggiornamenti del pannello se le Sue impostazioni valgano ancora.
Con lo shared hosting di solito si ha un solo utente per tutto. Una separazione tra proprietario e utente di esecuzione non è allora possibile. Tanto più importanti sono permessi ridotti sui file di configurazione, niente permessi 777 e la disattivazione dell'esecuzione di PHP nelle cartelle di upload, nei limiti in cui l'hoster lo consente.
Chi lavora con deployment automatici dovrebbe impostare i permessi nello script di deployment stesso. Altrimenti ogni nuova versione ripristina il vecchio stato troppo aperto. Un breve controllo alla fine del deployment, ad esempio con il comando per i file scrivibili visto sopra, intercetta in modo affidabile simili passi indietro e si inserisce senza grande sforzo in ogni pipeline.
Come aiuta concretamente PHP SOS?
- Rileviamo proprietario, permessi e utente di esecuzione di tutti i siti sul server.
- Definiamo un concetto di permessi adatto alla Sua applicazione e al Suo modo di aggiornare.
- Applichiamo permessi e blocchi di esecuzione e poi testiamo il sito completamente.
- Documentiamo il concetto, in modo che deployment e aggiornamenti non lo allentino di nuovo.
Come si inserisce in una messa in sicurezza duratura è descritto nel servizio Hardening del server per server web PHP.
Domande frequenti
I permessi 777 vanno mai bene?
Su un server di produzione praticamente mai. Con 777 ogni utente del sistema può creare e modificare file. Se un'applicazione non funziona senza 777, di solito il proprietario è impostato male, non i permessi troppo scarsi.
Perché il server web non dovrebbe poter modificare i propri file?
Perché il codice introdotto di nascosto gira con i permessi del server web. Se il server web può scrivere file PHP, un aggressore può manipolare script esistenti o creare nuove backdoor. Separando proprietario e utente di esecuzione, il codice resta protetto in scrittura.
Come aggiorno un CMS se il server web non può scrivere?
Gli aggiornamenti passano allora dal proprietario, ad esempio con WP-CLI, Composer o un deployment, non dal pulsante di aggiornamento nel backend. È un po' più laborioso, ma il codice introdotto di nascosto non può modificare i file del programma.
Quali permessi serve al file di configurazione con la password del database?
Il minimo possibile: leggibile per l'utente PHP, per nessun altro. Di solito si usa 640 con il gruppo adatto, oppure 400 se l'utente PHP è lui stesso il proprietario.