Errore 403 Forbidden: cosa significa e come risolverlo

Cosa significa 403 Forbidden

Il codice 403 appartiene alla famiglia delle risposte HTTP 4xx. Non indica necessariamente un sito guasto: una directory privata, una funzione amministrativa o un IP bloccato possono restituire 403 intenzionalmente. Diventa un problema quando il divieto riguarda una risorsa che dovrebbe essere accessibile.

Un 403 non equivale a una richiesta di effettuare nuovamente l'accesso. Il 401 riguarda principalmente l'assenza di credenziali valide; il 403 comunica invece che la richiesta non è autorizzata. Un'applicazione può inoltre restituire 404 per non rivelare l'esistenza di una risorsa riservata.

Per la diagnosi degli errori interni, distinta dalle restrizioni di accesso, consulta la guida all'errore HTTP 500.

Da dove può arrivare un errore 403

Su un sito moderno una richiesta può attraversare CDN o proxy, Nginx, Apache, PHP e applicazione. Ognuno di questi livelli può rifiutarla. La pagina di errore visualizzata dal browser, anche quando riporta il nome di un prodotto, non è sempre sufficiente a identificare con certezza l'origine: occorre confrontarla con i log e con la richiesta effettiva.

Come diagnosticare un errore 403 senza procedere per tentativi

Verificare l'URL e il metodo HTTP

Identifica l'operazione che fallisce: homepage, singola pagina, accesso all'area amministrativa, caricamento di un file oppure richiesta AJAX. Annota l'orario e verifica se il problema si ripete con lo stesso account e dalla stessa rete. Se il 403 si verifica durante il salvataggio di un modulo, la richiesta da esaminare potrebbe essere una POST e non la pagina GET iniziale.

Da terminale, per controllare una normale richiesta GET e il codice restituito, puoi utilizzare:

curl -sS -o /dev/null -w 'HTTP %{http_code}\n' \ https://www.example.com/percorso/

Per esaminare anche gli header:

curl -sS -D - -o /dev/null \ https://www.example.com/percorso/

Questi comandi non replicano automaticamente cookie, sessione, token o corpo di una richiesta effettuata dal browser. Per una POST o una chiamata AJAX usa gli strumenti di sviluppo del browser, nella scheda Rete/Network, e controlla la richiesta che restituisce effettivamente 403. Evita di condividere pubblicamente cookie di sessione, token e header di autorizzazione.

Correlare la richiesta ai log

Verifica i log di accesso e di errore di Apache e Nginx nell'intervallo esatto. Un access log che riporta 403 conferma il codice restituito da quel componente, ma non necessariamente la causa: il relativo error log o un evento del WAF può fornire il dettaglio. In un'architettura con reverse proxy è utile confrontare i diversi livelli, perché il blocco può verificarsi prima che la richiesta raggiunga PHP.

Su un server Linux, se disponi degli accessi necessari, puoi seguire un file di log con tail -f /percorso/del/log. Il percorso dipende dal web server e dal pannello di gestione; non esiste un percorso universale valido per tutti gli hosting. Su un piano condiviso, se i log necessari non sono accessibili, chiedi al supporto di verificare la richiesta indicando URL, orario e IP pubblico d'origine.

Confrontare richieste riuscite e richieste bloccate

Se il problema compare solo da una rete, confronta le evidenze con un accesso autorizzato da un'altra connessione: può emergere una restrizione per IP o una decisione di sicurezza. Se interessa tutti gli utenti ma soltanto una directory, verifica prima indici, permessi e regole relative a quel percorso. La differenza è un indizio diagnostico, non una prova definitiva.

Permessi, proprietà e directory senza file index

Per leggere un file, il processo che gestisce la richiesta deve poter attraversare le directory del percorso e accedere al file secondo la configurazione del sistema. Proprietario, gruppo, ACL ed eventuali controlli di sicurezza del sistema operativo concorrono a determinare l'accesso. I valori 644 per i file e 755 per le directory sono comuni in alcuni ambienti, ma non costituiscono una correzione universale.

Non impostare 777 indiscriminatamente: espone file e directory a scritture non necessarie e può non risolvere il 403. Anche il cambio massivo di proprietario può interrompere il funzionamento di un hosting con utenti e processi separati.

Esempio illustrativo: directory priva di pagina iniziale

Se l'URL /documenti/ corrisponde a una directory senza un file indice riconosciuto, e l'elenco dei file è disabilitato, Apache può rispondere con 403. Un messaggio indicativo è:

AH01276: Cannot serve directory: No matching DirectoryIndex found

Controlla se il documento previsto, per esempio index.html o index.php, esiste nel percorso corretto e se la configurazione lo riconosce. Non abilitare la visualizzazione dell'elenco della directory per aggirare il problema: potrebbe esporre file che devono rimanere riservati. L'esempio è illustrativo e non descrive un incidente verificato su HostingRelax.

Regole Apache, .htaccess e Nginx che negano l'accesso

In Apache 2.4 le direttive di autorizzazione possono consentire o negare l'accesso in base al percorso e ad altre condizioni. Per esempio, Require all denied impedisce l'accesso alle risorse nel contesto in cui è applicata. Anche una regola di riscrittura con flag [F] può produrre una risposta 403. Non tutte le direttive possono essere usate in ogni contesto .htaccess: dipende dalla configurazione del server.

In Nginx, una direttiva deny, una regola return 403 o una particolare configurazione del blocco location possono impedire la richiesta. Se Nginx opera come reverse proxy davanti ad Apache, la presenza del 403 non basta a stabilire quale dei due livelli abbia applicato la restrizione.

Se l'errore è comparso dopo una modifica a .htaccess o alla configurazione del virtual host, confronta la versione precedente e controlla la direttiva coinvolta. Non cancellare tutte le regole né disabilitare globalmente i controlli: alcune possono proteggere file sensibili, aree amministrative o endpoint riservati.

Errore 403 su WordPress

Su WordPress un 403 può comparire durante l'accesso alla bacheca, il salvataggio di un articolo, una chiamata REST API o il caricamento di media. Le cause cambiano in base all'operazione: permessi sul filesystem, regole del web server, plugin di sicurezza, firewall applicativi oppure controlli di autorizzazione eseguiti da WordPress.

Se l'errore compare soltanto durante il salvataggio, apri gli strumenti di sviluppo e individua la richiesta fallita. Una risposta JSON contenente un errore di autorizzazione proveniente dalla REST API non va confusa automaticamente con un blocco di Apache o del WAF. Verifica sessione, ruolo dell'utente, capacità richieste dall'endpoint ed eventuali token di sicurezza, senza rimuovere controlli legittimi.

Se invece l'errore è iniziato subito dopo l'installazione di un plugin di protezione, consulta gli eventi registrati dal plugin prima di modificarne le regole. Per approfondire aggiornamenti, protezioni e gestione delle intrusioni, consulta la guida alla sicurezza WordPress.

Errore 403 su PrestaShop

In PrestaShop il negozio pubblico può funzionare mentre una specifica operazione del back office restituisce 403. Può accadere, per esempio, quando la richiesta non supera un controllo di autorizzazione, quando un token non è più valido o quando un sistema di sicurezza blocca il contenuto inviato da un modulo. Queste sono possibilità da verificare, non diagnosi automatiche.

Individua la chiamata precisa nella scheda Rete del browser e verifica codice HTTP, URL, metodo e risposta. Se la richiesta non raggiunge l'applicazione, controlla i log del web server e del WAF; se viene gestita dal back office, esamina autorizzazioni, sessione e log applicativi. Su un negozio in produzione evita modifiche indiscriminate a moduli, permessi o protezioni: prima salva la configurazione e riproduci il problema in modo controllato quando possibile.

Quando il 403 è generato da un sistema di sicurezza

Un Web Application Firewall (WAF), una CDN con funzioni di sicurezza o un componente di blocco collegato a un sistema come CrowdSec possono rifiutare richieste considerate rischiose. Il blocco può essere corretto, per esempio contro un tentativo di accesso abusivo, oppure un falso positivo su un'operazione legittima.

Per distinguere le due situazioni servono almeno orario, IP d'origine, URL, metodo HTTP e, se disponibile, identificativo della regola o dell'evento di sicurezza. Quando un sito è dietro una CDN o un reverse proxy bisogna anche verificare come viene ricostruito l'IP originale: un indirizzo interpretato in modo errato può rendere fuorviante l'indagine.

Esempio illustrativo: salvataggio bloccato dal WAF

Un redattore riesce ad aprire l'editor ma riceve 403 al salvataggio. Prima di attribuire il problema al CMS, si verifica la richiesta POST fallita e la si confronta con gli eventi di sicurezza dello stesso istante. Se l'evento indica una regola specifica e la richiesta è legittima, il rimedio è una correzione mirata della regola o un'eccezione limitata al caso verificato, non la disattivazione dell'intero WAF.

Anche questo esempio è illustrativo: non rappresenta un caso cliente HostingRelax documentato.

Come risolvere il 403 senza ridurre la sicurezza

La correzione dipende dalla causa dimostrata. Se manca il file indice, pubblica il documento previsto o correggi il percorso. Se il processo web non può leggere un file necessario, ripristina proprietà e permessi coerenti con il modello di esecuzione. Se una regola Apache o Nginx blocca una risorsa che deve essere pubblica, intervieni su quella regola preservando le altre restrizioni.

Per un controllo applicativo verifica invece che l'utente abbia il ruolo e le autorizzazioni richieste; per un falso positivo WAF identifica l'evento e limita l'eccezione al minimo necessario. Dopo ogni modifica ripeti esattamente l'operazione che falliva e controlla che le risorse che devono rimanere protette non siano diventate accessibili.

Se il blocco è intenzionale, il comportamento corretto può essere lasciare il 403 invariato. L'obiettivo non è eliminare ogni risposta Forbidden, ma risolvere quelle non previste.

Quando rivolgersi al supporto hosting

Se non puoi consultare i log o il 403 sembra provenire da un servizio di sicurezza gestito dal provider, il supporto può verificare componenti non disponibili nel tuo pannello. Fornisci l'URL precisa, data e ora con fuso orario, IP pubblico da cui si verifica il problema, tipo di operazione, eventuali modifiche recenti e un riferimento alla richiesta fallita.

Se devi allegare una cattura della scheda Rete, rimuovi prima cookie, credenziali, token e informazioni personali. Non inviare password per consentire una verifica: è preferibile concordare un accesso di supporto con autorizzazioni limitate, quando necessario.

Conclusioni

Un errore HTTP 403 segnala un accesso rifiutato, ma non ne identifica la causa. La diagnosi più efficace parte dalla richiesta fallita, ne individua il punto di blocco e verifica i log corrispondenti. Una correzione mirata consente di ripristinare l'accesso legittimo senza compromettere le protezioni del sito.

Approfondimenti

• Errore HTTP 500: cause, diagnosi e soluzioni
• Sicurezza WordPress: aggiornamenti, backup e bonifica
• Trasferire un sito WordPress senza downtime