HTTP 400 Bad Request: Bedeutung und Fehlerbehebung

Was dieser Fehler bedeutet und wie du ihn erkennst

• Ein Browser, API-Client, Uptime-Monitor, Webhook-Absender oder anderer HTTP-Client meldet 400 Bad Request.
• Die Response kann nur für eine bestimmte URL, HTTP-Methode, Query-Zeichenfolge, einen Request-Body, einen bestimmten Header-Satz oder einen bestimmten Client auftreten.
• DNS kann aufgelöst werden und TLS kann erfolgreich abgeschlossen werden, weil der Endpunkt eine HTTP-Response zurückgegeben hat.
• Der Response-Body kann eine allgemeine Fehlerseite oder – abhängig von der erzeugenden Komponente – eine spezifischere Validierungsmeldung enthalten.
• Response-Header können den Cache-Status, Proxy- oder CDN-Informationen, den Authentifizierungskontext, Weiterleitungen oder Request-IDs offenlegen.
• Eine zuvor funktionierende Anfrage kann nach einem Deployment oder einer Änderung an Routing, Validierung, Proxy oder Sicherheitsregeln plötzlich 400 zurückgeben.

Hauptursachen nach Wahrscheinlichkeit

1. Fehlerhafte oder ungültige Anfragedetails: URL, Query-Zeichenfolge, Header, Cookies, Methode oder Request-Body entsprechen möglicherweise nicht dem vom Endpunkt erwarteten Format.
2. Anwendungsvalidierung oder Routing-Regeln: Die Anwendung kann fehlende, falsch typisierte, nicht unterstützte oder widersprüchliche Parameter ablehnen. Möglich ist auch, dass die Anfrage an eine Route gerichtet ist, die diese Methode nicht akzeptiert.
3. Verarbeitung durch Webserver, Reverse Proxy, CDN oder WAF: Ein Vermittler kann die Anfrage aufgrund von Parsing-, Routing-, Filter- oder Richtlinienregeln ablehnen, bevor sie die Anwendung erreicht.
4. Größen- oder Formatlimits für Anfragen: Ein Body, ein Header-Satz, eine URL, eine Cookie-Sammlung oder ein hochgeladener Wert kann ein umgebungsspezifisches Limit überschreiten oder ein nicht unterstütztes Format verwenden.
5. Authentifizierungs- oder sitzungsbezogener Anfragezustand: Eine Anwendung kann 400 für ein ungültiges Token, fehlerhafte Sitzungsdaten oder eine Anfrage verwenden, die nicht dem erwarteten Zustand zugeordnet werden kann. Andere Systeme verwenden für verwandte Zugriffsprobleme 401 oder 403. Prüfen Sie daher das Verhalten in den relevanten Logs.
6. Kürzliche Konfigurations- oder Deployment-Änderungen: Aktualisierte Routen, Validierungslogik, Authentifizierung, Caching-, Proxy-, CDN- oder Sicherheitseinstellungen können ändern, wie eine ansonsten vertraute Anfrage verarbeitet wird.

So behebst du den Fehler

Wenn Sie Besucher oder API-Nutzer sind

1. Wiederholen Sie die genaue URL einmal und achten Sie auf Tippfehler, unbeabsichtigte Leerzeichen, abgeschnittene Query-Parameter oder ein veraltetes Lesezeichen.
2. Wenn die Anfrage ein Konto erfordert, melden Sie sich über den normalen Prozess der Website an und versuchen Sie es erneut. Fügen Sie Passwörter, Cookies oder Tokens niemals Supportanfragen bei.
3. Wenn Sie einen API-Client verwenden, vergleichen Sie HTTP-Methode, erforderliche Parameter, Header, Content-Type und Request-Body mit den dokumentierten Anforderungen des Endpunkts.
4. Wenn eine Browseranfrage fehlschlägt, führen Sie dieselbe Aktion aus, ohne die Seite wiederholt zu aktualisieren. Wiederholte Anfragen können zusätzliche Last erzeugen oder mit Rate-Limits interagieren.
5. Notieren Sie URL oder Endpunkt, Methode, ungefähren Zeitpunkt, Response-Status und jede in der Response angezeigte Request-ID. Teilen Sie dem Websitebetreiber nur bereinigte Details mit.
6. Wenn der Fehler nur eine Aktion betrifft, melden Sie diese Aktion und das erwartete Verhalten. Wenn viele voneinander unabhängige Seiten fehlschlagen, schildern Sie den größeren Umfang, statt anzunehmen, dass jeder Fehler dieselbe Ursache hat.

Wenn Sie die Website betreiben oder entwickeln

1. Erstellen Sie eine minimale Reproduktion. Notieren Sie HTTP-Methode, vollständige URL mit entfernten vertraulichen Werten, Status, Response-Header, relevante Request-Header, Content-Type und einen sicher minimierten Request-Body. Bestätigen Sie, dass 400 die endgültige Response ist und nicht eine Zwischen-Response, auf die eine Weiterleitung folgt.
2. Vergleichen Sie eine funktionierende und eine fehlschlagende Anfrage. Prüfen Sie Route, Methode, Query-Parameter, Body-Format, Content-Type, Cookies, Authentifizierungsstatus, Client und Payload-Größe. Ändern Sie jeweils nur eine relevante Variable.
3. Ermitteln Sie die antwortende Schicht. Verwenden Sie Response-Header, Formulierungen im Body, Request-IDs und Zeitstempel, um festzustellen, ob Anwendung, Webserver, Reverse Proxy, CDN oder WAF die Response erzeugt hat. Headernamen und -werte sind umgebungsspezifisch und sollten daher als Hinweise, nicht als Beweis betrachtet werden.
4. Untersuchen Sie die passenden Logs. Durchsuchen Sie die ermittelte Schicht und angrenzende Komponenten anhand desselben Zeitstempels, derselben Route und Methode sowie der Request-ID. Achten Sie auf Parserfehler, Validierungsfehler, abgelehnte Methoden, Limitüberschreitungen, Routing-Abweichungen oder Treffer von Sicherheitsregeln.
5. Prüfen Sie kürzliche Änderungen. Vergleichen Sie Deployments und Konfigurationsänderungen an Routing, Request-Parsing, Authentifizierung, Caching, Proxy-Weiterleitung, CDN-Verhalten und WAF-Regeln. Prüfen Sie, ob die fehlschlagende Anfrage von der Route erwartungsgemäß akzeptiert werden sollte.
6. Nehmen Sie die kleinste sichere Korrektur vor. Korrigieren Sie den Anfragevertrag oder genau die Route beziehungsweise Regel, die gültigen Datenverkehr ablehnt. Vermeiden Sie umfassende Änderungen an Sicherheit, Berechtigungen, Größenlimits oder Proxys ohne Autorisierung und Tests.
7. Testen Sie erneut und prüfen Sie benachbartes Verhalten. Wiederholen Sie die ursprüngliche Anfrage und testen Sie anschließend die vorgesehene Methode, eine repräsentative ungültige Anfrage sowie verwandte Routen. Stellen Sie sicher, dass die Korrektur fehlerhafte Anfragen nicht unbeabsichtigt erfolgreich macht und Weiterleitungen, Authentifizierung, Caching oder Sicherheitskontrollen nicht beeinträchtigt.
8. Bewahren Sie nützliche Belege auf. Speichern Sie bereinigte Anfragedetails, Zeitstempel, relevante Header und Logs gemäß Ihren üblichen Aufbewahrungs- und Datenschutzvorgaben.

Vorbeugung und Überprüfung der Lösung

• Definieren und dokumentieren Sie für wichtige Routen akzeptierte Methoden, Parameter, Content-Types, Authentifizierungsanforderungen und Größenlimits für Anfragen.
• Validieren Sie Anfragen konsistent und geben Sie, sofern angemessen, eine hilfreiche, nicht vertrauliche Fehlermeldung zurück.
• Unterstellen Sie Routing-, Proxy-, CDN-, Authentifizierungs-, Caching- und WAF-Konfigurationen einer Änderungskontrolle.
• Testen Sie nach Anwendungs- oder Infrastruktur-Releases repräsentative gültige und ungültige Anfragen.
• Überwachen Sie 400-Raten nach Route, Methode, Client und Deployment, damit sich eine lokal begrenzte Regression von einer umfassenden Änderung unterscheiden lässt.
• Bewahren Sie Request-IDs und relevante Logs lange genug auf, um eine Response der Komponente zuordnen zu können, die sie erzeugt hat.
• Entfernen oder maskieren Sie Passwörter, Cookies, Autorisierungswerte, personenbezogene Daten und API-Secrets in Logs und Supportbelegen.

Häufig gestellte Fragen