Werkzeuge Anmelden 14 Tage testen
Illustration: Ein geschlossenes Gartentor in einer niedrigen Steinmauer, am Riegel hängt ein kleines oranges Vorhängeschloss.
Software

HTTP Statuscode 403: Forbidden

· 10 Min. Lesezeit

Der HTTP-Statuscode 403 sagt: Der Server hat die Anfrage verstanden und weigert sich, sie zu erfüllen. Die Adresse ist angekommen, der Server war erreichbar, er hat bewusst abgelehnt. Das unterscheidet 403 von einem Netzwerkfehler, von einer nicht gefundenen Seite und von einem fehlenden Login.

Ein 403 ist eine Entscheidung des Servers, keine Störung. Irgendwo in der Kette zwischen CDN, Webserver und Dateisystem steht eine Regel, die diese Anfrage nicht durchlässt. Die Regel zu finden ist die ganze Aufgabe.

Der Beitrag trennt zwei Lagen, die leicht vermischt werden: Du siehst einen 403 als Besucher einer fremden Seite, oder deine eigene Seite liefert ihn aus. Der zweite Fall ist der, der Arbeit macht.

Abgrenzung zu 401 und 404#

RFC 9110 definiert 403 so: Der Server hat die Anfrage verstanden, weigert sich aber, sie zu erfüllen. Wurden Anmeldedaten mitgeschickt, hält der Server sie für unzureichend — der Client soll die Anfrage nicht automatisch mit denselben Daten wiederholen. Und dann der Satz, der im Alltag zählt: Eine Anfrage kann aus Gründen verboten sein, die mit Anmeldedaten nichts zu tun haben.

401 Unauthorized ist der Code für fehlende oder ungültige Anmeldedaten. Der Server muss dabei eine WWW-Authenticate-Kopfzeile mitschicken, die sagt, welche Art Anmeldung erwartet wird; der Browser zeigt daraufhin den Anmeldedialog. 403 verlangt keine solche Kopfzeile, und ein erneuter Login ändert nichts.

404 Not Found heißt: keine Darstellung für diese Adresse — oder der Server will nicht verraten, dass es eine gibt. RFC 9110 erlaubt ausdrücklich, statt 403 einen 404 zu senden, wenn der Server die Existenz einer gesperrten Ressource verbergen möchte. Wer also 404 auf einer Adresse bekommt, die es sicher gibt, sieht möglicherweise eine getarnte Sperre.

Bei Apache gibt es eine Feinheit, die die Zuordnung leichter macht: Schlägt bei einem Passwortschutz die Berechtigungsprüfung fehl, antwortet Apache laut mod_authz_core standardmäßig mit 401, nicht mit 403. Erst AuthzSendForbiddenOnFailure On schaltet auf 403 um. Ein 403 in einem Verzeichnis mit .htaccess-Passwortschutz spricht also zuerst für eine andere Regel im selben Verzeichnis — es sei denn, jemand hat genau diesen Schalter gesetzt.

Ursachen beim Betreiber, in Prüfreihenfolge#

Illustration: Ein Gang mit mehreren geschlossenen Türen hintereinander; nur der Griff der vordersten Tür ist orange.

Die Reihenfolge geht von außen nach innen: erst das, was vor dem Server sitzt, dann die Serverkonfiguration, dann das Dateisystem. Jeder Schritt lässt sich in unter einer Minute prüfen.

1. Ein Zwischenglied antwortet, nicht dein Server. Liegt ein CDN oder eine Web Application Firewall vor der Seite, kann der 403 dort entstehen, ohne dass der Webserver die Anfrage je gesehen hat. Die Cloudflare-Dokumentation nennt als Auslöser die WAF-Regeln (verwaltete oder eigene), die Einstellung „Security Level" und den DDoS-Schutz — und gibt zugleich das Unterscheidungsmerkmal: Ein 403 mit Cloudflare-Gestaltung im Antworttext kommt von Cloudflare, ein 403 ohne diese Gestaltung vom Ursprungsserver. Dieselbe Seite nennt einen zweiten Fall, der leicht übersehen wird: Der eigene Server blockiert die IP-Bereiche von Cloudflare, und das CDN reicht den 403 nur durch.

2. Eine Zugriffsregel greift. Gesucht wird in .htaccess, in der Vhost-Konfiguration und in nginx.conf. Bei Apache heißt die Direktive Require: Require all denied sperrt unbedingt, Require ip und Require not ip sperren nach Adresse. Die älteren Formen Order, Allow und Deny stammen laut Apache-Dokumentation aus mod_access_compat, sind als veraltet markiert und werden in einer künftigen Version entfernt — die Dokumentation rät ausdrücklich, veralteten Anleitungen nicht zu folgen. Auch mod_rewrite kann sperren: Das Flag [F] liefert laut Flag-Referenz einen 403 und bricht die Regelverarbeitung ab.

<Files "wp-config.php">
    Require all denied
</Files>
RewriteRule "\.exe$" "-" [F]

Bei nginx macht das ngx_http_access_module mit allow und deny dasselbe; die Regeln werden laut Dokumentation der Reihe nach geprüft, bis die erste passt:

location /intern/ {
    allow 192.168.1.0/24;
    deny  all;
}

Greift so eine Regel, steht es im Fehlerlog. Apache schreibt client denied by server configuration und antwortet mit 403 — das steht so im Quelltext von mod_authz_core. nginx schreibt access forbidden by rule, ebenfalls mit 403, nachzulesen im Quelltext des Zugriffsmoduls.

3. Ein Verzeichnis ohne Indexdatei. Wird ein Verzeichnis aufgerufen und liegt dort keine der Dateien aus DirectoryIndex, erzeugt Apache laut mod_dir nur dann eine Auflistung, wenn die Option Indexes gesetzt ist. Ist sie es nicht — und das ist auf Produktivsystemen die richtige Einstellung —, antwortet Apache mit 403 und schreibt ins Log: Cannot serve directory …: No matching DirectoryIndex (…) found, and server-generated directory index forbidden by Options directive. Die Zeile stammt aus mod_autoindex; daneben steht die Direktive IndexForbiddenReturn404, die in genau diesem Fall 404 statt 403 sendet. nginx verhält sich gleich: autoindex steht laut Dokumentation standardmäßig auf off, und fehlt die Indexdatei, meldet der Kern directory index of "…" is forbidden und antwortet mit 403 — sichtbar im Quelltext des Kernmoduls. Zwei Beispiele: Ein Deploy hat index.html in einen Unterordner gelegt, oder die Indexdatei heißt index.htm, während die Konfiguration nur index.html kennt.

4. Dateirechte. Kann der Prozess des Webservers die Datei nicht lesen, ist die Antwort 403 — nicht 500. Apache schreibt in diesem Fall file permissions deny server access ins Log, wie im Kernquelltext hinterlegt; nginx ordnet einen Zugriffsfehler beim Öffnen der Datei im statischen Modul ebenfalls dem Status 403 zu. Das passiert nach Kopieraktionen als anderer Benutzer, nach Entpacken eines Archivs mit fremden Rechten oder wenn ein übergeordnetes Verzeichnis nicht durchquert werden darf. Die Prüfung ist ein ls -l auf die Datei und jedes Verzeichnis darüber, verglichen mit dem Benutzer, unter dem der Webserver läuft.

5. Hotlink-Schutz. Ein 403 nur auf Bildern, und nur, wenn sie direkt oder von fremden Seiten aufgerufen werden, ist das Muster eines Referer-Filters. Die Apache-Dokumentation zeigt die Variante mit SetEnvIf Referer und Require env und merkt an, dass der Referer-Header optional ist und gefälscht werden kann; die Bedingung !^$ sorgt dafür, dass Anfragen ohne Referer durchgelassen werden. nginx löst das mit valid_referers und return 403, und die Moduldokumentation sagt ausdrücklich, dass reguläre Browser den Referer auch bei gültigen Anfragen weglassen können. Wer diesen Fall vergisst, sperrt Besucher aus, die den Link aus einer Mail öffnen.

6. Geo- und Netzsperren. Sperren nach Herkunftsland oder Netz liefern einen 403, der sich vom eigenen Rechner aus nicht reproduzieren lässt, weil man selbst nicht betroffen ist. Bei nginx setzt das ngx_http_geo_module Variablen abhängig von der Client-IP; die Sperre selbst ist dann eine eigene Regel, die diese Variable auswertet. Bei CDNs ist es eine Firewall-Regel im Dashboard. Solche Regeln fallen erst auf, wenn sich jemand aus dem gesperrten Bereich meldet.

Eingrenzen in drei Schritten#

Illustration: Ein oranger Abhörbecher liegt an einer großen geschlossenen Schranktür; das Kabel führt aus dem Bild.

Erstens: die Antwort selbst ansehen, nicht die Fehlerseite.

curl -sI https://beispiel.de/pfad/

Die Zeile Server: sagt, wer geantwortet hat. Steht dort ein CDN, obwohl du einen Apache betreibst, liegt die Entscheidung vor deinem Server. Der Abruf mit -A und einem anderen User-Agent oder von einem anderen Netz aus zeigt, ob die Sperre an Kennung oder Adresse hängt. Wenn dir kein zweiter Standort zur Verfügung steht: Das SEO-Audit ruft die Adresse von einem fremden Server ab und meldet einen 403 als fehlerhaften Status — das reicht, um „nur von hier" von „überall" zu unterscheiden.

Zweitens: am CDN vorbei. Mit --resolve schickt curl die Anfrage direkt an die IP des Ursprungsservers, behält aber den Hostnamen:

curl -sI --resolve beispiel.de:443:203.0.113.10 https://beispiel.de/pfad/

Antwortet der Ursprung mit 200 und das CDN mit 403, ist die Ursache im CDN. Antworten beide mit 403, geht es am Server weiter.

Drittens: das Fehlerlog zum Zeitstempel. Die Meldungen aus dem Abschnitt oben sind eindeutig: client denied by server configuration ist eine Require-Regel, file permissions deny server access ein Rechteproblem, Cannot serve directory eine fehlende Indexdatei; bei nginx entsprechend access forbidden by rule, is forbidden und directory index of … is forbidden. Wo die Logs liegen, steht im Beitrag zum Statuscode 500 — es sind dieselben Dateien.

Steht im Log gar nichts, obwohl der 403 sicher vom eigenen Server kommt, antwortet die Anwendung selbst. Dann ist es keine Serverfrage mehr, sondern eine Berechtigungsprüfung in PHP oder im Framework, und die Suche geht dort weiter.

Was ein 403 für Googlebot bedeutet#

Google behandelt laut Dokumentation zu HTTP-Statuscodes alle 4xx-Antworten außer 429 gleich: Der Inhalt wird nicht verwendet, eine bereits indexierte Adresse wird aus dem Index entfernt, und die Crawling-Häufigkeit sinkt allmählich. Ein 403 ist für Google also dasselbe wie ein 404. Dieselbe Seite warnt ausdrücklich davor, 401 oder 403 zum Drosseln des Crawlings einzusetzen — die 4xx-Codes außer 429 haben auf die Crawling-Rate keinen Einfluss.

In der Search Console erscheint der Fall im Bericht zur Seitenindexierung als „Wegen Zugriffsverbot (403) blockiert". Die Hilfeseite zum Bericht formuliert es deutlich: Googlebot schickt nie Anmeldedaten, ein 403 ist deshalb aus Googles Sicht eine falsche Antwort des Servers, und die Seite wird nicht indexiert.

Ein Fall, der leicht übersehen wird, ist der Bot-Schutz. Eine WAF, die Googlebot für einen Angreifer hält, produziert genau diesen Befund — und die Seite verschwindet aus dem Index, ohne dass ein Besucher je einen Fehler sieht. Google weist in der Googlebot-Dokumentation darauf hin, dass die User-Agent-Kennung von Googlebot häufig von anderen Crawlern gefälscht wird. Eine Regel, die nur auf den User-Agent schaut, ist deshalb in beide Richtungen falsch: Sie lässt Nachahmer durch und sperrt bei einem Tippfehler das Original. Der belastbare Weg steht in der Anleitung zur Überprüfung von Googlebot: Reverse-DNS-Abfrage der IP, die auf googlebot.com, google.com oder googleusercontent.com enden muss, gefolgt von einer Vorwärtsauflösung zurück auf dieselbe IP — oder der Abgleich mit den veröffentlichten IP-Bereichen in common-crawlers.json.

Ob Google eine Seite gerade so sieht, zeigt die URL-Prüfung der Search Console. Taucht der 403 dort auf, während der Browser die Seite normal lädt, ist der Bot-Schutz der erste Verdächtige. Die weiteren Gründe, aus denen Seiten aus dem Index fallen, stehen in Warum Google deine Seiten nicht indexiert.

Wenn du den 403 als Besucher siehst#

Auf einer fremden Seite ist der Spielraum klein, weil die Entscheidung auf der anderen Seite fällt. Drei Dinge lohnen sich: die Seite in einem privaten Fenster öffnen, um Cookies und eine alte Sitzung auszuschließen; ein anderes Netz probieren, etwa Mobilfunk statt WLAN, weil Sperren an der Adresse hängen können; ein VPN oder einen Proxy abschalten, dessen Adressbereich der Betreiber gesperrt haben könnte. Bleibt der 403 in allen drei Fällen, hat der Betreiber dich, dein Netz oder dein Land ausgeschlossen — und nur er kann das ändern.

Was nicht hilft#

Den Browser-Cache leeren. Der 403 kommt bei jedem Aufruf frisch vom Server. Der Cache hat ihn nicht erzeugt und kann ihn nicht beheben.

Die .htaccess komplett löschen. Das beseitigt den 403 womöglich, zusammen mit dem Passwortschutz, den Weiterleitungen und den Regeln, die WordPress zum Funktionieren braucht. Besser: die Datei zeilenweise auskommentieren, bis der Verursacher feststeht. Wie eine saubere Datei aussieht, steht in Die Standard-.htaccess von WordPress.

Alle Rechte für alle setzen. Es behebt den Rechtefall, öffnet aber jede Datei für jeden Prozess auf dem System. Der Webserver-Benutzer braucht Leserechte, sonst nichts.

Den 403 in einen 404 umschreiben, um Google zu beruhigen. Für Google sind beide Codes gleich; die Seite fällt in beiden Fällen aus dem Index. Ein 404 ist nur dann richtig, wenn die Existenz der Ressource tatsächlich verborgen werden soll.

Googlebot am User-Agent erkennen und durchwinken. Das öffnet die Tür für jeden, der die Kennung in seinen Crawler schreibt. Die Ausnahme muss an der verifizierten IP hängen, nicht am String.

Der ehrliche Schluss#

Ein 403 ist einer der besser diagnostizierbaren Fehler, weil jede Ursache eine eigene Logzeile hinterlässt. Was ihn unangenehm macht, ist die Zahl der Stellen, an denen die Regel stehen kann: CDN, Firewall, Serverkonfiguration, Verzeichnisdatei, Dateisystem, Anwendung. Die Reihenfolge von außen nach innen erspart es, alle sechs auf einmal aufzumachen.

Wer nach der Durchsicht feststellt, dass Regeln im Spiel sind, die niemand kennt — eine Sperre, eine Umleitung, eine Datei mit fremden Rechten —, sollte den Fall nicht als Konfigurationsfehler abhaken. Gehackte Website erkennen beschreibt, woran man den Unterschied sieht. Und wenn der 403 auf einer Adresse liegt, die nur aus dem eigenen Auftritt verlinkt ist, ist es eher ein Wartungsfall: Tote Links finden zeigt, wie man solche Verweise systematisch aufspürt.

Quellen#