Ein 403-Forbidden-Fehler bedeutet, dass der Server die Anfrage erhalten und verstanden hat, sie aber nicht beantworten will. Anders als bei einem 401 hilft eine Anmeldung nicht unbedingt: Der Server sagt, dass dieser Client, von dieser Adresse, mit diesen Berechtigungen, diese Ressource nicht bekommt. Die Ursache ist fast immer eine Regel, kein Absturz: Dateiberechtigungen, eine fehlende Indexdatei, eine Deny-Regel in der Serverkonfiguration, eine Firewall oder ein Bot-Schutz, eine IP- oder Ländersperre oder ein Konto ohne passende Rolle. Website-Betreiber finden die Regel im Error-Log oder im Ereignisprotokoll der Firewall; Besucher können meist nur ändern, was sie senden.
403 vs. 401 vs. 404
CodeWas der Server sagtWas hilft401 UnauthorizedWer sind Sie? Senden Sie Zugangsdaten.Anmelden oder ein gültiger API-Schlüssel bzw. Token403 ForbiddenIch weiß, was Sie wollen, und Sie bekommen es nicht.Andere Berechtigungen, Adresse oder Anfrage404 Not FoundHier gibt es nichts.Die richtige Adresse
Server halten sich nicht immer ans Lehrbuch. Manche antworten mit 404 statt 403, um zu verbergen, dass eine private Seite existiert, und manche antworten bei fehlenden Dateien mit 403: Ein privater Storage-Bucket etwa kann für ein nicht vorhandenes Objekt 403 liefern, wenn der Client den Bucket nicht auflisten darf. Den Rest finden Sie in der Referenz der HTTP-Statuscodes.
Häufige Ursachen
Datei- und Ordnerberechtigungen. Der Benutzer des Webservers kann die Datei nicht lesen oder den Ordner nicht betreten, oft nach einem Upload oder Deploy, der Dateien als anderer Benutzer kopiert hat.
Keine Indexdatei. Eine Anfrage für einen Ordner ohne index.html oder index.php auf einem Server mit deaktiviertem Verzeichnis-Listing beantwortet der Server mit 403. Ein fehlgeschlagener Deploy, der den Ordner leer hinterlassen hat, bewirkt dasselbe.
Deny-Regeln. Ein deny all in nginx, ein Require all denied in Apache oder eine Regel in der .htaccess, die einen Pfad, einen Dateityp oder einen User-Agent sperrt.
Eine Firewall oder ein Bot-Schutz. Eine WAF, der Bot-Schutz eines CDN oder ein Sicherheits-Plugin hält die Anfrage für automatisiert oder bösartig und blockiert sie, manchmal mit einer Challenge-Seite.
IP- und Ländersperren. Adresse, Netz oder Land des Besuchers stehen auf einer Sperrliste, oder die Seite ist auf ein Büronetz oder VPN beschränkt.
Fehlende Rechte. Der Besucher ist angemeldet, aber seine Rolle erlaubt die Seite nicht, oder einem API-Schlüssel fehlt der Scope für den Endpunkt.
Abgelaufene oder falsch signierte Links. Download-Links mit Signatur oder Ablaufzeit antworten mit 403, sobald sie abgelaufen sind.
Hotlink-Schutz. Bilder oder Dateien, die von einer anderen Website oder ohne den erwarteten Referer angefordert werden, werden abgewiesen.
Was Besucher versuchen können
Die Adresse prüfen. Ein Link, der auf einen Ordner statt auf eine Seite endet, oder ein vertippter Pfad kann auf einem Ordner landen, den der Server nicht auflistet.
Anmelden, oder mit dem richtigen Konto anmelden. Manche Websites zeigen nicht angemeldeten Besuchern oder Konten ohne Zugriff einen 403.
Die Cookies der Website löschen und neu laden. Eine alte Sitzung oder ein veraltetes Challenge-Cookie kann dafür sorgen, dass eine Firewall Sie weiter abweist.
Das Netzwerk wechseln. Schalten Sie ein VPN oder einen Proxy aus oder ein, oder versuchen Sie es über mobile Daten. Geteilte Adressen und Rechenzentrumsadressen werden häufiger gesperrt als private Anschlüsse.
Erweiterungen für die Website deaktivieren. Manche Datenschutz-Erweiterungen verändern Header so, dass eine Firewall anschlägt.
Den Website-Betreiber informieren, mit der Uhrzeit und einer eventuellen Referenznummer von der Fehlerseite. Mit dieser Nummer findet er die genaue Regel.
So finden und beheben Website-Betreiber den Fehler
Klären Sie zuerst, wer geantwortet hat. Sehen Sie sich die Fehlerseite und die Antwort-Header an: Ein CDN oder eine Firewall gibt sich meist selbst zu erkennen, mit einer Seite im eigenen Design, einem Server-Header oder einer Request-ID. Ist es Ihr Webserver, nennt sein Error-Log den Grund. Ist es das CDN oder die WAF, tut es deren Ereignisprotokoll.
Berechtigungen und Indexdateien
Auf Linux-Hosts brauchen Ordner meist 755 und Dateien 644, im Besitz des Benutzers, unter dem der Webserver oder PHP läuft. Prüfen Sie, bevor Sie etwas ändern, und beheben Sie einen 403 nie mit 777: Damit kann jeder Benutzer auf dem Server in Ihre Website schreiben.
ls -la /var/www/example.com/public
find /var/www/example.com/public -type d -exec chmod 755 {} +
find /var/www/example.com/public -type f -exec chmod 644 {} +
nginx protokolliert „directory index of … is forbidden“, wenn ein Ordner keine Indexdatei hat; Apache protokolliert, dass es keinen Index findet und das Verzeichnis-Listing deaktiviert ist. Prüfen Sie, ob der Deploy die Dateien dort abgelegt hat, wohin das Document Root des Servers zeigt.
Serverregeln
nginx protokolliert „access forbidden by rule“ für ein deny, Apache „client denied by server configuration“ für eine Require-Regel. Durchsuchen Sie die Konfiguration und jede .htaccess auf dem Pfad nach der passenden Regel. In WordPress schreibt das Speichern der Permalink-Einstellungen den Core-Teil der .htaccess neu, und Sicherheits-Plugins fügen dort und in ihren Einstellungen eigene Sperren hinzu.
Firewalls, CDNs und Sicherheits-Plugins
Suchen Sie die blockierte Anfrage im Ereignisprotokoll nach Uhrzeit, Adresse oder Request-ID, sehen Sie nach, welche Regel gegriffen hat, und entscheiden Sie, ob die Regel falsch ist oder die Anfrage tatsächlich unerwünscht war. Legen Sie Ausnahmen für bestimmte Adressen oder Pfade an, statt eine Regel für die ganze Website abzuschalten. Testen Sie nach einer Firewall-Änderung aus einem Netz außerhalb Ihres Büros, denn Ihre eigene Adresse steht womöglich auf der Allowlist.
Warum ein Monitor 403 bekommt, Ihr Browser aber nicht
Ein häufiger Fall: Die Website funktioniert bei Ihnen, aber Ihr Uptime-Monitor meldet 403. Meist ist nichts kaputt. Etwas vor der Website behandelt den Check als Bot, weil er einer ist:
Bot-Schutz. CDNs und WAFs stellen Clients, die kein JavaScript ausführen oder automatisiert wirken, eine Challenge. Ein Browser löst sie, ein Monitor nicht, also bekommt er einen 403 oder eine Challenge-Seite.
Rechenzentrumsadressen. Monitore prüfen von Servern aus, und manche Regeln sperren Hosting-Netze standardmäßig.
Ländersperren. Eine Website, die nur ihr Heimatland zulässt, sperrt einen Monitor, der aus dem Ausland prüft.
Rate-Regeln. Manche Firewalls antworten mit 403 statt 429, wenn ein Client zu viele Anfragen stellt.
Die Lösung: Setzen Sie den Monitor auf die Allowlist, am besten über seine IP-Adressen, denn einen User-Agent kann jeder kopieren. Lösen Sie es nicht, indem Sie 403 für die ganze Website als „erreichbar“ akzeptieren: Dann bleibt eine echte Sperre Ihrer Besucher unbemerkt. Muss eine Seite wirklich hinter dem Schutz bleiben, überwachen Sie einen Health-Check-Endpunkt außerhalb davon. Der Leitfaden zum Vermeiden von Fehlalarmen behandelt weitere Ursachen für Alarme, hinter denen kein Ausfall steckt.
403-Fehler und Uptimecheck
Ein HTTP(S)-Monitor im Uptime-Monitoring von Uptimecheck wertet standardmäßig Status von 200 bis 399 als erreichbar, ein 403 gilt also als Ausfall. Ein zweiter Check bestätigt ihn, bevor Sie alarmiert werden, und der Vorfall erklärt, wer geantwortet hat: Stammen der 403 oder eine Challenge-Seite von Cloudflare, Sucuri, Imperva, Akamai, DataDome, Vercel, Wordfence oder AWS WAF, nennt er diesen Dienst und was Sie dort freigeben müssen. Website-Checks kommen aus Stockholm, Schweden, mit einem User-Agent, der „Uptimecheck“ enthält. So lassen Sie Uptimecheck durch eine Firewall listet unsere Adressen mit fertigen Regeln für Cloudflare, WordPress-Sicherheits-Plugins und nginx auf, und warum ein Monitor ausgefallen sein kann, obwohl die Website funktioniert behandelt die übrigen Gründe.
Sie möchten wissen, ob eine Website überhaupt antwortet? Der kostenlose Is it down?-Checker wertet jede Antwort unter 500, auch einen 403, als erreichbar: Der Server hat geantwortet, auch wenn er abgelehnt hat.
Unterscheiden Sie einen blockierten Check von einem echten Ausfall. Testen Sie Uptimecheck 14 Tage kostenlos, ohne Kreditkarte.