Un errore 403 Forbidden significa che il server ha ricevuto la richiesta, l’ha capita e si è rifiutato di rispondere. A differenza di un 401, accedere non aiuta per forza: il server sta dicendo che questo client, da questo indirizzo, con questi permessi, non può avere questa risorsa. La causa è quasi sempre una regola, non un crash: permessi dei file, un file index mancante, una regola di deny nella configurazione del server, un firewall o una protezione anti-bot, un blocco per IP o per paese, oppure un account senza il ruolo giusto. I gestori del sito trovano la regola nel log degli errori o nel log degli eventi del firewall; i visitatori, per lo più, possono cambiare solo ciò che inviano.
403 vs 401 vs 404
CodiceCosa dice il serverCosa aiuta401 UnauthorizedChi sei? Invia le credenziali.Accedere, oppure una chiave API o un token validi403 ForbiddenSo cosa vuoi, e non puoi averlo.Permessi, indirizzo o richiesta diversi404 Not FoundQui non c’è niente.L’indirizzo giusto
I server non seguono sempre il manuale. Alcuni rispondono 404 invece di 403 per nascondere che una pagina privata esiste, e alcuni rispondono 403 per file mancanti: un bucket di storage privato, per esempio, può rispondere 403 per un oggetto che non esiste quando il client non ha il permesso di elencare il bucket. Il riferimento dei codici di stato HTTP contiene tutti gli altri.
Cause comuni
Permessi di file e cartelle. L’utente del web server non può leggere il file o entrare nella cartella, spesso dopo un upload o un deploy che ha copiato i file come un altro utente.
Nessun file index. Una richiesta per una cartella senza index.html o index.php, su un server con l’elenco delle directory disattivato, risponde 403. Lo stesso succede dopo un deploy fallito che ha lasciato la cartella vuota.
Regole di deny. Un deny all in nginx, un Require all denied in Apache o una regola in .htaccess che blocca un percorso, un tipo di file o uno user agent.
Un firewall o una protezione anti-bot. Un WAF, la protezione anti-bot di una CDN o un plugin di sicurezza decide che la richiesta sembra automatizzata o malevola e la blocca, a volte con una pagina di verifica.
Blocchi per IP e per paese. L’indirizzo, la rete o il paese del visitatore è in una blocklist, oppure la pagina è limitata alla rete aziendale o a una VPN.
Permessi mancanti. Il visitatore ha effettuato l’accesso, ma il suo ruolo non consente la pagina, oppure una chiave API non ha lo scope per l’endpoint.
Link firmati scaduti o errati. I link di download con una firma o una scadenza rispondono 403 quando scadono.
Protezione dall’hotlinking. Immagini o file richiesti da un altro sito, o senza il Referer previsto, vengono rifiutati.
Cosa possono provare i visitatori
Controlla l’indirizzo. Un link che finisce con una cartella invece che con una pagina, o un percorso digitato male, può puntare a una cartella che il server non elenca.
Accedi, o accedi con l’account giusto. Alcuni siti mostrano un 403 ai visitatori che non hanno effettuato l’accesso, o agli account senza autorizzazione.
Cancella i cookie del sito e ricarica. Una vecchia sessione o un cookie di verifica scaduto può far sì che il firewall continui a rifiutarti.
Cambia rete. Disattiva una VPN o un proxy, o attivali, oppure prova con i dati mobili. Gli indirizzi condivisi e quelli dei data center vengono bloccati più spesso delle connessioni domestiche.
Disattiva le estensioni per il sito. Alcune estensioni per la privacy modificano gli header in modi che fanno scattare un firewall.
Avvisa il gestore del sito, indicando l’ora e l’eventuale codice di riferimento mostrato nella pagina di errore. Quel codice gli permette di trovare la regola esatta.
Come i gestori del sito lo trovano e lo risolvono
Per prima cosa capisci chi ha risposto. Guarda la pagina di errore e gli header della risposta: una CDN o un firewall di solito si identifica, con una pagina nel suo stile, un header Server o un ID della richiesta. Se è il tuo web server, il suo log degli errori indica il motivo. Se è la CDN o il WAF, lo indica il suo log degli eventi.
Permessi e file index
Sugli host Linux, di solito le cartelle richiedono 755 e i file 644, di proprietà dell’utente con cui girano il web server o PHP. Controlla prima di modificare qualsiasi cosa, e non risolvere mai un 403 con 777, che permette a ogni utente del server di scrivere sul tuo sito:
ls -la /var/www/example.com/public
find /var/www/example.com/public -type d -exec chmod 755 {} +
find /var/www/example.com/public -type f -exec chmod 644 {} +
nginx registra “directory index of … is forbidden” quando una cartella non ha un file index; Apache registra che non trova un index e che l’elenco delle directory è disattivato. Verifica che il deploy abbia messo i file dove punta la document root del server.
Regole del server
nginx registra “access forbidden by rule” per un deny, e Apache registra “client denied by server configuration” per una regola Require. Cerca la regola corrispondente nella configurazione e in ogni .htaccess lungo il percorso. Su WordPress, salvare le impostazioni dei permalink riscrive la parte core di .htaccess, e i plugin di sicurezza aggiungono i propri blocchi lì e nelle loro impostazioni.
Firewall, CDN e plugin di sicurezza
Trova la richiesta bloccata nel log degli eventi per ora, indirizzo o ID della richiesta, guarda quale regola è scattata e decidi se la regola è sbagliata o se la richiesta era davvero indesiderata. Aggiungi eccezioni per indirizzi o percorsi specifici invece di disattivare una regola per tutto il sito. Dopo una modifica al firewall, fai una prova da una rete esterna al tuo ufficio, perché il tuo indirizzo potrebbe essere in allowlist.
Perché un monitor riceve 403 quando il browser no
Un caso frequente: il sito funziona per te, ma il tuo monitor di uptime segnala 403. Di solito non c’è niente di rotto. Qualcosa davanti al sito tratta il controllo come un bot, perché lo è:
Protezione anti-bot. CDN e WAF sottopongono a verifica i client che non eseguono JavaScript o che sembrano automatizzati. Un browser supera la verifica; un monitor no, quindi riceve un 403 o una pagina di verifica.
Indirizzi dei data center. I monitor controllano dai server, e alcune regole bloccano le reti di hosting per impostazione predefinita.
Blocchi per paese. Un sito che accetta solo il proprio paese blocca un monitor che controlla dall’estero.
Regole di frequenza. Alcuni firewall rispondono 403 invece di 429 quando un client fa troppe richieste.
La soluzione è mettere il monitor in allowlist, preferibilmente tramite i suoi indirizzi IP, perché chiunque può copiare uno user agent. Non risolverlo accettando 403 come “up” per tutto il sito: altrimenti un vero blocco dei tuoi visitatori passa inosservato. Se una pagina deve davvero restare dietro la protezione, monitora un endpoint di health check al di fuori di essa. La guida per ridurre i falsi allarmi tratta altre cause di avvisi che non sono downtime.
Errori 403 e Uptimecheck
Un monitor HTTP(S) nel monitoraggio uptime di Uptimecheck considera up per impostazione predefinita gli stati da 200 a 399, quindi un 403 risulta down. Un secondo controllo lo conferma prima che tu riceva un avviso, e l’incidente spiega chi ha risposto: quando il 403 o una pagina di verifica arriva da Cloudflare, Sucuri, Imperva, Akamai, DataDome, Vercel, Wordfence o AWS WAF, indica quel servizio e cosa consentire lì. I controlli dei siti web partono da Stoccolma, in Svezia, con uno user agent che contiene “Uptimecheck”. Come consentire Uptimecheck attraverso un firewall elenca i nostri indirizzi con regole pronte per Cloudflare, i plugin di sicurezza di WordPress e nginx, e perché un monitor può risultare down quando il sito funziona tratta gli altri motivi.
Vuoi sapere se un sito risponde? Il checker Is it down? gratuito considera up qualsiasi risposta sotto 500, 403 compreso: il server ha risposto, anche se ha rifiutato.
Distingui un controllo bloccato da un vero downtime. Prova Uptimecheck gratis per 14 giorni, senza carta di credito.