Risolvere l'errore 403 Forbidden

Se il tuo sito web mostra il messaggio di errore 403 Proibito rispettivamente 403 Accesso negato viene visualizzato, il server web può in linea di principio raggiungere la risorsa richiesta, ma nega l'accesso ad essa.

La causa quindi spesso non risiede nel dominio stesso, ma nelle regole di accesso, nei permessi dei file, in un .htaccess-file o di una funzione di sicurezza.

In questa guida ti mostriamo come investigare sistematicamente su un errore 403 nel web hosting CURIAWEB e risolverne le cause più comuni.

Importante: Non modificare contemporaneamente i permessi dei file, .htaccess, ModSecurity e altre impostazioni di sicurezza. Controlla una possibile causa alla volta. È l'unico modo per scoprire cosa sta effettivamente causando l'errore 403.

Cosa significa 403 Forbidden? #

Il codice di stato HTTP 403 significa semplicemente:

La richiesta arriva al server web
        ↓
la risorsa richiesta viene riconosciuta
        ↓
l'accesso non è consentito
        ↓
403 Forbidden

Questo distingue un errore 403, ad esempio, da un classico errore 404.

Errore	In parole semplici, significa
403 Proibito	L'accesso alla risorsa è negato
404 Non Trovato	La risorsa richiesta non è stata trovata
Errore interno del server	Elaborazione lato server non riuscita
503 Servizio non disponibile	Il servizio non può elaborare la richiesta temporaneamente

Che aspetto può avere un errore 403? #

A seconda dell'applicazione e del server web, il messaggio visibile può essere formulato in modo diverso.

Gli esempi sono:

403 Accesso negato

Proibito

Accesso negato

Non si dispone dell'autorizzazione per accedere a questa risorsa.

Ciò che conta è il codice di stato HTTP 403.

403 su tutto il sito web o solo su un URL? #

Prima di modificare le impostazioni, dovresti circoscrivere il problema.

Verifica ad esempio:

• L'intero sito web è interessato?
• Solo una singola pagina?
• Solo l'area di amministrazione di WordPress?
• Solo un file o una directory?
• Solo un modulo o un'azione specifica?
• Solo la tua connessione Internet o il tuo indirizzo IP?

Questa distinzione fornisce già importanti indizi sulla possibile causa.

1. Annotare esattamente l'URL interessato #

Prendi nota prima dell'URL in cui si verifica l'errore.

Per esempio:

https://example.ch

o:

https://example.ch/wp-admin

o:

https://example.ch/download/datei.pdf

Se è interessato solo un URL specifico, non dovresti modificare immediatamente la configurazione dell'intero sito web.

2. Testare l'errore in una finestra di navigazione in incognito #

Apri l'URL interessato anche in una finestra privata o in incognito.

In questo modo puoi almeno escludere più facilmente determinati effetti locali di browser, cookie o sessione.

Tuttavia, una finestra di navigazione privata non aggira un blocco IP lato server.

3. Verificare se è interessato solo il tuo indirizzo IP #

Se il sito web mostra un errore 403 sul tuo dispositivo, ma funziona per altre persone o tramite un'altra connessione Internet, potrebbe essere coinvolto un blocco legato all'indirizzo IP.

Puoi, ad esempio, confrontare:

connessione internet domestica → 403
connessione cellulare → il sito web funziona

Questo è un chiaro indizio che il sito web non è bloccato in generale.

Consiglio pratico: Un test su una seconda connessione internet può essere molto utile in caso di errore 403. Per farlo, non disattivare precipitosamente le funzioni di sicurezza del sito web.

4. Controlla il log degli errori di cPanel #

Apri nel cPanel di CURIAWEB:

Valori misurati → Errore

Verifica se al momento dell'errore 403 è presente una voce corrispondente.

Spieghiamo come analizzare sistematicamente i messaggi di errore su Leggere il log degli errori di cPanel e trovare gli errori del sito web.

Annota sempre in corrispondenza delle segnalazioni pertinenti:

• Data e ora
• file o URL interessato
• esatta formulazione
• eventualmente specificata regola o causa

5. Controllare i permessi dei file #

I permessi di file errati sono tra le possibili cause di un errore 403.

Apri:

File → Gestione file

Naviga nella root dei documenti del dominio interessato e controlla i permessi dei file e delle directory interessati.

Nei siti Web tipici si possono spesso trovare i seguenti valori:

File:      644
Cartelle: 755

Questi non sono tuttavia valori che dovresti applicare ciecamente a ogni file e a ogni directory.

La nostra guida dettagliata è disponibile su Impostare correttamente i permessi dei file 644 e 755 in cPanel.

Attenzione: Non usare indiscriminatamente 777, per „risolvere“ un errore 403. I permessi di scrittura estremamente estesi non sono una correzione pulita e possono rappresentare un rischio per la sicurezza.

Perché autorizzazioni errate possono causare un errore 403 #

Il server web necessita di autorizzazioni sufficienti per poter accedere alle directory e ai file richiesti per una richiesta.

Se questi diritti sono impostati in modo troppo restrittivo o non idoneo, l'accesso potrebbe essere negato.

Il problema può verificarsi, ad esempio, dopo:

• di un trasferimento file manuale
• di una migrazione
• l'estrazione di un archivio
• una modifica manuale dei permessi

verificarsi.

6. Document Root del dominio controllare #

Verifica che il dominio punti alla directory in cui si trova il sito Web effettivo.

Apri per farlo:

Domini → Domini

Controlla la document root utilizzata per il dominio.

Spieghiamo come i domini e le document root sono collegati su Aggiungere e gestire un dominio in cPanel.

Una radice del documento errata può causare errori fuorvianti #

Supponendo che il tuo sito web si trovi su:

/public_html/meinewebsite/

ma il dominio punta a un'altra directory.

Il server web può quindi elaborare un contenuto o una directory diversi da quelli previsti.

Verifica quindi sempre prima se stai effettivamente modificando i file del dominio interessato.

7. Controllo del file di indice #

Se un dominio punta a una directory in cui non è presente un file di avvio idoneo, a seconda della configurazione del server, anziché l'elenco della directory potrebbe comparire un errore 403.

I file di avvio tipici sono, ad esempio:

index.php
index.html

Verifica nel file manager se nella root del documento del sito web è presente un file di avvio appropriato.

403 su una directory senza file di indice #

Un caso tipico si presenta in modo semplificato così:

/public_html/downloads/
    datei-a.pdf
    datei-b.pdf
    datei-c.pdf

Se dopo solo:

https://example.ch/downloads

richiami, il server non deve mostrare automaticamente un elenco dei file esistenti.

Se la visualizzazione delle directory è disattivata e non è presente alcun file di indice, l'accesso alla vista della directory può essere negato.

Ciò non significa necessariamente che i singoli file all'interno della directory siano anch'essi bloccati.

Non attivare inutilmente l'elenco delle directory #

Non attivare il directory listing o gli indici delle directory solo per eliminare un errore 403.

Un elenco di file pubblico può rivelare informazioni che non sono destinate ai visitatori.

Verifica prima se la directory deve essere accessibile direttamente.

8. Verificare .htaccess come possibile causa #

Il file .htaccess può contenere regole di accesso, reindirizzamenti e altre direttive Apache.

Una regola errata o intenzionalmente restrittiva può causare un errore 403.

Il file si trova spesso nella root dei documenti del sito web.

Se non è visibile nel file manager, leggi prima Visualizzare i file nascosti come .htaccess in cPanel.

.Non cancellare subito il file .htaccess #

Non cancellare semplicemente il file.

Lei può stabilire regole importanti per:

• Permalink di WordPress
• Reindirizzamenti
• Controllo degli accessi
• Funzioni di sicurezza
• configurazioni di siti web individuali

contenere.

Ti spieghiamo come modificarli in modo controllato su .htaccess spiegato e modificato in sicurezza.

.Testare .htaccess in modo controllato #

Se l'errore si verifica immediatamente dopo una modifica della .htaccess si è verificato, puoi prima creare una copia di backup.

Successivamente, dovresti annullare in modo mirato l'ultima modifica apportata.

È molto meglio che rimuovere tutte le regole in una volta sola.

Esempio:

Sito web funziona
        ↓
Aggiunta regola .htaccess
        ↓
Si verifica errore 403
        ↓
Verificare miratamente la nuova regola

Tipiche restrizioni di accesso in .htaccess #

Un' .htaccess può contenere regole che negano deliberatamente l'accesso a determinate risorse.

Se esiste una regola di questo tipo, un errore 403 potrebbe essere esattamente il risultato desiderato.

Non rimuovere quindi le norme di sicurezza prima di averne compreso lo scopo.

9. Controlla il blocco IP di cPanel #

cPanel fornisce sotto:

Sicurezza → Blocco IP

una funzione che consente di bloccare gli accessi da determinati indirizzi IP o intervalli.

Se solo determinati visitatori sono interessati, dovresti verificare se lì è presente un blocco adeguato.

Rimuovi il blocco IP solo se è effettivamente errato #

Un indirizzo IP bloccato potrebbe essere stato bloccato intenzionalmente.

Pertanto, non rimuovere un blocco solo perché un utente segnala un errore 403.

Verifica prima:

• quale IP è interessata
• perché è stata bloccata
• se il blocco sia ancora necessario

10. Verificare ModSecurity come possibile causa #

CURIAWEB si trova in cPanel sotto Sicurezza → ModSecurity disponibili adeguate funzioni di sicurezza.

ModSecurity è in grado di analizzare le richieste HTTP sulla base di regole di sicurezza. Se una richiesta viene ritenuta problematica, può essere bloccata.

Ciò può manifestarsi in determinate circostanze come errore 403.

Situazioni tipiche con ModSecurity #

Un problema può verificarsi, ad esempio, solo in occasione di un'azione ben precisa:

Visitare il sito        → funziona
Aprire WordPress        → funziona
Modificare l'articolo   → funziona
Inviare un modulo specifico → 403

Un simile schema depone più a favore di una regola di sicurezza basata sulla richiesta che di permessi errati dell'intero sito web.

Non disattivare permanentemente ModSecurity #

Se sospetti che sia coinvolta una regola di sicurezza, non dovresti semplicemente disattivare la protezione in modo permanente.

In questo modo verrebbe rimossa una funzione di sicurezza senza chiarire la causa effettiva.

Importante: Se una richiesta legittima viene bloccata in modo riproducibile da una regola di sicurezza, documenta l'URL interessato, l'azione e l'ora esatta. Ciò consente di indagare sulla causa in modo molto più mirato.

11. Considerare Imunify360 #

CURIAWEB utilizza inoltre Imunify360 come soluzione di sicurezza sul sistema di hosting.

Imunify360 non fa parte di cPanel stesso, ma è una piattaforma di sicurezza aggiuntiva integrata nell'ambiente di hosting.

I meccanismi di sicurezza possono rilevare attività sospette o classificate come dannose e reagire di conseguenza.

Se un accesso viene bloccato a causa di una misura di sicurezza, non dovresti aggirarla senza conoscere la causa scatenante.

403 dopo molti tentativi di accesso #

Se l'accesso viene improvvisamente bloccato dopo numerosi tentativi di accesso falliti o attività insolite, potrebbe essere coinvolto un meccanismo di sicurezza.

Verifica in particolare se:

• solo il tuo IP è interessato
• il sito web funziona tramite un'altra connessione
• l'errore si è verificato dopo un numero insolitamente alto di tentativi di accesso

Documenta in questo caso il tuo indirizzo IP pubblico e l'ora del problema per una verifica tecnica.

12. Verifica delle directory protette da password #

cPanel offre sotto:

File → Privacy per le cartelle

la possibilità di proteggere ulteriormente le directory con una password di accesso.

Se una directory è stata protetta intenzionalmente, potrebbero verificarsi corrispondenti limitazioni di accesso.

Spieghiamo come impostare e gestire questa protezione su Proteggere con password una cartella in cPanel.

13. Isolare WordPress come causa #

Se è interessato un solo sito web WordPress, potrebbero essere coinvolti anche componenti specifici di WordPress.

A ciò appartengono, ad esempio:

• Plugin di sicurezza
• Plug-in per firewall
• individuale .htaccess-Regole
• Conflitti tra plugin
• Codice tema
• proprie restrizioni di accesso

403 solo nell'area di amministrazione di WordPress #

Se il sito web pubblico funziona, ma ad esempio:

https://example.ch/wp-admin

genera un errore 403, dovresti controllare attentamente:

• Plugin di sicurezza per WordPress
• .htaccess-Regole
• Restrizioni basate su IP
• ModSecurity
• altri meccanismi di sicurezza

Un problema generale di dominio o DNS è in questo caso meno probabile, poiché il sito Web pubblico è fondamentalmente accessibile.

403 solo durante il salvataggio di un post di WordPress #

Se riesci a usare WordPress normalmente, ma ricevi un errore 403 durante il salvataggio di un determinato contenuto, il tipo di errore è particolarmente importante.

Verifica se l'errore:

• si verifica in ogni post
• si verifica solo con un determinato contenuto
• si verifica dopo l'inserimento di determinati contenuti HTML o script
• si verifica solo durante una determinata azione

Un 403 riproducibile su una determinata richiesta HTTP può indicare una regola di sicurezza.

403 nei moduli #

Se viene visualizzato un modulo di contatto ma l'invio fallisce con un errore 403, il normale caricamento della pagina funziona già.

La diagnosi dovrebbe quindi concentrarsi sulla richiesta al momento dell'invio.

I possibili ambiti sono:

• ModSecurity
• Plugin di sicurezza
• regola di accesso individuale
• errata configurazione dell'applicazione

In caso di tali problemi, annota se possibile l'ora esatta del tentativo fallito.

403 dopo l'installazione di un plugin #

Se l'errore inizia immediatamente dopo l'installazione o l'attivazione di un plugin di WordPress, questa correlazione temporale è un indizio importante.

In particolare, i plugin di sicurezza, firewall e login possono modificare i controlli di accesso.

Spiegheremo come isolare sistematicamente i problemi di plugin e temi su Identificare e risolvere i conflitti tra plugin e temi WordPress.

403 dopo una migrazione #

Se un sito web mostra un errore 403 immediatamente dopo un trasferimento, dovresti controllare in particolare:

• Document Root
• Permessi dei file
• .htaccess
• File di avvio
• restrizioni di accesso ereditate
• Plugin di sicurezza per WordPress

Le regole che funzionavano sul precedente ambiente di hosting non devono necessariamente adattarsi senza modifiche al nuovo ambiente.

403 dopo la decompressione di un file ZIP #

Se hai caricato e decompresso manualmente un sito web come archivio, verifica prima:

• se i file si trovano nella Document Root corretta
• se un index.php rispettivamente index.html disponibile
• se i permessi di file e directory sono plausibili
• se una in dotazione .htaccess contiene restrizioni di accesso

Spieghiamo come vengono gestiti i file ZIP nel gestore di file su Comprimere ed estrarre file ZIP in cPanel.

403 solo per un determinato file #

Se il sito web funziona e solo un singolo file genera un errore 403, concentra la diagnostica su questa risorsa.

Verifica:

• Permessi dei file
• autorizzazioni della directory padre
• .htaccess-Regole
• Protezione hotlink
• Norme di sicurezza

Considera la protezione dell'hotlink #

cPanel fornisce sotto:

Sicurezza → Protezione contro gli hotlink

una funzione che può limitare l'inclusione diretta di determinati file da siti web esterni.

Se, ad esempio, le immagini o i download non funzionano solo con l'inclusione esterna, dovresti verificare anche questa impostazione.

403 solo per immagini o download #

Se le pagine HTML funzionano, ma le immagini, i PDF o altri file generano un errore 403, verifica in particolare:

• Permessi dei file
• Autorizzazioni di directory
• Protezione hotlink
• .htaccess-Regole
• ModSecurity o altre regole di sicurezza

Non modificare l'intera configurazione del sito web se è interessato solo un singolo tipo di file.

Il DNS di solito non causa un classico 403 #

Se ricevi già una risposta 403 dal server web, significa che in linea di principio è stato raggiunto un server web.

Un classico guasto del DNS si manifesta diversamente.

Tuttavia, un dominio può, dopo una modifica DNS a un un altro server mostrare. Dopodiché il server web locale potrà ovviamente restituire un errore 403.

Verifica quindi, in caso di modifiche recenti ai DNS, se il dominio punta effettivamente all'ambiente di hosting desiderato.

Anche SSL non è la stessa cosa di 403 #

Un errore di certificato e un HTTP 403 sono diversi tipi di errore.

Se il tuo browser riceve già un codice di stato HTTP 403, la connessione HTTPS è stata fondamentalmente stabilita in modo sufficiente per ricevere una risposta dal server web.

Pertanto, non cambiare i certificati SSL per supposizione se il messaggio effettivo è 403.

Distinguere tra 403 e 404 #

Un errore 404 significa fondamentalmente che una risorsa richiesta non è stata trovata.

Un 403 invece significa che l'accesso non è consentito.

In WordPress possono inoltre influenzare il comportamento visibile le regole di reindirizzamento e di rewrite.

Se ricevi effettivamente un errore 404, la nostra guida Risolvere l'errore 404 di WordPress la base di partenza più adatta.

Differenziare tra 403 e 500 #

Un errore 500 Internal Server Error indica un errore lato server durante l'elaborazione.

Un 403, invece, nega l'accesso.

Se il tuo sito web mostra un errore 500, non dovresti perciò adottare le stesse misure previste per un errore 403.

Le istruzioni adatte si trovano su Risolvere l'errore 500 Internal Server Error.

Differenziare tra 403 e Resource Limit Is Reached #

Anche un limite di risorse CloudLinux appartiene a un'altra classe di errore.

Quando CloudLinux raggiunge un limite di risorse, dovresti analizzare l'utilizzo delle risorse anziché modificare i permessi dei file.

Vedi a riguardo Limite di risorse raggiunto: identificazione e risoluzione dei limiti di CloudLinux.

403 dopo la modifica della propria .htaccess #

Se l'errore è sorto immediatamente dopo una modifica manuale, inizia la diagnosi esattamente da lì.

Esempio:

10:15 → .htaccess modificato
10:16 → Il sito web restituisce 403

Questa correlazione è decisamente più significativa di una modifica casuale a PHP, DNS o WordPress.

Ripristina prima lo stato dell'ultima regola funzionante in questione.

403 dopo la modifica dei permessi dei file #

Lo stesso principio vale per le autorizzazioni.

Wenn du unmittelbar vor dem Fehler Rechte verändert hast, kontrolliere diese Änderung zuerst.

Setze nicht den gesamten Account pauschal auf andere Berechtigungen.

403 nach Aktivierung einer Sicherheitsfunktion #

Wenn unmittelbar zuvor beispielsweise eine Zugriffsbeschränkung, ein Sicherheitsplugin oder eine andere Schutzfunktion aktiviert wurde, sollte diese Änderung zuerst überprüft werden.

Das bedeutet nicht, dass die Sicherheitsfunktion grundsätzlich entfernt werden sollte.

Prüfe stattdessen, ob sie korrekt konfiguriert ist.

Fehler nach Änderung immer erneut testen #

Nach jeder gezielten Änderung solltest du die exakt gleiche URL beziehungsweise Aktion erneut testen.

Esempio:

403 reproduzieren
        ↓
eine mögliche Ursache ändern
        ↓
gleiche URL erneut testen
        ↓
Ergebnis dokumentieren

So kannst du feststellen, ob deine Änderung tatsächlich relevant war.

Browser-Cache bei Tests berücksichtigen #

Bei der Fehlersuche solltest du nach Änderungen gegebenenfalls ein privates Browserfenster oder einen anderen Browser verwenden.

Damit reduzierst du das Risiko, dass lokal gespeicherte Inhalte deine Beurteilung verfälschen.

Serverseitige Zugriffsbeschränkungen werden dadurch allerdings nicht aufgehoben.

Keine Sicherheitsfunktionen dauerhaft deaktivieren #

Ein 403-Fehler ist häufig gerade das Ergebnis einer Sicherheitsentscheidung.

Die falsche Reaktion wäre deshalb:

403 erscheint
        ↓
alle Sicherheitsfunktionen deaktivieren
        ↓
Website funktioniert
        ↓
Schutz bleibt ausgeschaltet

Damit wäre zwar möglicherweise das Symptom beseitigt, aber gleichzeitig eine Schutzfunktion entfernt.

Die bessere Vorgehensweise lautet:

403 erscheint
        ↓
Auslöser identifizieren
        ↓
legitime oder unerwünschte Anfrage unterscheiden
        ↓
gezielt korrigieren

Keine Dateiberechtigungen 777 als Standardlösung #

Die Berechtigung 777 wird in älteren Internetanleitungen häufig als schnelle Lösung für Berechtigungsprobleme vorgeschlagen.

Das ist keine sinnvolle Standardmaßnahme.

Verwende nur die Berechtigungen, die für die betreffende Anwendung und Serverumgebung erforderlich sind.

403 systematisch diagnostizieren #

1. Notiere die genaue betroffene URL.
2. Prüfe, ob die ganze Website oder nur eine Ressource betroffen ist.
3. Teste die URL in einem privaten Browserfenster.
4. Prüfe bei Verdacht auf IP-Sperre eine zweite Internetverbindung.
5. Controlla Valori misurati → Errore.
6. Prüfe den Document Root der Domain.
7. Kontrolliere die betroffenen Datei- und Verzeichnisberechtigungen.
8. Prüfe, ob eine geeignete Indexdatei vorhanden ist.
9. Untersuche relevante .htaccess-Regeln.
10. Prüfe gegebenenfalls die cPanel-IP-Blockierung.
11. Berücksichtige ModSecurity und andere Sicherheitsmechanismen.
12. Prüfe bei WordPress Sicherheitsplugins und kürzlich vorgenommene Änderungen.
13. Ändere immer nur eine mögliche Ursache gleichzeitig.
14. Teste anschließend exakt dieselbe URL beziehungsweise Aktion erneut.

Was du bei einem 403 nicht tun solltest #

Evita in particolare:

• alle Dateien pauschal auf 777 setzen
• .htaccess ohne Sicherung löschen
• ModSecurity dauerhaft abschalten
• Sicherheitsplugins wahllos entfernen
• IP-Sperren ohne Prüfung löschen
• PHP-Version ohne Zusammenhang wechseln
• DNS-Einträge auf Verdacht verändern
• mehrere Einstellungen gleichzeitig ändern

Regola fondamentale: Ein 403-Fehler bedeutet Zugriff verweigert. Konzentriere die Diagnose deshalb zuerst auf Berechtigungen, Zugriffskontrollen, Sicherheitsregeln und die konkret betroffene Ressource.

Quando dovresti contattare il supporto di CURIAWEB? #

Wenn der 403-Fehler weiterhin besteht oder eine Sicherheitsregel als Ursache vermutet wird, dokumentiere das Problem möglichst genau.

Sono particolarmente utili:

• dominio interessato
• vollständige betroffene URL
• Data e ora esatte
• messaggio di errore visibile
• ob die ganze Website oder nur eine bestimmte Aktion betroffen ist
• ob der Fehler über eine zweite Internetverbindung ebenfalls auftritt
• deine öffentliche IP-Adresse, falls nur dein Anschluss betroffen ist
• modifiche recenti
• relevante Einträge aus dem Error Log

Wenn der Fehler nur beim Absenden eines Formulars oder bei einer bestimmten Aktion auftritt, beschreibe zusätzlich genau, welche Schritte den Fehler reproduzieren.

Riepilogo #

Uno 403 Proibito bedeutet, dass der Webserver die angeforderte Ressource grundsätzlich erreicht, den Zugriff darauf aber verweigert.

Zu den häufigsten Bereichen, die du überprüfen solltest, gehören Dateiberechtigungen, Document Root, Indexdateien, .htaccess, IP-Sperren, ModSecurity und andere Sicherheitsmechanismen.

Wenn nur deine eigene Internetverbindung betroffen ist, solltest du eine IP-bezogene Sperre berücksichtigen. Wenn dagegen nur eine bestimmte Aktion wie das Absenden eines Formulars einen 403 erzeugt, kann eine anfragebezogene Sicherheitsregel beteiligt sein.

Bei WordPress können zusätzlich Sicherheitsplugins, individuelle Zugriffsbeschränkungen und Plugin-Konflikte relevant sein.

Setze Dateiberechtigungen nicht pauschal auf 777 und deaktiviere Sicherheitsfunktionen nicht dauerhaft, nur damit der Fehler verschwindet.

Vergleiche den Zeitpunkt des Fehlers mit dem Error Log und mit kürzlich vorgenommenen Änderungen. Ändere anschließend immer nur eine mögliche Ursache und teste erneut.

La regola più importante è: Erst feststellen, wer oder was tatsächlich vom Zugriff ausgeschlossen wird – und danach die konkrete Zugriffsbeschränkung gezielt untersuchen.