Permessi file WordPress: valori sicuri e controlli

Questa guida approfondisce permessi file WordPress con controlli progressivi, modifiche reversibili e verifiche finali. Non inviare password, cookie, token, chiavi private o codici 2FA nei ticket.

Che cosa significa

Come riferimento comune si usano spesso 644 per i file e 755 per le directory, ma il proprietario e il modello PHP del server sono altrettanto importanti.

Un file con 777 non risolve un proprietario errato e concede scrittura a soggetti non necessari. Su hosting condiviso non bisogna eseguire chown casuali come root.

Come riconoscere il problema

• WordPress non aggiorna plugin.
• uploads non è scrivibile.
• Il file editor non salva.
• Dopo migrazione i file appartengono a root.
• Il sito restituisce 403 o 500 dopo chmod.

Cause più frequenti

1. Permessi troppo restrittivi

PHP non può creare o modificare i file necessari. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

2. Permessi eccessivi

File e directory sono scrivibili da utenti non previsti. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

3. Proprietario errato

Una copia eseguita come root altera ownership. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

4. Regole ricorsive sbagliate

Lo stesso chmod viene applicato a file e directory. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

5. wp-config.php esposto

Il file contiene credenziali e richiede protezione maggiore. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

6. Plugin di sicurezza o immutable

La scrittura può essere bloccata anche con chmod corretto. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.

Diagnosi passo per passo

1. Identifica il percorso. Limita il controllo alla installazione interessata. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
2. Controlla file e directory separatamente. Usa find in sola lettura per individuare anomalie. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
3. Verifica proprietario e gruppo. Confronta con file creati normalmente dall’account. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
4. Controlla error_log. Cerca permission denied e operation not permitted. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
5. Verifica spazio e inode. Un errore di scrittura può avere cause diverse. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
6. Controlla wp-content/uploads. Testa una nuova immagine senza modifiche massive. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
7. Confronta dopo migrazione. Individua file copiati con ownership differente. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.

Metodo sicuro di diagnosi

Prima di applicare modifiche, registra lo stato iniziale: URL o servizio coinvolto, messaggio completo, data e ora, rete o client, ultima operazione eseguita e risultato da un secondo strumento. Questo consente di distinguere una causa locale da una configurazione condivisa e rende possibile il rollback.

Cambia un solo elemento alla volta. Dopo ogni intervento ripeti esattamente lo stesso test, controlla i log dello stesso intervallo temporale e annota il risultato. Modificare contemporaneamente DNS, cache, PHP, plugin e firewall rende impossibile stabilire quale correzione abbia avuto effetto.

Controllo incrociato

Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin e WP-CLI; per DNS interroga nameserver autoritativo e resolver pubblico; per la posta confronta header, Webmail e Track Delivery. Cache e proxy possono mostrare stati differenti per alcuni minuti.

Quando il problema sembra risolto, ripeti il test con una seconda rete o un secondo account e verifica che le protezioni restino attive. Una soluzione che disabilita globalmente TLS, WAF, autenticazione o controlli di sicurezza non è considerata definitiva.

Procedura di risoluzione

1. Ripristina permessi coerenti. Applica valori distinti a file e directory. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
2. Correggi il proprietario tramite procedura supportata. Su server condiviso coinvolgi l’assistenza. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
3. Proteggi wp-config.php. Mantieni il file leggibile solo dai processi necessari. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
4. Evita scrittura globale. Non usare 777 come soluzione. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
5. Correggi soltanto il percorso interessato. Non modificare l’intera home senza motivo. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
6. Verifica aggiornamenti e upload. Controlla che WordPress possa operare senza eccessi. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
7. Conserva un report. Annota file anomali e modifica applicata. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.

Verifica della stabilità dopo l’intervento

Non fermarti al primo test riuscito. Ripeti l’operazione dopo aver aperto una nuova sessione, svuotato soltanto la cache pertinente e atteso l’eventuale scadenza del TTL o del rate limit. Controlla inoltre che una seconda pagina, un secondo utente o un secondo destinatario non presentino ancora il problema.

Conserva per almeno il tempo necessario il backup e la configurazione precedente. Se l’anomalia ricompare, confronta orario, log e processo pianificato: una ricorrenza regolare può dipendere da cron, rinnovi, rotazioni, cache rigenerate o servizi esterni.

Controlli finali

• File e directory hanno valori coerenti.
• WordPress aggiorna e carica media.
• wp-config.php è protetto.
• Nessun file appartiene a root senza motivo.
• Il sito non mostra nuovi errori.

Prevenzione

• Usa strumenti dell’account.
• Mantieni backup.
• Evita copie come root.
• Controlla dopo migrazioni.
• Limita la scrittura.

Errori da evitare

• Non usare chmod -R 777.
• Non applicare 644 alle directory.
• Non cambiare proprietario di file di sistema.
• Non rendere pubblico wp-config.php.
• Non correggere senza backup.

Quando contattare l’assistenza Xlogic

Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi o richiede log e configurazioni non disponibili nel pannello. Indica:

• percorso
• utente proprietario
• permessi anomali
• errore e orario
• operazione fallita

Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.

Fonti tecniche ufficiali

• WordPress file permissions
• WordPress hardening

Verifica prolungata dopo la correzione

Una singola prova riuscita non dimostra che il problema sia definitivamente risolto. Ripeti l’operazione dopo una nuova sessione, da una seconda rete o con un secondo utente quando applicabile. Per DNS e posta considera anche TTL, code e cache dei resolver; per HTTP e WordPress controlla una pagina dinamica, una funzione amministrativa e il relativo registro degli errori.

Conserva temporaneamente il backup, i valori precedenti e gli estratti dei log. Se l’anomalia ricompare, confronta l’orario con cron, backup, aggiornamenti, rinnovi SSL, rotazioni DNS, code email e servizi esterni. Una ricorrenza regolare è spesso più significativa del messaggio mostrato durante il singolo evento.

Prima di chiudere l’intervento verifica inoltre che le misure di sicurezza siano ancora operative: HTTPS valido, autenticazione richiesta, WAF attivo, permessi non eccessivi e nessun endpoint di debug o manutenzione lasciato pubblico. La soluzione deve correggere la causa senza ridurre stabilmente le protezioni del servizio.

Domande frequenti su permessi file WordPress