HTTP 401 Error signalisiert fehlgeschlagene Website-Authentication
Ein HTTP 401 Error ist eine Antwort des Hypertext Transfer Protocol, die anzeigt, dass eine Website eine Anfrage empfangen und verstanden, die dazugehörigen Anmeldedaten jedoch nicht akzeptiert hat. Authentication, also der Vorgang zur Bestätigung einer Identität, kann fehlschlagen, weil ein Passwort, ein Anwendungsschlüssel oder Anmeldedaten fehlen, fehlerhaft formatiert, abgelaufen, widerrufen oder schlicht falsch sind. Besucher sehen möglicherweise eine leere Seite, eine Meldung über verweigerten Zugriff oder ein Browserfenster, das einen Benutzernamen und ein Passwort verlangt. Administratoren können auf ihren eigenen Anmeldeseiten auf dieselbe Barriere stoßen.
Der Code gehört zur 4xx-Familie von Antworten, die Probleme im Zusammenhang mit einer Anfrage abdeckt und nicht Fälle, in denen ein Server sie nicht verarbeiten kann. Das bedeutet nicht zwangsläufig, dass der Besucher das Problem verursacht hat. Eine fehlerhafte Regel auf dem Server kann für jeden legitimen Benutzer HTTP 401 Errors zurückgeben. Auch die Formulierung kann verwirrend sein: 401 Unauthorized bedeutet üblicherweise, dass keine Authentication erfolgt ist, weil der Server die Identität des Anfragenden nicht festgestellt hat. Eine 403-Antwort ist etwas anderes. Sie bedeutet, dass der Zugriff verweigert wird, obwohl die Identität bekannt ist oder andere Anmeldedaten an der Entscheidung nichts ändern würden.
Eine korrekt formatierte 401-Antwort sollte einen WWW-Authenticate header enthalten. Ein header besteht aus Informationen, die zusammen mit einer Webanfrage oder -antwort gesendet werden; dieser header gibt die erwartete Art der Authentication an, beispielsweise Basic oder Bearer. Basic authentication übermittelt einen codierten Benutzernamen und ein Passwort, während Bearer authentication ein token verwendet, das einem autorisierten Benutzer oder einer autorisierten Anwendung ausgestellt wurde. Browser nutzen diesen header, um zu entscheiden, ob sie ein Fenster zur Eingabe von Anmeldedaten öffnen sollen. Entwickler können ihn im Bereich „Network“ der Browser-Entwicklertools untersuchen, um festzustellen, welches System Anmeldedaten verlangt.
Die unmittelbaren Folgen gehen über eine lästige Anmeldung hinaus. Menschliche Besucher können die angeforderte Seite nicht erreichen, während Suchmaschinen-Crawler öffentliche URLs, die 401 zurückgeben, als nicht zugänglich behandeln. Öffentliche Seiten können in Suchmaschinen an Sichtbarkeit verlieren, wenn der Zustand anhält. Ein HTTP 401 Error in einem Administrationspfad kann den Betreiber außerdem daran hindern, weitere Reparaturen vorzunehmen. Bei einer API, also einer Programmierschnittstelle, über die Software Anfragen und Daten austauscht, kann der Fehler stattdessen als JSON- oder XML-Fehlertext, als Eintrag im HTTP-Clientprotokoll und als fehlgeschlagene Aufgabe an anderer Stelle der Anwendung erscheinen.
Zu den häufigsten Ursachen gehören geänderte Passwörter, deaktivierte Dienstkonten, abgelaufene tokens und ausgetauschte Anwendungsschlüssel. Anmeldesitzungen können ebenfalls veralten, wenn Authentication-Cookies nicht mehr zum Server passen. Das kann nach einer Domainänderung, einem Wechsel zwischen Adressen mit und ohne www, einer Migration von HTTP zu HTTPS oder der Neuerstellung von Sitzungsschlüsseln durch ein WordPress-Plugin auftreten. Bei WordPress und anderen Content-Management-Systemen, also Software zum Erstellen und Verwalten von Websites, können außerdem Konflikte zwischen Sicherheits-, Mitgliedschafts-, Caching- und Single-Sign-on-Komponenten auftreten. Solche Konflikte betreffen möglicherweise nur bestimmte Benutzerrollen oder Routen.
Ein weiterer häufiger Auslöser ist ein Passwortschutz auf Serverebene. Apache setzt ihn üblicherweise über .htaccess, eine Datei mit Serverregeln auf Verzeichnisebene, zusammen mit einer .htpasswd-Passwortdatei um. Nginx kann entsprechende auth_basic-Regeln anwenden. Eine verschobene Passwortdatei, ein nicht lesbares Passwortformat, falsche Dateiberechtigungen oder ein nach dem Start weiterhin aktiver Staging-Schutz können jeweils einen 401 verursachen. Ein reverse proxy, der Datenverkehr empfängt, bevor er ihn an die Website weiterleitet, kann den Authorization header entfernen. Ebenso können ein content delivery network, eine firewall oder ein load balancer eine übersehene Zugriffsregel anwenden oder eine geschützte Antwort im Cache speichern und dadurch sporadische Fehler verursachen.
Die Fehlerbehebung sollte mit den am wenigsten einschneidenden Prüfungen beginnen. Bestätigen Sie den genauen Status im „Network“-Bereich des Browsers und prüfen Sie die Antwort-header, insbesondere den WWW-Authenticate header. Öffnen Sie dieselbe Adresse in einem privaten Fenster und in einem anderen Browser. Wenn sie dort funktioniert, löschen Sie die Cookies und gespeicherten Websitedaten für die Domain, gegebenenfalls sowohl für die Version ohne www als auch für die mit www, und melden Sie sich anschließend erneut an. Stellen Sie fest, ob die gesamte Website, nur /wp-admin/ oder lediglich eine API-Route betroffen ist. Setzen Sie das betreffende Passwort, token, den API key oder das Anwendungspasswort zurück, bevor Sie Änderungen am Server vornehmen.
Sichern und prüfen Sie anschließend .htaccess oder die entsprechende Serverkonfiguration auf AuthType-, AuthUserFile-, Require- oder auth_basic-Regeln. Vergewissern Sie sich, dass die Passwortdatei vorhanden und lesbar ist. Durch das vorübergehende Deaktivieren des betreffenden Blocks lässt sich feststellen, ob die Server-Authentication das Problem verursacht hat. Leeren Sie die Caches von Plugins, Server, Objekten, Browser und content delivery network. Sofern es die Hostingkonfiguration zulässt, testen Sie die ursprüngliche Website ohne proxy oder firewall. Tritt der Fehler nur über diesen Vermittler auf, müssen dessen Regeln oder die Verarbeitung von headern geprüft werden.
Bei WordPress können alle Plugins gemeinsam deaktiviert und anschließend einzeln wieder aktiviert werden, bis der Fehler erneut auftritt. Wenn das Dashboard nicht zugänglich ist, erzwingt das Umbenennen des Pluginverzeichnisses über Secure File Transfer Protocol (SFTP), eine verschlüsselte Methode zur Verwaltung von Websitedateien, oder über den Dateimanager des Hosters eine vollständige Deaktivierung. Die vorübergehende Auswahl eines Standard-Themes kann Störungen auf Theme-Ebene sichtbar machen. Serverzugriffs-, Fehler- und firewall-Protokolle können zeigen, welche Komponente den 401 zurückgegeben und welcher Pfad ihn ausgelöst hat. Der Hosting-Support kann außerdem Staging-Schutz, Edge-Regeln und Einschränkungen prüfen, die innerhalb von WordPress nicht sichtbar sind.
Zeichnen Sie bei Aufrufen der REST API, also Anfragen über eine webbasierte Schnittstelle nach REST-Konventionen, die ausgehende Anfrage auf, ohne ihre geheimen Daten offenzulegen. Bestätigen Sie, dass der Authorization header das Ziel erreicht, insbesondere bei Apache-CGI- oder FastCGI-Konfigurationen und Proxys. Vergleichen Sie die Anfrage aus demselben Netzwerk mit curl, einem Kommandozeilenwerkzeug für Webanfragen. Prüfen Sie, ob Bearer und Basic nicht verwechselt wurden und ob das token weiterhin gültig ist. Ein Fehler, der nach einer Phase erfolgreichen Betriebs regelmäßig wiederkehrt, deutet zunächst auf den Ablauf des tokens hin.
Die WordPress REST API stellt eigene Anforderungen. Cookie-basierte Authentication benötigt für Schreibvorgänge aus externen Kontexten einen gültigen nonce, einen kurzlebigen Wert, mit dem bestätigt wird, dass eine Anfrage aus einer autorisierten Sitzung stammt. Anwendungspasswörter für Server-zu-Server-Anfragen müssen einem Benutzer gehören, dessen Rolle die erforderliche Berechtigung für den endpoint besitzt. Auch der Basispfad muss korrekt sein, da Rewrite-Regeln oder Plugins REST-Routen verschieben können. Wenn eine firewall automatisierten Datenverkehr überprüft, sollte jede Allowlist auf die Adresse der Integration oder eine bestimmte Route beschränkt werden, statt den Schutz global zu lockern. Übermäßig viele Anfragen können durch Rate-Limiting begrenzt werden, wobei dies normalerweise HTTP 429 statt 401 erzeugt.
Die meisten 401-Antworten werden durch die Konfiguration verursacht, doch ein unerklärliches Muster kann eine Sicherheitsuntersuchung rechtfertigen. Zu den Warnzeichen gehören plötzlich ausgesperrte Administratoren, während die öffentliche Website weiterhin funktioniert, eine unerwartete Passwortabfrage des Browsers, gleichzeitige Fehler bei vielen Adressen oder ein Zurücksetzen des Passworts, das den Zugriff nicht wiederherstellt.