L’errore 403 Forbidden significa che il server ha ricevuto la richiesta ma rifiuta l’accesso alla risorsa. Il sito o il file esiste, tuttavia una regola, un permesso o un controllo di sicurezza impedisce di servirlo.
Questa guida approfondisce errore 403 Forbidden con una procedura progressiva e reversibile. Non inviare password, codici 2FA, token, chiavi private o file di configurazione completi nei ticket.
Che cosa significa
Il 403 può essere prodotto dal web server, da ModSecurity, da Imunify360, da Cloudflare, da un plugin o da una regola nel file .htaccess.
Prima di modificare i permessi bisogna capire se il blocco riguarda tutti, un solo IP, una cartella, un file o una specifica azione.
Come riconoscere il problema
- Una pagina o cartella restituisce 403.
- Il sito funziona da un’altra rete.
- Il salvataggio di un contenuto viene bloccato.
- Dopo una migrazione una directory non è accessibile.
- Cloudflare mostra un identificativo evento.
Cause più frequenti
1. Permessi o proprietario errati
File e cartelle possono non essere leggibili dal processo web o appartenere all’utente sbagliato. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
2. File index assente
La directory listing è disabilitata e la cartella non contiene index.php o index.html. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
3. Regole .htaccess
Deny, Require, rewrite o protezioni copiate possono bloccare l’URL. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
4. WAF o ModSecurity
Il contenuto della richiesta può corrispondere a una regola di sicurezza. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
5. IP bloccato
Firewall, plugin o protezioni brute force possono limitare la rete del visitatore. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
6. Hotlink o regole CDN
Una protezione referer, paese, user agent o firewall può negare l’accesso. Verifica questa ipotesi usando il messaggio completo e i dati dell’orario interessato, senza basarti soltanto sul testo mostrato dal browser o dall’applicazione.
Diagnosi passo per passo
- Definisci l’ambito. Prova homepage, file diretto, wp-admin, seconda rete e finestra anonima. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Controlla error_log. Cerca permission denied, access denied, ModSecurity e percorso coinvolto. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Verifica permessi. Come riferimento comune controlla 644 per file e 755 per cartelle, senza applicarli indiscriminatamente. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Esamina .htaccess. Conserva una copia e cerca regole riferite a IP, cartelle, user agent o redirect. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Controlla sicurezza. Consulta eventi WAF, Imunify360, plugin e Cloudflare nell’orario esatto. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Verifica index e document root. Assicurati che il dominio punti alla cartella corretta e che sia presente il file iniziale. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
- Riproduci una sola volta. Evita tentativi ripetuti che possono generare un secondo blocco. Salva il risultato e confrontalo con il passaggio successivo; in questo modo potrai distinguere una causa locale da una configurazione del servizio.
Metodo sicuro di intervento
Prima di modificare la configurazione, registra lo stato iniziale: indirizzo o funzione coinvolta, messaggio completo, data e ora, ultima modifica nota e risultato da un secondo dispositivo, rete o strumento. Una diagnosi ripetibile è più utile di molti tentativi eseguiti contemporaneamente.
Applica una sola correzione alla volta e conserva una copia dei file, dei record o dei valori precedenti. Dopo ogni intervento ripeti esattamente il test originale e controlla i log relativi allo stesso intervallo temporale. Se il risultato cambia, annota quale modifica lo ha prodotto.
Evita disattivazioni globali di firewall, WAF, TLS, cache o sistemi di sicurezza. Quando serve una eccezione, deve essere limitata all’URL, al parametro, al processo o al servizio realmente interessato.
Procedura di risoluzione
- Ripristina permessi corretti. Intervieni sul percorso identificato e non usare 777. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Correggi la regola. Rimuovi o limita soltanto la direttiva che causa il blocco. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Ripristina il file index. Verifica che non sia stato rinominato, eliminato o messo in quarantena. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Richiedi analisi WAF. Fornisci URL, orario, IP e rule id per una eventuale esclusione mirata. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Sblocca l’IP dopo aver corretto la causa. Cambia credenziali errate sui dispositivi prima di richiedere lo sblocco. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Correggi document root. Associa il dominio alla directory effettiva del sito. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
- Svuota le cache pertinenti. Dopo la correzione elimina eventuali risposte 403 memorizzate. Dopo la modifica ripeti lo stesso test, controlla il log e verifica che non siano comparsi effetti collaterali.
Controlli finali
- URL e file restituiscono la risposta attesa.
- Il sito funziona da più reti.
- Il WAF resta attivo.
- Permessi e proprietario sono coerenti.
- Non compaiono nuovi access denied nel log.
Prevenzione
- Evita 777.
- Documenta regole .htaccess.
- Aggiorna plugin di sicurezza.
- Usa esclusioni WAF mirate.
- Controlla document root dopo migrazioni.
Errori da evitare
- Non disabilitare globalmente ModSecurity.
- Non cancellare .htaccess senza backup.
- Non cambiare proprietario con comandi non verificati.
- Non continuare tentativi con password errate.
- Non rendere pubblica una directory riservata.
Come documentare la verifica
Conserva una breve nota con configurazione iniziale, risultato di ogni controllo e modifica applicata. Inserisci sempre data e ora, perché cache, log, code, rate limit e processi pianificati possono cambiare nel tempo. Questa documentazione facilita il rollback e permette all’assistenza di evitare verifiche già eseguite.
Quando confronti due test, usa le stesse condizioni: stesso URL o destinatario, stesso file, stesso client e stessa rete quando possibile. Se cambi più variabili, il risultato non permette di individuare con certezza la causa.
Controllo incrociato
Dopo la correzione esegui almeno un controllo indipendente. Per un sito confronta browser, risposta HTTP e log; per DNS interroga autoritativo e resolver pubblico; per la posta confronta Webmail, intestazioni e Track Delivery; per PHP verifica il valore effettivamente applicato al dominio. Un solo indicatore può essere influenzato da cache o configurazioni locali.
Se il problema ricompare, evita ulteriori modifiche e raccogli nuovamente i dati. La ricorrenza può indicare un processo pianificato, un limite raggiunto, una dipendenza esterna o una configurazione che viene rigenerata automaticamente.
Quando contattare l’assistenza Xlogic
Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi oppure richiede log e configurazioni non disponibili nel pannello. Indica:
- URL
- IP pubblico
- orario
- estratto log o rule id
- modifiche recenti
Non inviare credenziali. Per iniziare la diagnosi sono sufficienti dati tecnici, orari, URL, codici e messaggi di errore.
Fonti tecniche ufficiali
Domande frequenti su errore 403 Forbidden
Un 403 significa che il file non esiste?
No. Normalmente il server conosce la risorsa ma nega l’accesso.
Posso impostare 777 per risolvere?
No. È una pratica insicura e spesso non corregge la causa reale.
Come capisco se è ModSecurity?
Cerca access denied e rule id nei log nell’orario del test.
Perché funziona da un’altra rete?
L’IP originale può essere bloccato da firewall, plugin o rate limiting.
Il 403 può dipendere da Cloudflare?
Sì, se una regola firewall, bot protection o access policy nega la richiesta.