L’errore 403 Forbidden e’ uno dei codici di stato HTTP piu’ frustranti che un utente o un webmaster possa incontrare. A differenza di un classico errore 404, dove la pagina semplicemente non esiste, il codice HTTP 403 indica che il server ha compreso la richiesta ma si rifiuta deliberatamente di soddisfarla. In altre parole, la risorsa esiste, ma l’accesso negato e’ stato imposto dal server per ragioni di sicurezza o configurazione.
In questa guida completa analizzeremo nel dettaglio cos’e’ l’errore 403, quali sono le cause piu’ comuni e, soprattutto, come risolvere il problema su Apache, Nginx e WordPress. Che tu sia un amministratore di sistema esperto o un proprietario di sito web alle prime armi, troverai tutte le informazioni necessarie per diagnosticare e correggere questo errore.
Cos’e’ l’errore 403 Forbidden
Il codice di stato 403 Forbidden fa parte della famiglia degli errori 4xx del protocollo HTTP, cioe’ quegli errori che indicano un problema lato client o nella relazione tra client e server. Quando un browser riceve una risposta 403, significa che il server web ha ricevuto e compreso la richiesta, ma ha deciso di non autorizzare l’accesso alla risorsa specificata.
La definizione ufficiale secondo la RFC 7231 recita: “Il server ha compreso la richiesta ma rifiuta di autorizzarla”. Questo significa che, anche fornendo credenziali di autenticazione valide, il server potrebbe comunque negare l’accesso. Il 403 error e’ definitivo: il server non cambiera’ idea, a meno che la configurazione non venga modificata.
I messaggi piu’ comuni che potresti vedere nel browser includono:
- 403 Forbidden
- HTTP Error 403 – Forbidden
- Access Denied – You don’t have permission to access this resource
- Forbidden – You don’t have permission to access / on this server
- Error 403 – Accesso negato
Indipendentemente dalla variante del messaggio, il significato e’ sempre lo stesso: il server rifiuta di servire il contenuto richiesto.
Differenza tra errore 403 e 401
Una confusione molto comune riguarda la differenza tra l’errore 403 e l’errore 401 Unauthorized. Sebbene entrambi riguardino problemi di accesso, hanno significati profondamente diversi:
L’errore 401 Unauthorized indica che la richiesta non e’ stata completata perche’ mancano credenziali di autenticazione valide. In pratica, il server sta dicendo: “Non so chi sei, identificati”. Se l’utente fornisce le credenziali corrette, il server concedera’ l’accesso.
L’errore 403 Forbidden, invece, indica che il server sa chi sei (o non gli importa saperlo) ma ti nega comunque l’accesso. Il server sta dicendo: “So chi sei, ma non hai il permesso di vedere questa risorsa”. Fornire credenziali diverse non risolvera’ il problema, perche’ la restrizione e’ basata su regole di configurazione, permessi del filesystem o policy di sicurezza.
Per fare un’analogia pratica: il 401 e’ come presentarsi alla porta di un edificio senza badge, mentre il 403 e’ come avere un badge valido ma non autorizzato per accedere a un determinato piano.
Cause dell’errore 403
Le cause che possono generare un errore 403 Forbidden sono molteplici e variano in base alla configurazione del server, al CMS utilizzato e alle policy di sicurezza attive. Vediamo le piu’ comuni nel dettaglio.
Permessi file e cartelle errati (chmod)
Questa e’ in assoluto la causa piu’ frequente dell’errore 403 sui server Linux. Ogni file e ogni cartella nel filesystem hanno tre livelli di permessi: lettura (r), scrittura (w) e esecuzione (x), assegnati a tre categorie: proprietario, gruppo e altri utenti.
Se i permessi sono troppo restrittivi, il web server (che tipicamente gira come utente www-data o apache) non potra’ leggere i file e restituira’ un forbidden. Ad esempio, un file con permessi 600 e’ leggibile solo dal proprietario: se il proprietario non coincide con l’utente del web server, l’accesso sara’ negato.
I permessi standard per un sito web sono:
- 755 per le cartelle (il server puo’ attraversarle e leggerne il contenuto)
- 644 per i file (il server puo’ leggere il file)
Anche il proprietario (owner) e il gruppo dei file sono importanti. Su server con pannelli come Plesk o cPanel, ogni dominio ha il proprio utente di sistema. Se i file appartengono a un utente diverso, il web server potrebbe non avere i permessi necessari per leggerli.
File .htaccess con direttive restrittive
Il file .htaccess e’ un potente strumento di configurazione per Apache che permette di definire regole a livello di directory. Tuttavia, direttive errate o troppo restrittive possono facilmente causare un errore 403.
Ecco alcuni esempi di direttive che possono bloccare l’accesso:
# Blocca tutti gli accessi
Deny from all
# Blocca uno specifico range di IP
Order Allow,Deny
Deny from 192.168.1.0/24
# Blocca l'accesso a specifici file
<Files "config.php">
Require all denied
</Files>A volte il problema non e’ nel contenuto del file ma nel file stesso: un .htaccess corrotto, con caratteri invisibili o con errori di sintassi, puo’ causare un errore 403 o addirittura un errore 500.
Directory listing disabilitato
Quando un utente accede a una cartella che non contiene un file index (come index.html o index.php), il server puo’ reagire in due modi: mostrare l’elenco dei file presenti nella cartella (directory listing) oppure restituire un errore 403.
Per ragioni di sicurezza, la maggior parte dei server web ha il directory listing disabilitato per impostazione predefinita. Questo significa che, se manca il file index nella cartella richiesta, il server restituira’ un forbidden anziche’ esporre la struttura dei file.
La direttiva Apache che controlla questo comportamento e’:
# Abilita il directory listing (sconsigliato in produzione)
Options +Indexes
# Disabilita il directory listing (default sicuro)
Options -IndexesIP bloccato dal firewall o mod_security
Firewall applicativi come mod_security, fail2ban o firewall di rete possono bloccare specifici indirizzi IP o range di indirizzi, restituendo un errore 403 anziche’ un timeout o un reset della connessione.
Mod_security, in particolare, analizza le richieste HTTP alla ricerca di pattern sospetti (SQL injection, XSS, path traversal) e puo’ bloccare richieste legittime che contengono parole chiave considerate pericolose. Questo fenomeno e’ noto come “falso positivo” e puo’ colpire form di contatto, upload di file o anche semplici query string.
Per verificare se mod_security sta bloccando le richieste, controlla il log degli errori di Apache:
tail -f /var/log/apache2/error.log
# oppure
tail -f /var/log/httpd/modsec_audit.logHotlink protection attiva
L’hotlink protection e’ una misura di sicurezza che impedisce ad altri siti di incorporare direttamente le risorse (immagini, video, PDF) ospitate sul tuo server. Quando un browser richiede un’immagine, il server controlla l’header Referer: se il referer proviene da un dominio non autorizzato, il server restituisce un 403 Forbidden.
Questa protezione e’ solitamente configurata nel file .htaccess:
RewriteEngine On
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https://(www.)?tuodominio.it [NC]
RewriteRule .(jpg|jpeg|png|gif|webp)$ - [F]Se la configurazione e’ troppo aggressiva, potrebbe bloccare anche richieste legittime, ad esempio quando l’immagine viene aperta direttamente nel browser senza un referer.
File index mancante
Come accennato nella sezione sul directory listing, l’assenza di un file index nella cartella richiesta puo’ causare un errore 403. I file index piu’ comuni sono index.html, index.htm, index.php e default.html.
La priorita’ dei file index e’ definita nella configurazione di Apache con la direttiva DirectoryIndex:
DirectoryIndex index.html index.php index.htmSe nessuno di questi file esiste nella cartella e il directory listing e’ disabilitato, il server restituira’ un forbidden.
Imunify360 o WAF che blocca la richiesta
Sui server gestiti con pannelli come Plesk o cPanel, e’ comune trovare Imunify360 come sistema di sicurezza informatica avanzato. Imunify360 include un Web Application Firewall (WAF) che analizza il traffico in tempo reale e puo’ bloccare richieste considerate malevole.
Imunify360 puo’ causare un errore 403 in diversi scenari:
- Rilevamento di malware in un file PHP (il file viene “quarantinato” e reso inaccessibile)
- Pattern di attacco rilevato nella richiesta (anche se falso positivo)
- Rate limiting superato (troppe richieste dallo stesso IP)
- File PHP sospetto rimosso o rinominato dal modulo proattivo
Per verificare se Imunify360 sta causando il blocco, controlla il pannello Imunify360 nella sezione “Proactive Defense” e “Malware Scanner” oppure consulta i log in /var/log/imunify360/.
Come risolvere l’errore 403 su Apache
Apache e’ il web server piu’ diffuso al mondo e, di conseguenza, la maggior parte degli errori 403 Forbidden si verifica proprio su server Apache. Ecco le procedure di risoluzione passo per passo.
Verificare i permessi (644 per file, 755 per cartelle)
Il primo passo e’ sempre controllare i permessi del filesystem. Collegati al server via SSH e utilizza il seguente comando per verificare i permessi della cartella del sito:
# Verifica permessi della cartella principale
ls -la /var/www/html/
# Correggi i permessi delle cartelle (755)
find /var/www/html/ -type d -exec chmod 755 {} ;
# Correggi i permessi dei file (644)
find /var/www/html/ -type f -exec chmod 644 {} ;
# Verifica il proprietario dei file
chown -R www-data:www-data /var/www/html/Su server con Plesk, il proprietario dei file deve essere l’utente di sistema associato al dominio (ad esempio esempio.it:psacln), mentre la cartella httpdocs deve avere come gruppo psaserv con permessi 750.
Attenzione: non impostare mai permessi 777 (lettura, scrittura e esecuzione per tutti). Sebbene risolva il problema del 403, espone il server a gravi rischi di sicurezza. I permessi 644 per i file e 755 per le cartelle sono il giusto compromesso tra funzionalita’ e sicurezza.
Controllare il file .htaccess
Se i permessi sono corretti, il passo successivo e’ verificare il contenuto del file .htaccess. Per un test rapido, rinomina temporaneamente il file:
# Rinomina il file .htaccess
mv /var/www/html/.htaccess /var/www/html/.htaccess.bak
# Testa il sito
# Se funziona, il problema era nel .htaccess
# Ripristina il file originale
mv /var/www/html/.htaccess.bak /var/www/html/.htaccessSe il sito funziona dopo aver rinominato il file, il problema e’ nel .htaccess. Riabilitalo e rimuovi le direttive una alla volta per identificare quella problematica. Cerca in particolare direttive Deny from all, Require all denied o regole di riscrittura errate.
Verificare la configurazione del VirtualHost
La configurazione del VirtualHost di Apache definisce le regole per ogni sito ospitato sul server. Un errore nella direttiva Directory puo’ causare un errore 403:
<VirtualHost *:80>
ServerName esempio.it
DocumentRoot /var/www/html/esempio
<Directory /var/www/html/esempio>
Options -Indexes +FollowSymLinks
AllowOverride All
Require all granted
</Directory>
</VirtualHost>I punti critici da verificare sono:
Require all granted: deve essere presente per consentire l’accesso a tutti (in Apache 2.4). Se troviRequire all denied, l’accesso e’ bloccato.AllowOverride All: necessario se il sito usa un file.htaccess. ConAllowOverride None, il file .htaccess viene ignorato.DocumentRoot: deve puntare alla cartella corretta del sito.
Dopo ogni modifica alla configurazione di Apache, ricarica il servizio:
apachectl configtest # Verifica la sintassi
systemctl reload apache2 # Applica le modificheControllare mod_security e firewall
Se le soluzioni precedenti non hanno risolto il problema, verifica se mod_security sta bloccando la richiesta. Puoi controllare i log di audit:
# Log di Apache con errori mod_security
grep "ModSecurity" /var/log/apache2/error.log
# Log di audit dettagliato
cat /var/log/apache2/modsec_audit.logSe trovi una regola che causa un falso positivo, puoi disabilitarla specificamente per il tuo sito aggiungendo nel file .htaccess:
# Disabilita una regola specifica di mod_security
<IfModule mod_security2.c>
SecRuleRemoveById 123456
</IfModule>Controlla anche il firewall del server (iptables, firewalld, ufw) e eventuali sistemi di protezione come fail2ban per verificare che il tuo IP non sia stato inserito in una blacklist.
Come risolvere l’errore 403 su WordPress
WordPress e’ il CMS piu’ diffuso al mondo e l’errore 403 Forbidden e’ un problema ricorrente, soprattutto dopo aggiornamenti, installazione di plugin di sicurezza o migrazioni. Se il tuo sito WordPress in hosting WordPress mostra un errore 403, ecco come intervenire.
Rigenerare il file .htaccess
WordPress utilizza il file .htaccess per gestire i permalink. Un file corrotto e’ una delle cause piu’ comuni di errore 403 su WordPress. Per rigenerarlo:
- Collegati al server via FTP o SSH
- Rinomina il file
.htaccessin.htaccess.bak - Accedi alla bacheca di WordPress (se possibile)
- Vai in Impostazioni > Permalink
- Clicca su Salva le modifiche senza cambiare nulla
- WordPress generera’ automaticamente un nuovo file
.htaccess
Il contenuto standard del file .htaccess di WordPress e’:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressSe non riesci ad accedere alla bacheca, crea manualmente un nuovo file .htaccess con il contenuto sopra indicato.
Disattivare i plugin di sicurezza
Plugin come Wordfence, iThemes Security, Sucuri o All In One WP Security possono aggiungere regole al file .htaccess o bloccare richieste a livello applicativo, causando un 403 forbidden anche per utenti legittimi.
Se non riesci ad accedere alla bacheca, puoi disattivare i plugin via SSH o FTP:
# Rinomina la cartella dei plugin per disattivarli tutti
mv wp-content/plugins wp-content/plugins_disabled
# Oppure rinomina solo il plugin sospetto
mv wp-content/plugins/wordfence wp-content/plugins/wordfence_disabledSe il sito torna a funzionare, riattiva i plugin uno alla volta per identificare il colpevole. Una volta identificato, controlla le sue impostazioni di sicurezza o considera un’alternativa.
Per situazioni complesse in cui non riesci a risolvere autonomamente, il servizio SoccorsoWP di G Tech Group offre assistenza specializzata per il recupero di siti WordPress con errori critici.
Verificare il file wp-config.php
Il file wp-config.php e’ il cuore della configurazione di WordPress. Sebbene raramente sia la causa diretta di un errore 403, alcuni scenari possono causare problemi:
- Permessi errati: il file
wp-config.phpdovrebbe avere permessi600o640, ma mai000(che lo renderebbe illeggibile). - Proprietario errato: se il proprietario del file non corrisponde all’utente del web server o all’utente del dominio, PHP potrebbe non riuscire a leggerlo.
- Costanti di debug: abilitare
WP_DEBUGpuo’ aiutare a identificare la causa del problema mostrando messaggi di errore dettagliati.
# Verifica permessi e proprietario
ls -la wp-config.php
# Imposta permessi corretti
chmod 640 wp-config.php
# Abilita il debug temporaneamente
# Aggiungi in wp-config.php:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Il log di debug verra’ scritto in wp-content/debug.log e potra’ fornire informazioni preziose sulla causa dell’errore.
Come risolvere l’errore 403 su Nginx
Su Nginx, l’errore 403 Forbidden ha cause simili a quelle di Apache, ma la configurazione e’ diversa. Nginx non utilizza file .htaccess ma si basa interamente su file di configurazione centralizzati.
Le cause piu’ comuni su Nginx includono:
Permessi del filesystem: come per Apache, i file devono avere permessi 644 e le cartelle 755. Inoltre, l’utente Nginx (solitamente nginx o www-data) deve avere permessi di esecuzione su tutte le cartelle padre fino alla root del sito.
# Verifica che tutte le cartelle padre siano attraversabili
namei -om /var/www/html/esempio/index.htmlDirettiva autoindex: se un utente accede a una cartella senza file index e autoindex non e’ abilitato, Nginx restituisce un 403:
location /documenti/ {
autoindex on; # Abilita il listing (attenzione alla sicurezza)
}Direttive allow/deny: Nginx utilizza direttive allow e deny per controllare l’accesso:
location /admin/ {
allow 192.168.1.0/24;
deny all; # Blocca tutti tranne la rete locale
}File index non configurato: verifica che la direttiva index includa il file corretto:
server {
index index.html index.php;
root /var/www/html/esempio;
}Dopo ogni modifica alla configurazione di Nginx, verifica e ricarica:
nginx -t # Verifica la sintassi
systemctl reload nginx # Applica le modifichePer diagnosticare il problema, consulta il log degli errori di Nginx:
tail -f /var/log/nginx/error.logIl log indichera’ chiaramente se l’errore e’ dovuto a permessi insufficienti (permission denied), directory index mancante (directory index of "/path/" is forbidden) o direttive di accesso (access forbidden by rule).
Come prevenire l’errore 403
Prevenire e’ sempre meglio che curare. Ecco una serie di best practice per evitare che l’errore 403 Forbidden si presenti sul tuo sito:
Standardizza i permessi: implementa uno script che periodicamente verifica e corregge i permessi dei file. Questo e’ particolarmente importante dopo aggiornamenti del CMS, upload di file o interventi di manutenzione che potrebbero alterare i permessi.
#!/bin/bash
# Script per correggere i permessi di un sito web
SITEPATH="/var/www/html/miosito"
find "$SITEPATH" -type d -exec chmod 755 {} ;
find "$SITEPATH" -type f -exec chmod 644 {} ;
echo "Permessi corretti per $SITEPATH"Fai backup del file .htaccess: prima di qualsiasi modifica al file .htaccess, crea sempre una copia di backup. Un errore di sintassi puo’ rendere l’intero sito inaccessibile.
Testa le modifiche in staging: se possibile, testa le modifiche alla configurazione del server in un ambiente di staging prima di applicarle in produzione. Questo riduce drasticamente il rischio di downtime.
Monitora i log del server: configura un sistema di monitoraggio che ti avvisi quando si verificano errori 403 anomali. Un improvviso aumento di errori 403 potrebbe indicare un problema di configurazione, un attacco in corso o un’interferenza da parte di un WAF.
Documenta le regole di sicurezza: ogni direttiva di blocco (mod_security, firewall, .htaccess) dovrebbe essere documentata con la data di inserimento, la motivazione e il responsabile. Questo facilita enormemente il troubleshooting quando un errore 403 si presenta inaspettatamente mesi dopo.
Mantieni aggiornato il software: server web, CMS, plugin e moduli di sicurezza aggiornati riducono il rischio di conflitti e incompatibilita’ che possono causare errori 403 Forbidden.
Configura pagine di errore personalizzate: anche se non previene l’errore, una pagina 403 personalizzata migliora l’esperienza utente fornendo informazioni utili e un link per tornare alla home page:
# In .htaccess (Apache)
ErrorDocument 403 /errore-403.html
# In nginx.conf (Nginx)
error_page 403 /errore-403.html;FAQ su Errore 403 Forbidden
L’errore 403 dipende dal mio browser?
No, l’errore 403 Forbidden e’ generato dal server, non dal browser. Cambiare browser non risolvera’ il problema. Tuttavia, provare con un browser diverso puo’ aiutare a escludere problemi legati alla cache o ai cookie. Se il 403 si presenta solo su un browser specifico, svuota la cache e i cookie per quel sito.
Posso risolvere il 403 svuotando la cache del browser?
In rari casi si. Se il server ha restituito un 403 temporaneo (ad esempio a causa di un rate limiting) e la risposta e’ stata memorizzata nella cache del browser, svuotare la cache potrebbe mostrare la versione aggiornata della pagina. Tuttavia, nella maggior parte dei casi, il problema e’ lato server e va risolto a quel livello.
L’errore 403 influisce sulla SEO del mio sito?
Si, un errore 403 persistente puo’ avere un impatto negativo sulla SEO. I motori di ricerca, quando incontrano ripetutamente un HTTP 403 su una pagina precedentemente indicizzata, potrebbero rimuoverla dall’indice. Inoltre, un alto numero di errori 403 nel report di Google Search Console puo’ indicare problemi di qualita’ del sito. E’ importante risolvere gli errori 403 il prima possibile e, se una pagina deve essere permanentemente inaccessibile, utilizzare un redirect 301 verso una pagina alternativa.
Come faccio a sapere se il mio IP e’ bloccato?
Se il sito funziona per altri utenti ma non per te, il tuo IP potrebbe essere stato bloccato da un firewall o da un sistema anti-DDoS. Per verificarlo, prova ad accedere al sito tramite una VPN o un proxy: se funziona, il tuo IP e’ bloccato. Contatta l’amministratore del server per farlo rimuovere dalla blacklist oppure controlla i log di fail2ban e del firewall.
L’errore 403 puo’ essere causato da un plugin WordPress?
Assolutamente si. Plugin di sicurezza, caching o ottimizzazione possono aggiungere regole restrittive al file .htaccess o bloccare richieste a livello applicativo. Disattivare i plugin via FTP e riprovarli uno alla volta e’ il metodo piu’ efficace per identificare il colpevole.
Qual e’ la differenza tra 403 e 404?
L’errore 404 indica che la risorsa non esiste sul server, mentre il 403 Forbidden indica che la risorsa esiste ma l’accesso e’ negato. In altre parole, il 404 e’ “non trovo quello che cerchi”, il 403 e’ “so dov’e’ ma non te lo do”.
L’errore 403 puo’ verificarsi anche sulle API REST?
Si, le API REST possono restituire un errore 403 quando l’utente autenticato non ha i permessi necessari per accedere a un endpoint specifico. In questo caso, e’ necessario verificare i ruoli e le autorizzazioni dell’utente nell’applicazione backend. A differenza di un 401, il 403 nelle API indica che l’autenticazione e’ avvenuta con successo ma l’autorizzazione e’ stata negata.
Conclusione su Errore 403 Forbidden
L’errore 403 Forbidden puo’ sembrare intimidatorio, ma nella maggior parte dei casi la soluzione e’ piu’ semplice di quanto si pensi. Che si tratti di permessi errati, di un file .htaccess problematico o di un firewall troppo aggressivo, seguendo le procedure descritte in questa guida dovresti essere in grado di identificare e risolvere il problema.
Ricorda sempre di: verificare i permessi del filesystem come primo passo, controllare il file .htaccess e i log del server, e procedere con metodo escludendo una causa alla volta.
Se l’errore 403 persiste sul tuo sito WordPress e non riesci a risolverlo autonomamente, il team di SoccorsoWP e’ specializzato nel recupero di siti WordPress con errori critici. Per problemi di configurazione server, firewall o permessi su sistemi complessi, puoi richiedere il servizio di Assistenza Sistemi di G Tech Group per un intervento rapido e professionale.