403 Forbidden: permessi, proprietario del file e regole del server web

La verifica più rapida

Prima di tutto: il 403 non dipende quasi mai dal file che stavi guardando tu, ma da come è configurata la cartella. Primo test, trenta secondi: prova a caricare un altro file nella stessa directory (anche un file vuoto chiamato test.html). Se anche quello dà 403, il problema è nella cartella o nella configurazione del server, non nel singolo file. Secondo test: apri il log degli errori del server, non fidarti solo della pagina bianca nel browser. Su Ubuntu con Nginx il file è /var/log/nginx/error.log (lo stesso percorso vale per le installazioni da pacchetto su RHEL e CentOS), come indicato dalla documentazione ufficiale di Nginx. Il comando per guardarlo in tempo reale è:

sudo tail -f /var/log/nginx/error.log

La riga che conta è quella con l'indirizzo IP del tuo test e la parola "Permission denied" oppure "access forbidden by rule": la prima punta a un problema di permessi/proprietario, la seconda a una regola di configurazione.

Cosa significa l'errore

Il server ha capito la richiesta, ha trovato (o dovrebbe trovare) il file, ma ha deciso di non consegnarlo. Non è un problema di rete, non è il sito "giù": è una porta chiusa a chiave, e la chiave sbagliata può essere in tre punti diversi.

Causa 1: permessi del file (la più frequente)

È la causa più comune dopo un upload via FTP, un ripristino da backup o una migrazione. Il processo del server web (Nginx, Apache) gira con un utente di sistema — tipicamente www-data su Ubuntu — e quell'utente deve poter leggere il file e attraversare tutte le cartelle del percorso.

Come si capisce se è la tua: dalla shell, nella directory del sito:

ls -la

Se le cartelle non mostrano rwxr-xr-x (755) o i file non mostrano rw-r--r-- (644), è questa la causa. Attenzione anche alle cartelle padre: basta una sola cartella nel percorso senza il bit di esecuzione (x) per bloccare tutto quello che sta sotto, anche se il file finale ha i permessi giusti.

Come si risolve, su Ubuntu, dalla cartella radice del sito (sostituire /var/www/sitotuo con il percorso reale):

sudo find /var/www/sitotuo -type d -exec chmod 755 {} \;
sudo find /var/www/sitotuo -type f -exec chmod 644 {} \;

Il comando find separato per cartelle (-type d) e file (-type f) serve proprio a non applicare lo stesso valore a tutto: una cartella con 644 non è attraversabile, un file con 755 è eseguibile quando non dovrebbe esserlo. Su Plesk la procedura ufficiale, descritta nella pagina di supporto sul Repair Kit, è identica nella sostanza: find /var/www/vhosts/example.com/httpdocs/* -type d -exec chmod 0755 {} ; per le cartelle e il corrispondente -type f -exec chmod 0644 per i file, con il percorso che su Plesk è sempre sotto /var/www/vhosts/.

Perché mai 777. Con 777 chiunque abbia un accesso al sistema — anche un altro sito sullo stesso server condiviso, se non è isolato bene — può scrivere e modificare i tuoi file. È la causa più comune di siti WordPress compromessi silenziosamente: non risolve il 403 meglio di 755, lo risolve allo stesso modo ma lascia la porta aperta a tutti.

Come si verifica che è risolto: ricarica la pagina. Se usi la cache del browser, apri in incognito. Da shell, ls -la deve mostrare 755 sulle cartelle e 644 sui file coinvolti.

Causa 2: proprietario del file (owner) sbagliato

I permessi dicono cosa si può fare, il proprietario dice chi può farlo. Un file può avere 644 e dare comunque 403 se appartiene a un utente diverso da quello che il server web si aspetta, perché PHP-FPM o il modulo del server web leggono i file come un utente specifico e le cartelle intermedie negano l'accesso agli "altri".

Come si capisce se è la tua: confronta l'utente nell'output di ls -la con l'utente del pool PHP-FPM del sito. Su un setup Ubuntu con PHP-FPM, l'utente del pool è indicato nella direttiva user = del file di pool in /etc/php/8.3/fpm/pool.d/. Se il file appartiene a root o a un altro account e il pool gira come utente del sito, è un conflitto di proprietario tipico dopo un ripristino da backup fatto da root o un rsync lanciato con sudo senza preservare l'utente.

Come si risolve, su Ubuntu (sostituire utente:gruppo con l'utente reale del sito, es. www-data:www-data o l'utente dedicato del pool):

sudo chown -R utente:gruppo /var/www/sitotuo

Come si verifica: ls -la deve mostrare l'utente corretto su cartelle e file, e il sito deve rispondere senza 403.

Causa 3: regole di configurazione del server

Qui i permessi e il proprietario sono già giusti, ma è il server stesso a dire di no: una direttiva deny all; in un blocco location di Nginx, una regola Require all denied in un file .htaccess su Apache, un'autenticazione HTTP Basic richiesta e non fornita, o un limite esplicito sulla cartella (tipico su /wp-admin, /xmlrpc.php o le cartelle di upload per bloccare l'esecuzione di script).

Come si capisce se è la tua: il file ha permessi e proprietario corretti, eppure il 403 resta. Cerca nella configurazione del sito:

grep -r "deny" /etc/nginx/sites-available/

oppure, per Apache/.htaccess, apri il file .htaccess nella cartella interessata e cerca righe Deny from all o Require all denied. Nel log di Nginx la riga caratteristica, come segnalato dalla documentazione ufficiale, riporta la severità e il messaggio dell'evento registrato dalla direttiva error_log.

Come si risolve: commenta o rimuovi la regola se non serve più, oppure correggila per limitarla all'IP o al percorso giusto. Dopo ogni modifica alla configurazione di Nginx:

sudo nginx -t && sudo systemctl reload nginx

Il comando nginx -t controlla la sintassi prima di ricaricare: se c'è un errore, il server continua a girare con la configurazione precedente invece di cadere.

Il caso cPanel

Su cPanel la logica è la stessa — 755 per le cartelle, 644 per i file — ma il proprietario deve sempre essere l'utente dell'account cPanel del sito, mai root né un utente generico tipo nobody: è la causa più comune di 403 dopo un ripristino manuale da backup o un trasferimento fatto da un altro hosting. Il filesystem sotto cPanel è lo stesso Linux, quindi gli stessi comandi find ... -exec chmod funzionano identici; la differenza è che va passato il percorso corretto dell'account, in genere sotto /home/utentecpanel/public_html/. Per correggere il proprietario in un colpo solo:

chown -R utentecpanel:utentecpanel /home/utentecpanel/public_html

Il caso Plesk

Su Plesk il percorso dei siti è sotto /var/www/vhosts/nomedominio/httpdocs/ e lo strumento ufficiale per intercettare questi problemi è plesk repair fs, che segnala file o directory scrivibili da chiunque o non leggibili/scrivibili dal proprietario, permessi insicuri che possono indicare una violazione di sicurezza. Per vedere nel dettaglio quali file sono fuori norma prima di correggere, si lancia prima in modalità di sola verifica:

plesk repair fs -v -n

e poi si applicano gli stessi comandi find con chmod 0755 per le cartelle e chmod 0644 per i file, sostituendo il nome del dominio nel percorso, come indicato nella pagina ufficiale di supporto Plesk.

Quando non è colpa tua: il caso del fornitore

Se il sito era online, non hai toccato file né permessi, e il 403 compare all'improvviso su tutto il dominio (non su una sola pagina), può essere un problema lato infrastruttura: un aggiornamento automatico del pannello che ha sovrascritto una regola di configurazione, un ripristino di backup fatto dal provider con l'utente sbagliato, o una modifica a una WAF/CDN davanti al server. In questo caso, apri un ticket all'assistenza allegando: l'URL esatto che dà 403, l'orario preciso in cui è comparso, e se possibile l'output di ls -la sulla cartella del sito presa da un accesso SSH o da File Manager del pannello. Senza questi tre elementi il supporto deve rifare da zero la diagnosi che hai già fatto tu in due minuti.

Riepilogo valori corretti

Elemento	Valore corretto	Comando di verifica
Cartelle	755 (rwxr-xr-x)	ls -ld nomecartella
File	644 (rw-r--r--)	ls -l nomefile
Proprietario	utente del pool PHP-FPM o dell'account hosting	ls -la (terza colonna)
Mai	777 su cartelle o file	—