HTTP 401 error bedeutet, dass die Website-Authentication fehlgeschlagen ist
Ein HTTP 401 error ist ein Statuscode des Hypertext Transfer Protocol, der besagt, dass ein Server eine Anfrage empfangen und verstanden, aber keine akzeptablen Anmeldedaten erhalten hat. Das Passwort, application password, der API key oder access token kann fehlen, fehlerhaft formatiert, abgelaufen, widerrufen oder falsch sein. Obwohl die offizielle Bezeichnung „Unauthorized“ lautet, ist die praktische Bedeutung in der Regel „unauthenticated“: Der Server kann nicht feststellen, wer die Anfrage stellt. Im Vergleich dazu bedeutet eine 403-Antwort, dass der Server den Zugriff verweigert, obwohl die Identität bekannt oder unerheblich ist.
Eine korrekte 401-Antwort sollte einen WWW-Authenticate header enthalten, also Antwortinformationen, die die erwartete Authentication-Methode wie Basic oder Bearer angeben. Basic authentication sendet codierte Anmeldedaten mit der Anfrage, während Bearer authentication einen access token verwendet. Browser können darauf reagieren, indem sie einen Dialog zur Eingabe von Anmeldedaten öffnen. Websites können stattdessen eine leere Seite oder Meldungen wie „Authorization Required“ oder „Access denied due to invalid credentials“ anzeigen. Anwendungen protokollieren den Fehler normalerweise in ihren Logs und erhalten einen JSON- oder XML-Fehlerinhalt statt einer sichtbaren Seite.
Die Folgen hängen von der betroffenen Adresse ab. Besucher können nicht fortfahren, öffentliche Seiten können für Suchmaschinen-Crawler unzugänglich werden und an Sichtbarkeit in Suchergebnissen verlieren, solange der Fehler besteht, und ein blockierter Login- oder Admin-Pfad kann den Websitebetreiber daran hindern, Reparaturen vorzunehmen. Ein absichtlicher Schutz von Staging-, Administrations- und API-Pfaden ist normal. Problematisch sind der unbeabsichtigte Schutz öffentlicher Inhalte oder ein unerwarteter Fehler, der berechtigte Nutzer betrifft.
Zu den häufigsten Ursachen gehören Anmeldedaten, die geändert, deaktiviert, rotiert wurden oder ablaufen durften. Auch eine veraltete Login-Session kann dazu führen, dass ein authentifizierter Nutzer als anonym erscheint. Dies kann nach einem Domainwechsel, einem Wechsel zwischen www- und non-www-Adressen, einer HTTP-to-HTTPS-Migration oder der Neuerzeugung von Session-Keys durch ein Plugin auftreten. Security-, Membership-, Caching- und single sign-on plugins können miteinander in Konflikt geraten, wenn mehr als eine Komponente den Login oder die REST authorization steuert. Manchmal sind davon nur bestimmte Nutzerrollen oder endpoints betroffen.
Authentication kann auch durch den Webserver vorgeschrieben werden. Apache verwendet üblicherweise eine .htaccess-Konfigurationsdatei und eine .htpasswd-Passwortdatei, während Nginx einen auth_basic-Block verwenden kann. Eine verschobene Passwortdatei, ein nicht lesbares Format für gespeicherte Passwörter, restriktive Dateiberechtigungen oder ein versehentlich in die Produktionsumgebung übernommener Staging-Schutz können alle absichtlich eine 401-Antwort auslösen. Ein reverse proxy, der Anfragen an die Website weiterleitet, oder ein Content Delivery Network (CDN), das Inhalte über verteilte Systeme bereitstellt, kann den Authorization header entfernen, eine geschützte Antwort im Cache speichern oder eine übersehene Zugriffsregel anwenden. Geschützte Seiten in Kombination mit aggressivem Caching können sporadische Fehler verursachen, die sich nur schwer reproduzieren lassen.
Das Troubleshooting sollte mit den am wenigsten störenden Prüfungen beginnen. Öffnen Sie die Entwicklertools des Browsers, untersuchen Sie die fehlgeschlagene Anfrage im Network tab und überprüfen Sie, ob die Antwort tatsächlich 401 und nicht 403, 419 oder einen anderen Code zeigt. Notieren Sie die response headers, insbesondere WWW-Authenticate. Testen Sie dieselbe Adresse in einem privaten Fenster und in einem anderen Browser. Falls sie dort funktioniert, löschen Sie die Cookies und Website-Daten für die Domain, gegebenenfalls einschließlich der www- und non-www-Varianten, und melden Sie sich erneut an. Prüfen Sie, ob der Fehler die gesamte Website, nur /wp-admin/ oder eine einzelne API route betrifft.
Setzen Sie anschließend gezielt die betroffenen Anmeldedaten zurück, indem Sie das Passwort ändern, den API key oder das application password neu erzeugen oder einen neuen token ausstellen. Überprüfen Sie Apache-Direktiven wie AuthType, AuthUserFile und Require oder den entsprechenden auth_basic-Block von Nginx. Vergewissern Sie sich, dass die Passwortdatei vorhanden und lesbar ist. Nach dem Erstellen eines Backups können Sie den Block vorübergehend deaktivieren, um festzustellen, ob die Authentication auf Serverebene verantwortlich ist.
Leeren Sie jeden relevanten Cache, einschließlich Browser-Cache, WordPress caching plugin, server cache, object cache, der häufig wiederverwendete Datenbankergebnisse speichert, und CDN. Testen Sie nach Möglichkeit den hosting origin ohne Proxy, CDN oder firewall. Wenn der Fehler nur über die zwischengeschaltete Komponente auftritt, deutet dies auf deren Zugriffsregeln, gespeicherte Antworten oder Verarbeitung von headers hin.
Plugins sollten systematisch getestet werden. Deaktivieren Sie alle Plugins, prüfen Sie, ob der Zugriff wiederhergestellt ist, und aktivieren Sie sie anschließend einzeln wieder, bis der Fehler erneut auftritt. Falls das WordPress-Dashboard nicht zugänglich ist, kann das Plugin-Verzeichnis über SFTP, eine sichere Methode zur Übertragung von Website-Dateien, oder über den file manager des Hostinganbieters umbenannt werden, um eine Deaktivierung aller Plugins zu erzwingen. Benennen Sie es zurück, bevor Sie jedes Plugin testen. Die vorübergehende Verwendung eines default theme kann Störungen auf Theme-Ebene aufdecken. Serverzugriffs-Logs, Fehler-Logs und firewall-Logs können anschließend erkennen lassen, welche Komponente die Antwort erzeugt hat und welcher Pfad betroffen war. Der Hosting-Support kann möglicherweise auch Staging-Schutz, Edge-Einschränkungen oder Challenges erkennen, die innerhalb von WordPress nicht sichtbar sind.
Untersuchen Sie bei einer REST API, einer Schnittstelle, über die Anwendungen Anfragen und Daten austauschen, die tatsächlich gesendete Anfrage und entfernen Sie dabei vertrauliche Daten aus den Logs. Vergewissern Sie sich, dass der Authorization header den Server erreicht, da Proxies und manche Apache-CGI- oder FastCGI-Konfigurationen ihn verwerfen können. Vergleichen Sie die Anfrage mit curl aus demselben Netzwerk. Basic- und Bearer-Schemata sind nicht austauschbar, und die WWW-Authenticate-Antwort gibt an, was der endpoint erwartet. Tokens können außerdem ablaufen oder widerrufen werden. Bei einer Verbindung, die in regelmäßigen Abständen nicht mehr funktioniert, sollte daher zuerst das Ablaufdatum geprüft werden.
Die Cookie-basierte REST authentication von WordPress erfordert für Schreibvorgänge aus externen Kontexten eine gültige nonce, einen kurzlebigen Wert, mit dem überprüft wird, ob eine Website-Anfrage beabsichtigt ist. Angemeldet zu sein reicht nicht aus. Application passwords werden normalerweise für server-to-server requests verwendet, müssen jedoch zu einem Nutzer gehören, dessen Rolle über die vom endpoint benötigte capability verfügt. Prüfen Sie auch den base REST path, da rewrites oder Plugins routes verschieben können. Firewall-Regeln können automatisierte Aufrufe von Admin- oder API-Pfaden mit einer Challenge versehen. Nur die Adresse oder route der Integration auf eine Allowlist zu setzen, ist sicherer, als eine Regel global zu lockern. Übermäßig viele Anfragen führen normalerweise zu 429 statt 401.
Die meisten 401-Fehler sind Konfigurationsprobleme, doch ein unerklärliches Muster kann eine Sicherheitsuntersuchung rechtfertigen. Zu den Warnzeichen gehören Administratoren, die plötzlich den Zugriff verlieren, während die öffentliche Website weiterhin funktioniert, ein Dialog zur Eingabe von Anmeldedaten auf einem Pfad, der nie geschützt war, Fehler, die sich über viele Adressen ausbreiten, oder ein Zurücksetzen des Passworts, das den Zugriff nicht wiederherstellt. Eingeschleuster Code in einem Theme, Plugin oder must-use plugin, das WordPress automatisch lädt, kann die Authentication verändern, den Login-Handler ersetzen oder eine weitere Zugriffsprüfung erzwingen. Eine unvollständige Entfernung von Malware kann ebenfalls Authentication-Hooks zurücklassen, während ein unbefugt eingerichteter Verzeichnisschutz darauf abzielen kann, berechtigte Administratoren vom Zugang zum foothold eines Angreifers auszuschließen.
Betrachten Sie einen 401-Fehler allein nicht als Beweis für eine Kompromittierung.