Errore 403 Forbidden: cosa significa, cause e come risolverlo

L’errore 403 Forbidden è un codice di stato HTTP che indica una situazione precisa: il server ha compreso la richiesta, ma rifiuta di soddisfarla. Non significa necessariamente che il sito sia offline e non indica automaticamente un problema di password o di permessi sui file.

Il punto importante è capire chi sta negando l’accesso. Il blocco può dipendere dal browser o dalla sessione dell’utente, dall’indirizzo IP, da una CDN o da un Web Application Firewall, dalle regole del server oppure, nel caso di WordPress, da plugin, .htaccess, ownership e permessi.

Per questo motivo, davanti a un messaggio come 403 Forbidden, HTTP 403, Access Denied o You don't have permission to access this resource, conviene evitare modifiche casuali. Prima individua il livello in cui nasce il blocco, poi intervieni sulla causa.

Errore 403 Forbidden: cosa significa davvero

Secondo lo standard HTTP, un codice 403 Forbidden viene restituito quando il server comprende la richiesta ma rifiuta di eseguirla. Se sono state inviate credenziali, queste possono essere insufficienti, ma il divieto può dipendere anche da ragioni completamente estranee all’autenticazione. Puoi verificare la definizione nella specifica HTTP RFC 9110.

Questo dettaglio è importante perché evita un errore frequente nella diagnosi: un 403 non equivale semplicemente a “file esistente ma senza permessi”.

Il server potrebbe, per esempio, rifiutare la richiesta perché:

• l’utente o l’account non dispone dell’autorizzazione necessaria;
• l’indirizzo IP o la rete sono bloccati;
• una regola WAF considera la richiesta sospetta;
• una directory o una determinata URL sono protette;
• una configurazione Apache o Nginx impedisce l’accesso;
• ownership o permessi del filesystem non consentono al web server di leggere la risorsa;
• un plugin di sicurezza WordPress applica una restrizione;
• il sito impone volontariamente un limite geografico, di autenticazione o di accesso.

In altre parole, 403 descrive il risultato della richiesta, non identifica da solo la causa.

Differenza tra errore 401, 403 e 404

I codici 401, 403 e 404 vengono spesso confusi, ma rappresentano condizioni differenti.

Codice HTTP	Significato pratico	Cosa controllare
401 Unauthorized	Mancano credenziali di autenticazione valide oppure quelle fornite non sono accettate	Login, token, autenticazione HTTP
403 Forbidden	La richiesta è stata compresa ma il server rifiuta di soddisfarla	Autorizzazioni, WAF, IP, server, plugin, permessi
404 Not Found	Il server non trova una rappresentazione della risorsa oppure non vuole rivelarne l’esistenza	URL, risorsa rimossa, routing, redirect

C’è una sfumatura particolarmente utile: lo standard HTTP consente a un server di rispondere con 404 al posto di 403 per non rivelare l’esistenza di una risorsa protetta. Perciò non è corretto dedurre che ogni 403 dimostri necessariamente l’esistenza del file richiesto.

Se vuoi approfondire il codice Not Found, trovi una guida separata dedicata all’errore 404 e alla sua risoluzione.

Quando un 403 è intenzionale e non deve essere corretto

Non tutti i 403 rappresentano un malfunzionamento.

Una risposta Forbidden può essere esattamente ciò che il sistema dovrebbe restituire quando qualcuno tenta di accedere a:

• un’area riservata senza autorizzazione;
• file che non devono essere accessibili pubblicamente;
• directory amministrative protette;
• risorse disponibili soltanto da determinate reti o indirizzi IP;
• endpoint ai quali un determinato ruolo non deve accedere.

In questi casi il problema non è eliminare il codice 403, ma verificare che venga restituito soltanto alle richieste che devono realmente essere bloccate.

La situazione cambia quando il divieto compare su una pagina pubblica, sull’intero sito, nel pannello di amministrazione o su richieste che fino a poco prima funzionavano normalmente. A quel punto serve una diagnosi.

Prima di intervenire: capire da dove arriva il blocco

La tentazione più comune è iniziare immediatamente a svuotare cache, modificare .htaccess, disattivare plugin o cambiare i permessi.

È l’ordine sbagliato.

Prima di modificare il sito, prova a restringere il problema. Poche verifiche possono indicarti il livello da controllare.

Quello che osservi	Causa più probabile da verificare	Primo controllo
Il 403 compare soltanto a te	Browser, sessione, account, IP o rete	Navigazione privata e rete differente
Compare a tutti	Server, WAF, CDN o applicazione	Log ed eventuali modifiche recenti
Compare su una sola URL	Regola specifica, file, directory o routing	Configurazione relativa al percorso
Compare su tutto il sito	Configurazione globale, firewall o filesystem	Server e sicurezza
Compare solo su wp-admin	Sicurezza, autorizzazioni, plugin o WAF	Plugin/security events e log
Compare dopo una modifica	Configurazione appena cambiata	Ripristina o isola quella modifica
La pagina di errore mostra il provider CDN/WAF	Blocco edge/security	Eventi e regole del provider
Il CDN è attivo ma il 403 proviene dall’origine	Web server, ModSecurity, IP deny, filesystem	Log dell’origin server

Questa distinzione è molto più utile di una lunga lista di “soluzioni possibili”, perché permette di eliminare interi gruppi di cause prima di toccare la configurazione.

Il 403 compare a tutti o soltanto a te?

È il primo test che farei.

Prova ad aprire la stessa URL:

1. in una finestra di navigazione privata;
2. da un dispositivo differente;
3. usando una rete diversa, per esempio passando dal Wi-Fi alla connessione mobile.

Se il problema riguarda soltanto un browser o una sessione, la causa è probabilmente locale.

Se funziona cambiando rete ma non dispositivo, invece, diventa più plausibile un blocco legato all’indirizzo IP, alla rete, alla VPN o a una regola geografica.

Se nessuno riesce ad accedere, sposterei subito l’attenzione verso server, CDN, firewall o applicazione.

Una sola pagina, tutto il sito o solo l’area amministrativa?

Anche la portata del problema fornisce un’indicazione importante.

Un 403 su una singola directory può dipendere da una regola applicata proprio a quel percorso. Se il blocco riguarda l’intero dominio, una modifica globale del web server o del firewall diventa più probabile.

Su WordPress presta particolare attenzione alla differenza tra:

• front-end accessibile e wp-admin bloccato;
• amministrazione accessibile e una sola pagina pubblica bloccata;
• sito completamente irraggiungibile con risposta 403.

Sono tre scenari differenti e non dovrebbero partire tutti dalla stessa procedura.

Browser, account, rete, CDN/WAF o server di origine?

Un sito moderno può avere diversi livelli tra il browser dell’utente e WordPress:

browser → CDN/WAF → reverse proxy/web server → PHP/WordPress → filesystem

Il 403 può essere generato in qualsiasi punto della catena.

È proprio questa stratificazione che spiega perché due errori apparentemente identici possano richiedere soluzioni completamente diverse.

Se utilizzi un servizio come Cloudflare, per esempio, il blocco può essere applicato dal suo WAF oppure arrivare direttamente dall’origin server. La documentazione Cloudflare indica fra le possibili cause regole WAF, funzioni di sicurezza, regole ModSecurity lato origine e blocchi IP. Una pagina con branding Cloudflare fornisce inoltre un indizio utile per distinguere un errore prodotto dal servizio da uno restituito direttamente dall’origine. Puoi approfondire nella documentazione Cloudflare sul codice 403.

Come risolvere un errore 403 se stai visitando un sito

Se non gestisci il sito e stai semplicemente cercando di aprire una pagina, le possibilità di intervento sono necessariamente limitate.

Conviene procedere dai controlli meno invasivi.

Controlla URL, login e autorizzazioni

Per prima cosa verifica l’indirizzo.

Un link potrebbe puntare a:

• un’area privata;
• una directory non navigabile;
• una pagina disponibile solo dopo il login;
• una vecchia destinazione che oggi è protetta;
• una funzione riservata a un determinato account o ruolo.

Prova ad aprire la homepage e raggiungere nuovamente il contenuto attraverso la navigazione del sito.

Se il servizio richiede autenticazione, esegui nuovamente il login. Nel caso di account con più livelli di autorizzazione, controlla anche di stare utilizzando quello corretto.

Ricaricare ossessivamente la stessa URL raramente cambia qualcosa se il server sta applicando deliberatamente una regola di accesso.

Prova navigazione privata, cookie e sessione

Prima di cancellare tutti i dati del browser, utilizza una finestra privata.

È un test migliore perché consente di verificare rapidamente se il problema è collegato allo stato della sessione, senza eliminare immediatamente cookie e dati salvati.

Se in navigazione privata la pagina funziona, ha senso procedere con una pulizia selettiva dei dati relativi a quel sito o, quando necessario, svuotare la cache del browser.

Cache e cookie, però, non sono una spiegazione universale del codice 403. Sono soprattutto un controllo utile quando il problema riguarda autenticazione, sessioni o dati locali non più validi.

Se il 403 appare identico anche in una nuova sessione e da altri browser, continuare a cancellare cache difficilmente porterà alla soluzione.

Verifica VPN, rete e possibile blocco dell’indirizzo IP

Disattiva temporaneamente una VPN o un proxy, se li stai utilizzando, e riprova.

Puoi anche confrontare la risposta utilizzando un’altra rete.

Se il sito funziona tramite connessione mobile ma restituisce Forbidden tramite la connessione abituale, potrebbe essere coinvolto:

• l’IP pubblico;
• un range di indirizzi;
• la VPN;
• una regola del firewall;
• un controllo geografico o reputazionale.

Questo non significa automaticamente che il tuo IP sia stato inserito in una blacklist. È soltanto un indizio che permette di restringere la diagnosi.

Quando il problema può essere risolto solo dal proprietario del sito

Se il contenuto dovrebbe essere pubblico ma continua a restituire 403 da browser, dispositivi e reti differenti, come visitatore hai esaurito quasi tutte le verifiche utili.

A quel punto conviene segnalare al gestore:

• URL esatta;
• orario approssimativo del problema;
• messaggio visualizzato;
• eventuale identificativo mostrato nella pagina di errore;
• rete o paese dal quale stai tentando l’accesso.

Queste informazioni permettono al proprietario di cercare la richiesta nei log molto più rapidamente.

Come risolvere l’errore 403 sul tuo sito o su WordPress

Se l’errore 403 Forbidden compare su un sito che gestisci, l’approccio cambia completamente.

Non partirei dai permessi e non disattiverei indiscriminatamente tutti i plugin. Prima controllerei cosa è cambiato e quale componente sta effettivamente restituendo il divieto.

Parti dalle modifiche recenti e dai log, non dai tentativi casuali

Chiediti cosa è successo immediatamente prima dell’errore.

Hai:

• installato o aggiornato un plugin?
• modificato una regola firewall?
• attivato una CDN?
• cambiato DNS o proxy?
• modificato .htaccess?
• spostato file?
• cambiato ownership o permessi?
• applicato una nuova configurazione del server?

Una modifica temporalmente correlata non dimostra da sola la causa, ma è un ottimo punto dal quale iniziare.

Subito dopo controlla i log disponibili.

A seconda dell’infrastruttura possono essere utili:

• access log ed error log del web server;
• eventi del WAF;
• log di ModSecurity;
• pannello della CDN;
• log di sicurezza WordPress;
• log applicativi o PHP.

Cerca la richiesta che produce il 403 e verifica quale regola o componente l’ha respinta.

Modifica una variabile alla volta. Se cambi contemporaneamente plugin, firewall, .htaccess e permessi, anche quando il sito riprende a funzionare non saprai quale fosse la causa.

Controlla WAF, CDN, Cloudflare, ModSecurity e blocchi IP

I sistemi di sicurezza sono una delle aree da verificare prima di intervenire direttamente su WordPress.

Un Web Application Firewall può bloccare richieste in base a regole gestite, pattern considerati pericolosi, indirizzi IP, paese, rate limiting o regole personalizzate.

Se utilizzi Cloudflare, verifica gli eventi di sicurezza corrispondenti alla richiesta. Un 403 può essere prodotto da una regola WAF o da altre funzioni di protezione; può però anche provenire direttamente dall’origin server.

Non disabiliterei l’intero firewall come primo test su un sito pubblico.

È più sicuro identificare la regola responsabile, verificare perché scatta e applicare un’eccezione soltanto se la richiesta è realmente legittima.

Se il problema dipende invece da ModSecurity o da una regola gestita a livello hosting alla quale non hai accesso, raccogli URL, timestamp e dettagli della richiesta e passa queste informazioni all’assistenza del provider.

Verifica .htaccess se il server usa Apache

Se il sito usa Apache, un errore nel file .htaccess può effettivamente produrre un 403.

.htaccess è un file di configurazione distribuita utilizzato da Apache e WordPress se ne serve, tra le altre cose, per le regole dei permalink. La documentazione WordPress contempla esplicitamente anche il ripristino di un file corrotto. Puoi consultare la documentazione WordPress su Apache e .htaccess.

Prima di modificarlo:

1. scarica una copia di backup;
2. annota eventuali regole personalizzate;
3. rinomina temporaneamente il file, ad esempio in .htaccess-old;
4. riprova la pagina.

Se il problema scompare, hai un’indicazione forte che una regola contenuta nel vecchio file fosse coinvolta.

Quando riesci ad accedere all’amministrazione WordPress, puoi andare in Impostazioni → Permalink e salvare nuovamente la configurazione per rigenerare le regole standard compatibili con l’installazione.

Attenzione però: rigenerare .htaccess non ripristina automaticamente eventuali regole personalizzate aggiunte da hosting, plugin o interventi manuali. Prima di sostituire il file confronta quindi il backup con quello nuovo.

Per capire meglio cosa contiene e come funziona puoi approfondire nella nostra guida al file .htaccess.

Controlla le regole di accesso se utilizzi Nginx

Su un’installazione Nginx standalone la diagnosi cambia: Nginx non utilizza un file di configurazione per-directory equivalente a .htaccess. Le regole vengono gestite nella configurazione del server. Puoi consultare la documentazione WordPress dedicata a Nginx.

Controlla quindi i blocchi server e location, oltre a direttive e meccanismi che possono limitare l’accesso.

Nginx dispone, per esempio, di direttive allow e deny per consentire o negare richieste provenienti da determinati indirizzi e reti. La sintassi è descritta nella documentazione ufficiale del modulo HTTP Access.

Se utilizzi un hosting gestito e non hai accesso alla configurazione Nginx, non cercare inutilmente un .htaccess da modificare: invia al provider i dettagli della richiesta e chiedi di verificare i log e le regole applicate al percorso interessato.

Isola plugin WordPress e plugin di sicurezza

Un plugin può essere coinvolto, soprattutto se modifica:

• autenticazione;
• autorizzazioni;
• firewall;
• protezione del login;
• restrizioni geografiche;
• accesso alle directory;
• REST API;
• regole .htaccess.

Se il problema è apparso subito dopo l’installazione o l’aggiornamento di un plugin, partirei proprio da quello.

Quando la dashboard è accessibile, disattivalo temporaneamente e riprova la richiesta.

Se non puoi entrare in WordPress, puoi intervenire sui file tramite un accesso FTP al sito WordPress o tramite il file manager dell’hosting, rinominando temporaneamente la directory del plugin sospetto all’interno di wp-content/plugins.

Se non hai nessun candidato evidente e devi procedere per esclusione, fallo preferibilmente in staging o durante una finestra controllata. Disabilitare tutti i plugin contemporaneamente su un sito in produzione può interrompere funzionalità importanti e rende più difficile distinguere un problema applicativo da uno infrastrutturale.

Quando il 403 scompare, riattiva i componenti in modo controllato fino a identificare quello che riproduce il problema.

Verifica permessi e ownership di file e directory

I permessi possono provocare un 403, ma 755 per le cartelle e 644 per i file non sono valori universali da applicare ciecamente.

La documentazione WordPress specifica che lo schema appropriato dipende dall’hosting, dalla proprietà dei file, dall’utente con cui gira il web server e dalla configurazione dell’ambiente. In alcuni scenari sono normali, per esempio, 755/644; in altri possono essere corretti 775/664 oppure 750/640. Puoi approfondire nella guida ufficiale WordPress ai permessi dei file.

Prima di eseguire modifiche ricorsive verifica quindi:

ownership → utente/gruppo → permessi richiesti dall’hosting → directory o file realmente coinvolti

Non limitarti al numero visualizzato dal client FTP.

Un file può avere apparentemente un mode plausibile ma appartenere all’utente sbagliato; in quel caso il problema non si risolve rendendolo semplicemente più permissivo.

Evita inoltre di usare 777 come scorciatoia. Rendere una directory scrivibile ed eseguibile da tutti può introdurre un problema di sicurezza molto più serio del 403 che stai cercando di correggere.

Se il controllo porta davvero ai mode bit del filesystem, prima di modificarli è utile sapere come funziona chmod: r, w e x hanno conseguenze diverse su file e directory, mentre valori come 755 o 644 descrivono soltanto una specifica combinazione di quei permessi. Capire questa struttura evita di correggere un 403 aumentando i privilegi alla cieca.

Come individuare la causa esatta di un 403

Quando i controlli iniziali non chiariscono la causa dell’errore 403 Forbidden, conviene passare dalla logica “provo una soluzione” alla logica “osservo la risposta”.

È qui che il troubleshooting diventa molto più preciso.

Leggi pagina di errore, header HTTP e risposta del server

Non ignorare la pagina Forbidden.

Controlla se contiene:

• il nome del provider;
• un identificativo della richiesta;
• riferimenti al firewall;
• un messaggio personalizzato;
• indicazioni sull’autorizzazione;
• un timestamp.

Poi osserva gli header HTTP.

Da terminale puoi iniziare con:

curl -I https://example.com/percorso

Il comando mostra gli header senza scaricare normalmente il corpo della pagina.

Per una diagnosi più dettagliata puoi usare:

curl -v https://example.com/percorso -o /dev/null

L’output verbose permette di osservare connessione, richiesta, codice di risposta e header restituiti.

C’è però una precisazione: curl -I utilizza una richiesta HEAD. Se sospetti che il server applichi regole differenti in base al metodo HTTP, verifica anche la normale richiesta GET con il secondo comando.

Gli header possono aiutarti a capire quale infrastruttura sta rispondendo, ma non prenderne uno solo come prova definitiva. Reverse proxy e CDN possono modificare o nascondere informazioni sul server di origine.

Usa DevTools o curl per capire chi restituisce il blocco

Nel browser apri gli strumenti per sviluppatori e vai nella scheda Network.

Ricarica la pagina e seleziona la richiesta che restituisce 403.

Controlla:

• Request URL;
• Request Method;
• Status Code;
• Response Headers;
• Request Headers;
• eventuali redirect precedenti;
• corpo della risposta.

Questo è particolarmente utile quando il blocco riguarda una chiamata AJAX, una REST API, un file JavaScript, un’immagine o un endpoint specifico e non l’intera pagina.

Potresti scoprire, per esempio, che la pagina HTML risponde correttamente con 200 ma una chiamata successiva riceve 403. In quel caso modificare i permessi dell’intera installazione WordPress sarebbe un intervento sproporzionato.

Cambia una sola variabile alla volta e verifica il risultato

Un buon troubleshooting dovrebbe produrre una sequenza verificabile:

ipotesi → modifica controllata → nuova richiesta → risultato → log

Se sospetti il WAF, verifica quella regola.

Se sospetti .htaccess, isola quel file.

Se sospetti un plugin, intervieni sul componente interessato.

Se sospetti IP o rete, cambia soltanto la provenienza della richiesta.

Questo metodo è meno rapido soltanto in apparenza. In realtà evita il problema classico dei “cinque cambiamenti contemporanei”, dopo i quali il sito riprende a funzionare ma nessuno sa perché.

È anche il modo migliore per evitare che lo stesso errore torni alla modifica successiva.

Errore 403 e SEO: cosa succede se viene bloccato Googlebot

Se un 403 viene restituito intenzionalmente su un’area privata, non c’è necessariamente un problema SEO.

La situazione è diversa quando una URL che dovrebbe essere pubblica restituisce 403 anche ai crawler di Google.

Google documenta che i contenuti delle URL che restituiscono un codice 4xx non vengono utilizzati per l’indicizzazione. Per la Ricerca Google, una nuova URL con risposta 4xx non viene indicizzata e una URL precedentemente indicizzata che continua a restituire 4xx viene rimossa dall’indice nel tempo. Puoi consultare la documentazione Google sui codici HTTP e crawling.

Cosa accade a scansione e indicizzazione

Se l’errore 403 Forbidden viene restituito accidentalmente a Googlebot su una pagina che dovrebbe essere pubblica, il problema può coinvolgere direttamente scansione e indicizzazione.

Controlla:

• quando è iniziato il blocco;
• quali URL sono coinvolte;
• server log;
• regole WAF/CDN;
• eventuali restrizioni per IP, paese o user-agent;
• test dell’URL in Search Console.

Non partire dall’idea che “Google non riesce a indicizzare perché la pagina è protetta” senza verificare la risposta ricevuta realmente dal crawler.

Il sito può funzionare perfettamente dal tuo browser e contemporaneamente applicare una regola differente ad altri client o indirizzi.

Perché 403 non va usato per controllare il crawl rate

Un altro errore da evitare consiste nell’utilizzare deliberatamente 401 o 403 pensando di rallentare Googlebot.

Google specifica che 401 e 403 non vanno usati per limitare la frequenza di scansione e che i normali errori 4xx, con l’eccezione del 429, non producono quell’effetto.

Se il tuo obiettivo è gestire il crawling, utilizza quindi i meccanismi appropriati invece di negare l’accesso a contenuti che vorresti mantenere indicizzati.

Conclusione

L’errore 403 Forbidden diventa molto più semplice da affrontare quando smetti di considerarlo un singolo problema con una singola soluzione.

Il codice dice soltanto che la richiesta è stata compresa ma viene rifiutata. Il lavoro vero consiste nell’individuare dove avviene quel rifiuto.

Se sei un visitatore, partirei da URL e autenticazione, poi proverei una nuova sessione e una rete differente. Se il comportamento resta invariato, probabilmente la correzione richiede l’intervento del proprietario del sito.

Se gestisci il sito, invece, l’ordine che considero più efficace è:

portata del problema → modifiche recenti → log → CDN/WAF → web server → WordPress → filesystem

È molto più sicuro di partire direttamente da plugin, .htaccess o chmod, perché evita di correggere alla cieca un componente che potrebbe non avere nulla a che fare con il blocco.

E soprattutto, non usare valori di permesso più permissivi o disattivazioni globali soltanto per far sparire temporaneamente il 403. Una correzione è completa quando sai quale regola negava l’accesso e perché quella regola non dovrebbe applicarsi alla richiesta legittima.

Se il problema riguarda un sito WordPress in produzione e richiede interventi su configurazione, sicurezza o server che non vuoi eseguire alla cieca, puoi valutare un intervento di assistenza WordPress dopo aver raccolto URL, orario dell’errore e informazioni dai log.