HTTP 400 Bad Request : signification et solutions

Ce que signifie cette erreur et comment la reconnaître

• Un navigateur, un client d’API, un moniteur de disponibilité, un émetteur de webhook ou un autre client HTTP signale 400 Bad Request.
• La réponse peut apparaître uniquement pour une URL, une méthode HTTP, une chaîne de requête, un corps de requête, un ensemble d’en-têtes ou un client particulier.
• Le DNS peut résoudre le nom et le TLS peut aboutir, puisque le point de terminaison a renvoyé une réponse HTTP.
• Le corps de la réponse peut afficher une page d’erreur générique ou un message de validation plus précis, selon le composant qui l’a générée.
• Les en-têtes de réponse peuvent révéler l’état du cache, des informations sur le proxy ou le CDN, le contexte d’authentification, des redirections ou des identifiants de requête.
• Une requête qui fonctionnait auparavant peut commencer à renvoyer 400 après un déploiement ou une modification du routage, de la validation, du proxy ou des règles de sécurité.

Causes principales, classées par probabilité

1. Détails de requête mal formés ou invalides : l’URL, la chaîne de requête, les en-têtes, les cookies, la méthode ou le corps de la requête peuvent ne pas respecter le format attendu par le point de terminaison.
2. Règles de validation ou de routage de l’application : l’application peut rejeter des paramètres manquants, de type incorrect, non pris en charge ou incohérents, ou la requête peut cibler une route qui n’accepte pas cette méthode.
3. Traitement par le serveur web, le reverse proxy, le CDN ou le WAF : un intermédiaire peut rejeter la requête avant qu’elle n’atteigne l’application en raison de règles d’analyse, de routage, de filtrage ou de politique.
4. Limites de taille ou de format de la requête : un corps, un ensemble d’en-têtes, une URL, une collection de cookies ou une valeur téléversée peut dépasser une limite propre à l’environnement ou utiliser un format non pris en charge.
5. État lié à l’authentification ou à la session : une application peut utiliser 400 pour un jeton invalide, des données de session mal formées ou une requête qui ne peut pas être associée à l’état attendu. D’autres systèmes utilisent 401 ou 403 pour des problèmes d’accès connexes : vérifiez donc le comportement dans les logs concernés.
6. Modifications récentes de configuration ou de déploiement : la mise à jour des routes, de la logique de validation, de l’authentification, du cache, du proxy, du CDN ou des paramètres de sécurité peut modifier le traitement d’une requête pourtant familière.

Comment corriger le problème

Si vous êtes visiteur ou utilisateur d’une API

1. Réessayez une fois avec l’URL exacte et vérifiez les erreurs de saisie, les espaces involontaires, les paramètres de requête tronqués ou un favori obsolète.
2. Si la requête nécessite un compte, connectez-vous via le processus normal du site, puis réessayez. Ne collez pas de mots de passe, de cookies ou de jetons dans vos demandes d’assistance.
3. Si vous utilisez un client d’API, comparez la méthode HTTP, les paramètres requis, les en-têtes, le type de contenu et le corps de la requête avec les exigences documentées du point de terminaison.
4. Si une requête du navigateur échoue, essayez la même action sans actualiser la page de façon répétée. Des requêtes répétées peuvent augmenter la charge ou interagir avec des limites de débit.
5. Notez l’URL ou le point de terminaison, la méthode, l’heure approximative, le statut de la réponse et tout identifiant de requête affiché dans la réponse. Ne partagez avec le propriétaire du site que des informations assainies.
6. Si l’erreur ne concerne qu’une action, signalez cette action et son comportement attendu. Si de nombreuses pages sans lien apparent échouent, signalez l’étendue du problème plutôt que de supposer que toutes les erreurs ont la même cause.

Si vous possédez ou développez le site

1. Reproduisez le problème au minimum. Notez la méthode HTTP, l’URL complète après suppression des valeurs sensibles, le statut, les en-têtes de réponse, les en-têtes de requête pertinents, le type de contenu et un corps de requête réduit de manière sûre. Vérifiez que le 400 est bien la réponse finale, et non une réponse intermédiaire suivie d’une redirection.
2. Comparez une requête fonctionnelle et une requête en échec. Vérifiez la route, la méthode, les paramètres de requête, le format du corps, le type de contenu, les cookies, l’état d’authentification, le client et la taille de la charge utile. Modifiez une seule variable pertinente à la fois.
3. Identifiez la couche qui répond. Utilisez les en-têtes de réponse, le contenu du corps, les identifiants de requête et les horodatages pour déterminer si la réponse a été produite par l’application, le serveur web, le reverse proxy, le CDN ou le WAF. Les noms et valeurs d’en-têtes dépendent de l’environnement : considérez-les comme des indices, et non comme des preuves.
4. Examinez les logs correspondants. Recherchez dans la couche identifiée et les composants adjacents en utilisant le même horodatage, la même route, la même méthode et le même identifiant de requête. Cherchez des erreurs d’analyse, des échecs de validation, des méthodes rejetées, des dépassements de limites, des incohérences de routage ou des correspondances avec des règles de sécurité.
5. Examinez les modifications récentes. Comparez les déploiements et les changements de configuration qui affectent le routage, l’analyse des requêtes, l’authentification, la mise en cache, la transmission par proxy, le comportement du CDN et les règles du WAF. Vérifiez que la route est censée accepter la requête en échec.
6. Appliquez la correction sûre la plus ciblée. Corrigez le contrat de requête ou la route ou règle précise qui rejette un trafic valide. Évitez les modifications générales de sécurité, d’autorisations, de limites de taille ou de proxy sans autorisation ni tests.
7. Retestez et vérifiez le comportement connexe. Répétez la requête d’origine, puis testez la méthode attendue, une requête invalide représentative et les routes associées. Vérifiez que la correction ne transforme pas des requêtes mal formées en réussites involontaires et ne perturbe pas les redirections, l’authentification, la mise en cache ou les contrôles de sécurité.
8. Conservez les éléments utiles. Gardez les détails de requête assainis, les horodatages, les en-têtes pertinents et les logs conformément à vos pratiques habituelles de conservation et de protection de la vie privée.

Prévention et vérification du correctif

• Définissez et documentez les méthodes, paramètres, types de contenu, exigences d’authentification et limites de taille de requête acceptés pour les routes importantes.
• Validez les requêtes de manière cohérente et renvoyez, lorsque cela est approprié, un message d’erreur utile ne contenant pas d’informations sensibles.
• Soumettez la configuration du routage, du proxy, du CDN, de l’authentification, du cache et du WAF à une gestion des changements.
• Testez des requêtes valides et invalides représentatives après les mises en production de l’application ou de l’infrastructure.
• Surveillez les taux de 400 par route, méthode, client et déploiement afin de distinguer une régression localisée d’un changement étendu.
• Conservez les identifiants de requête et les logs pertinents assez longtemps pour relier une réponse au composant qui l’a produite.
• Masquez les mots de passe, cookies, valeurs d’autorisation, données personnelles et secrets d’API dans les logs et les éléments transmis au support.

Questions fréquentes