Permessi dei file di WordPress consigliati: 755, 644 e wp-config.php

Questo articolo è un'edizione localizzata dell'originale giapponese. Leggi l'originale in giapponese

Per i permessi dei file di WordPress la regola di base è 755 per le cartelle e 644 per i file. Per wp-config.php, che contiene i dati di connessione al database, conviene restringere ulteriormente chi può leggerlo. Oltre ai numeri, controlla anche chi è il proprietario dei file e con quale utente gira PHP: così eviti sia la fuga di informazioni sia il problema dell'«impossibile aggiornare». I valori consigliati in questo articolo derivano dalla guida ufficiale di WordPress «Hardening WordPress» (Rendere WordPress più sicuro), consultata a novembre 2026.

Come leggere i numeri dei permessi

I permessi sono espressi per tre insiemi, «proprietario, gruppo, altri», come somma di lettura (4), scrittura (2) ed esecuzione (1).

L'«esecuzione (x)» su una cartella è il permesso di entrarci. Se togli la x da una cartella, i file al suo interno non si possono più leggere.

I valori consigliati per WordPress

Non serve impostare 777 (scrittura per tutti). Su un server condiviso gli altri utenti dello stesso server potrebbero riscrivere i tuoi file.

Alcuni hosting con server condiviso stabiliscono valori consigliati propri (perché il modo di far girare PHP cambia da server a server). Se nel manuale del tuo hosting sono indicati dei valori, dai la precedenza a quelli.

Il criterio per il proprietario dei file

Secondo la guida ufficiale, i file devono appartenere al tuo account utente e devono essere scrivibili da te. Solo i file in cui WordPress deve scrivere (uploads, i temi se usi l'editor dei temi e così via) vanno resi scrivibili dall'utente con cui gira il server web (PHP), allineando proprietario o gruppo.

Se assegni tutto all'utente del server web, per esempio con chown -R www-data:www-data, PHP può riscrivere qualsiasi file. Se viene sfruttata una vulnerabilità di un plugin il danno si estende più facilmente, quindi controlla prima la situazione attuale e poi decidi.

Se durante l'aggiornamento di plugin o core vengono richieste le «informazioni di connessione (host, nome utente e password FTP)», nella maggior parte dei casi la causa è proprio questo disallineamento dei proprietari. WordPress sceglie di riscrivere direttamente i file solo quando il proprietario dei file creati da PHP coincide con quello dei file di WordPress. Se sono diversi, chiede di aggiornare via FTP. Non allargare i permessi a 777: allinea i proprietari.

Controlla le impostazioni attuali

Entra nella cartella di WordPress via SSH e controlla valori e proprietario con i comandi seguenti. Adatta il percorso al tuo ambiente.

cd /var/www/html

# Valore, proprietario e gruppo di wp-config.php
stat -c '%a %U:%G %n' wp-config.php

# Cerca file e cartelle in cui possono scrivere gli altri utenti
find . -perm -o=w ! -type l

# Cerca file PHP dentro uploads (di norma non ce ne sono)
find wp-content/uploads -type f -name '*.php'

L'utente con cui gira PHP quando si accede dal web va verificato nella configurazione del server (per esempio user nel pool di PHP-FPM) oppure nel manuale dell'hosting. Non è detto che coincida con l'utente con cui fai login via SSH.

Se in uploads c'è un file PHP che non riconosci, sospetta una manomissione e, prima di eliminarlo, registra data e contenuto del file.

Correggi i permessi in blocco

Eseguilo nella cartella di WordPress. Prima di eseguirlo, fai un backup.

cd /var/www/html

# Porta le cartelle a 755 e i file a 644
find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +

# Restringi wp-config.php (esempio per un ambiente in cui PHP gira con il proprietario del file)
chmod 600 wp-config.php

Il valore di wp-config.php si sceglie in base all'ambiente, così.

• PHP gira con lo stesso utente proprietario del file (molti hosting condivisi, PHP-FPM per utente): 600 o 400
• Il proprietario è il tuo account e il server web legge come gruppo: 640 o 440, con il gruppo impostato su quello del server web

# Esempio: proprietario tu, gruppo del server web (www-data) e permessi 640
sudo chgrp www-data wp-config.php
chmod 640 wp-config.php

Dopo la configurazione apri il sito e l'amministrazione e verifica che la visualizzazione e il login funzionino. Se compare una schermata bianca o un errore, PHP non riesce a leggere wp-config.php. Riporta il valore a 644 e rivedi proprietario e gruppo.

Con 400 o 440 falliscono i plugin che scrivono in wp-config.php (per esempio quelli che scrivono le impostazioni della cache). Consenti la scrittura temporaneamente solo quando configuri quei plugin.

Impedisci che wp-config.php venga letto dal web

Se PHP funziona normalmente, accedendo a wp-config.php dal browser il contenuto non viene mostrato. Per evitare che il sorgente venga visualizzato se PHP si ferma, nega l'accesso anche dal server web. Con Apache 2.4 scrivi quanto segue nel .htaccess della cartella in cui hai installato WordPress (i vecchi Order Deny,Allow / Deny from all sono la sintassi di Apache 2.2).

<Files "wp-config.php">
    Require all denied
</Files>

La procedura dettagliata è nella guida «Come negare l'accesso a wp-config.php».

Per .htaccess in sé, l'accesso è già negato dalla configurazione standard di Apache (<Files ".ht*"> in httpd.conf).

Secondo la guida ufficiale, si può anche spostare wp-config.php nella cartella superiore a quella di installazione di WordPress. Se non trova wp-config.php nella stessa cartella, WordPress lo cerca in quella superiore. Anche la guida ufficiale però menziona pareri secondo cui l'effetto è modesto e il rischio che, se fatto male, diventi controproducente. Se lo sposti, verifica che la cartella superiore non sia pubblica.

Non far eseguire PHP in uploads

uploads è una cartella in cui scrive WordPress ed è quindi un posto dove gli attacchi riescono facilmente a piazzare file. Se impedisci l'esecuzione di PHP qui, anche un file piazzato non gira.

Con Apache 2.4 crea wp-content/uploads/.htaccess e scrivi quanto segue.

<FilesMatch "\.(php|phtml|phar)$">
    Require all denied
</FilesMatch>

Per usare Require in .htaccess, il server deve averlo consentito con AllowOverride. Se non è consentito, si ottiene un errore 500 oppure l'impostazione viene ignorata. Dopo averlo scritto, apri l'URL di un PHP inesistente come https://example.com/wp-content/uploads/test.php e verifica che risponda 403 (se resta 404 l'impostazione non è efficace).

Con Nginx, nel blocco server mettilo prima di location ~ \.php$, quella che elabora PHP. Le location con espressioni regolari vengono confrontate dall'alto in basso e viene usata la prima che corrisponde.

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ {
    deny all;
}

Dopo aver cambiato la configurazione, controlla la sintassi con nginx -t e poi ricaricala.

Va detto inoltre che il caricamento dei file multimediali di WordPress non accetta di default file diversi dai tipi consentiti (immagini, PDF e così via). Dalla schermata di amministrazione, di norma, non si può caricare un file PHP come file multimediale.

Avvertenze

• Prima di cambiare i permessi, fai un backup di file e database.
• Se cambi i permessi con un programma FTP, alcuni server non supportano la modifica in blocco. Quando i file sono molti è più rapido, e si evitano dimenticanze, usare find via SSH.
• Se durante un aggiornamento vengono richieste le informazioni di connessione FTP, non allargare i permessi: controlla il proprietario. Può esserti utile anche «Come risolvere gli errori di permessi di WordPress».
• Eseguendo periodicamente i comandi di controllo qui sopra (file scrivibili da altri utenti, PHP dentro uploads) ti accorgi prima di impostazioni che si sono rovinate o di manomissioni.

Domande su WordPress? Chi pubblica questo sito ha sede in Giappone e risponde in giapponese. Contatti (in giapponese)