403 Forbidden

Verwendung

Trifft ein 403-Forbidden-Fehler ein, besitzt der Client nicht genügend Berechtigungen, um auf die Ressource zuzugreifen. Dies ist ein häufiger und allgemein gehaltener Fehler, der dem Client mitteilt, dass die Anfrage nicht erlaubt ist. Dieser Status unterscheidet sich von 401 Unauthorized, denn der Fehler bleibt bestehen, auch wenn sich der Client erneut authentifiziert und die Anfrage noch einmal absendet. Der spezifischere Status 405 Method Not Allowed zeigt an, dass die Ressource verfügbar ist, die konkrete HTTP-Methode jedoch nicht zugelassen wird.

403 und 404 als Sicherheitsentscheidung

Server geben absichtlich 404 statt 403 zurück, um die Existenz einer Ressource zu verbergen. Eine Antwort mit 403 bestätigt, dass die Ressource vorhanden, der Zugriff aber beschränkt ist – bei sensiblen Pfaden ist das unerwünscht. Die Wahl zwischen 403 und 404 ist eine bewusste sicherheitstechnische Designentscheidung.

SEO-Auswirkung

Suchmaschinen wie Google indexieren keine URL, die den Status 403 zurückgibt. Zuvor indexierte URLs, die diesen Statuscode liefern, werden aus den Suchergebnissen entfernt. Seiten mit diesem Code verbrauchen kein Crawl-Budget. Verwenden Sie 403 nicht, um Googlebot auszubremsen. Nur 429 verringert die Crawl-Rate.

Beispiel

Der Client fordert eine geschützte Ressource an und der Server antwortet mit 403 Forbidden, um anzuzeigen, dass dem Client der Zugriff fehlt. Der Antwort-Body erläutert die Beschränkung.

Anfrage

GET /tech-news/confidential.pdf HTTP/1.1
Host: example.com

Antwort

HTTP/1.1 403 Forbidden
Content-Type: text/html
Content-Length: 154

<html>
  <head>
    <title>Access Denied</title>
  </head>
  <body>
    <p>Permission to access this resource is
    restricted.</p>
  </body>
</html>

Behebung

Ein 403 Forbidden bedeutet, dass der Server die Anfrage verstanden hat, die Ausführung der Aktion aber verweigert.

Prüfen Sie die Datei- und Verzeichnisberechtigungen auf dem Server. Unter Linux kontrollieren Sie Eigentümer und Berechtigungsbits mit ls -la. Der Webserver-Prozess (der üblicherweise als www-data oder nginx läuft) benötigt Lesezugriff auf die angeforderte Datei. Standardberechtigungen: 755 für Verzeichnisse, 644 für Dateien. Rekursiv korrigieren:

find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;
chown -R www-data:www-data /var/www/html

nginx verlangt zusätzlich Ausführungsrechte auf jedem übergeordneten Verzeichnis im Pfad von / bis zur ausgelieferten Datei.

Prüfen Sie .htaccess oder die Serverkonfiguration auf Verbotsregeln. Apache-Require-Direktiven, nginx-deny-Regeln oder vergleichbare Zugriffskontrollen blockieren bestimmte Pfade oder IP-Bereiche. Suchen Sie in Apache nach Require all denied oder Deny from all in .htaccess oder in -Blöcken. Suchen Sie in nginx nach deny all; innerhalb von location-Blöcken. Sehen Sie die betreffenden Konfigurationsdateien durch und prüfen Sie das Fehlerprotokoll auf den konkreten Grund der Ablehnung.

Vergewissern Sie sich, dass die anfragende IP nicht gesperrt ist. Eine Firewall, eine Web Application Firewall (WAF) oder eine Geoblocking-Regel weist Anfragen von beschränkten Adressen ab. Prüfen Sie die Zugriffsprotokolle des Servers auf Ablehnungseinträge. Cloudflare, AWS WAF und mod_security erzeugen allesamt 403-Antworten, wenn Regeln auslösen. Sehen Sie das WAF-Dashboard oder das Audit-Log durch, um die blockierende Regel zu ermitteln.

Stellen Sie sicher, dass der authentifizierte Benutzer über die erforderliche Rolle oder den erforderlichen Scope verfügt. Selbst bei gültiger Authentication benötigt das Konto die richtige Berechtigungsstufe. Überprüfen Sie die Rollenzuweisungen im Zugriffskontrollsystem der Anwendung. API-Endpunkte geben häufig 403 zurück, wenn dem Token die erforderlichen OAuth-Scopes fehlen.

Prüfen Sie die Einstellungen zum Verzeichnisindex, wenn ein Ordner angefordert wird. Die Anfrage an ein Verzeichnis ohne Standard-Indexdatei (z. B. index.html) liefert 403, wenn die Verzeichnisauflistung deaktiviert ist. Fügen Sie eine Indexdatei hinzu oder aktivieren Sie die Auflistung. In nginx:

location /files/ {
    autoindex on;
}

Fügen Sie in Apache der Verzeichniskonfiguration Options +Indexes hinzu. Das Aktivieren der Verzeichnisauflistung auf Produktionsservern stellt ein Sicherheitsrisiko dar.

Prüfen Sie SELinux- oder AppArmor-Richtlinien. Auf RHEL-/CentOS-Systemen verweigert SELinux dem Webserver den Zugriff auf Dateien außerhalb der erwarteten Pfade, selbst wenn die Unix-Berechtigungen das Lesen erlauben. Führen Sie sestatus aus, um den SELinux-Modus zu prüfen, und sehen Sie /var/log/audit/audit.log auf verweigerte Einträge durch. Kennzeichnen Sie Dateien mit restorecon -Rv /var/www/html neu oder setzen Sie den korrekten Kontext mit chcon.

Untersuchen Sie die Anforderungen an SSL/TLS-Client-Zertifikate. Server, die für wechselseitiges TLS konfiguriert sind, geben 403 zurück, wenn der Client kein gültiges Zertifikat vorlegt. Prüfen Sie die nginx-Direktive ssl_verify_client oder die Apache-Direktive SSLVerifyClient.

Code-Referenzen

.NET

HttpStatusCode.Forbidden

Rust

http::StatusCode::FORBIDDEN

Rails

:forbidden

http.StatusForbidden

Symfony

Response::HTTP_FORBIDDEN

Python3.5+

http.HTTPStatus.FORBIDDEN

Java

java.net.HttpURLConnection.HTTP_FORBIDDEN

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_FORBIDDEN

Angular

@angular/common/http/HttpStatusCode.Forbidden