400 Bad Request : ce que ça signifie et comment le corriger

Ce que signifie 400 Bad Request

La RFC 9110 définit le 400 comme la façon dont le serveur dit que la requête n'a pas pu être comprise à cause d'une syntaxe mal formée. Le mot clé est syntaxe : le serveur n'évalue pas qui vous êtes, ce que vous avez le droit de faire, ni si la ressource existe. Il dit que la requête elle-même, en tant qu'octets sur le fil, ne s'analyse pas comme une requête HTTP valide. Cela peut concerner la ligne de requête, les en-têtes ou le corps, selon l'endroit où l'analyseur abandonne.

Comment l'erreur apparaît

Les navigateurs affichent la page d'erreur simple que le serveur renvoie pour un 400 ; il n'existe pas de page dédiée au niveau du navigateur comme pour un échec DNS ou de certificat, puisque la connexion a réussi et qu'une réponse est bien arrivée. Une variante courante affiche exactement « 400 Bad Request - request header or cookie too large », qui nomme directement la cause. Depuis la ligne de commande :

curl -I https://example.com/some/path
HTTP/1.1 400 Bad Request
Content-Type: text/html

Les journaux du serveur sont la preuve la plus utile ici, car contrairement à un échec de handshake TLS, la requête a bien atteint la couche applicative et est journalisée, souvent avec l'en-tête ou la ligne précise qui a échoué à l'analyse.

Ce qui provoque un 400 Bad Request

Pour un visiteur, dans l'ordre où vous êtes le plus susceptible de les rencontrer :

• Des cookies surdimensionnés ou corrompus. Des années de cookies accumulés pour un domaine, ou un cookie abîmé par une extension ou une redirection défaillante, produisent régulièrement exactement le message « 400 Bad Request - request header or cookie too large » une fois que la taille totale des en-têtes dépasse la limite du serveur.
• Une URL mal saisie ou mal encodée. Un caractère parasite, un espace non encodé, ou une séquence d'encodage pourcent cassée dans la barre d'adresse ou un lien collé peut échouer à s'analyser comme une syntaxe valide.
• Une extension de navigateur qui modifie les requêtes. Les bloqueurs de publicité, les outils de confidentialité et certaines extensions VPN réécrivent les en-têtes ou la ligne de requête, et un bug dans l'un d'eux peut envoyer au serveur quelque chose de mal formé.
• Une redirection mise en cache pointant vers une URL cassée. Le navigateur suit une redirection obsolète vers une URL elle-même invalide, et le 400 apparaît sur la destination, pas sur le lien que vous avez réellement cliqué.
• Un envoi de fichier plus volumineux que ce que le serveur autorise. Certaines configurations de serveur répondent à un envoi surdimensionné par 400 plutôt que par le 413 Payload Too Large, plus précis.

Pour le propriétaire du site, à peu près dans l'ordre où il vaut la peine de vérifier en premier :

• Des limites de taille d'en-tête ou de cookie fixées trop bas pour ce que l'application envoie réellement, surtout après l'ajout de cookies de suivi, de JWT dans les en-têtes, ou d'un mécanisme de session qui grossit avec le temps.
• Un en-tête Host invalide ou manquant, que peut produire un reverse proxy ou un client mal configuré, et que la plupart des serveurs exigent pour router la requête du tout.
• Un Content-Length qui ne correspond pas au corps réellement envoyé, que peut causer un client défaillant ou un proxy intermédiaire bogué.
• Des règles de pare-feu applicatif (WAF) ou ModSecurity qui rejettent une requête dont la syntaxe paraît correcte à un humain mais qui correspond à un motif défensif que le WAF traite comme mal formé.
• Une API qui rejette délibérément un JSON mal formé avec 400. Ce cas est un comportement correct, pas un bug : un corps de requête qui échoue à s'analyser comme JSON valide, ou auquel manque un champ requis que l'API valide au niveau syntaxique, doit renvoyer 400 par conception.

Comment savoir de qui vient la faute

Reproduisez la même requête depuis un environnement propre : une fenêtre de navigation privée sans extension ni cookies accumulés, ou un simple appel curl vers la même URL. Si la requête propre réussit, la cause était locale, le plus souvent des cookies ou une extension. Si elle échoue à l'identique depuis un client propre et depuis un tout autre endroit, ce sont les propres limites ou règles du serveur qui rejettent une requête légitimement formée, et le moyen le plus rapide de le confirmer à grande échelle est de lancer une vérification HTTP depuis plusieurs emplacements à la fois et de comparer le code de statut que chacun renvoie.

Comment corriger un 400 Bad Request

Si vous êtes visiteur

1. Videz d'abord les cookies du site, puisque des cookies surdimensionnés ou corrompus en sont de loin la cause la plus courante. La plupart des navigateurs permettent de vider les cookies d'un seul site sans effacer toutes les autres connexions.
2. Réessayez dans une fenêtre privée ou incognito. Une fenêtre propre n'a aucun cookie accumulé et, selon le navigateur, désactive la plupart des extensions par défaut, ce qui isole les deux causes courantes à la fois.
3. Vérifiez l'URL à la recherche de fautes de frappe ou de caractères parasites, surtout après avoir collé un lien provenant d'un endroit qui a pu ajouter des paramètres de suivi ou casser l'encodage.
4. Désactivez les extensions une par une si l'erreur persiste dans une fenêtre normale mais pas en navigation privée, pour trouver laquelle réécrit la requête.
5. Essayez un autre appareil ou un autre réseau pour écarter un portail captif ou un proxy local qui n'a rien à voir avec le site.

Si vous gérez le site

1. Augmentez les limites d'en-tête et de tampon si l'application en a réellement besoin de plus grandes. Sur nginx :

   large_client_header_buffers 4 16k;

   Sur Apache :

   LimitRequestFieldSize 16384

   Sur IIS, vérifiez à la fois maxRequestLength dans web.config pour le corps de la requête et le paramètre de registre HTTP.sys MaxFieldLength pour les champs d'en-tête individuels.
2. Réduisez ce que vous envoyez réellement dans les cookies et les en-têtes plutôt que de seulement relever le plafond. Élaguer les cookies obsolètes, déplacer les jetons volumineux hors des en-têtes et fixer des durées de vie de cookie plus courtes évite que le problème ne se reproduise à mesure que l'usage grandit.
3. Vérifiez la gestion de l'en-tête Host au niveau du reverse proxy ou de l'équilibreur de charge, et confirmez qu'il transmet à l'application une valeur valide et attendue.
4. Lisez les journaux du WAF ou de ModSecurity pour identifier la règle précise qui s'est déclenchée, s'il y en a un devant l'application ; un faux positif là-bas a besoin d'une exception ciblée, pas d'un jeu de règles désactivé.
5. Confirmez qu'un 400 renvoyé par votre API est intentionnel avant de le « corriger ». Un corps JSON mal formé ou un champ qui échoue à la validation au niveau syntaxique doit renvoyer 400 ; la correction dans ce cas, ce sont des messages d'erreur côté client plus clairs, pas un changement du code de statut.

400 face aux codes similaires

• 401 Unauthorized signifie que la requête a été parfaitement comprise, mais que des identifiants valides manquent ou ont été rejetés.
• 403 Forbidden signifie que la requête a été parfaitement comprise, mais que le serveur refuse de l'autoriser quels que soient les identifiants.
• 404 Not Found signifie que la requête a été parfaitement comprise et qu'aucune ressource ne correspondait au chemin.
• 413 Payload Too Large est le code spécifique pour un corps qui dépasse une limite de taille, même si certains serveurs répondent 400 à la place en pratique.
• 414 URI Too Long est le code spécifique pour une ligne de requête qui dépasse une limite de longueur.
• 422 Unprocessable Content signifie que la syntaxe s'est bien analysée mais que la sémantique non, par exemple un JSON valide avec une valeur qui échoue à une validation métier, une distinction plus fine que ce que la plupart des API prennent la peine de faire par rapport au 400.

Comment éviter qu'une erreur 400 ne fasse tomber une page

Un 400 introduit par un déploiement qui a resserré les limites d'en-tête, ou une mise à jour de règle WAF qui commence à correspondre à du trafic légitime, ne se manifestera pas comme un plantage ou un timeout, puisque le serveur répond instantanément et correctement selon ses propres règles. Une vérification HTTP programmée avec une assertion sur le code de statut attendu détecte cela dès que ça commence à se produire, plutôt que d'attendre que les tickets de support s'accumulent. Combinée à une surveillance depuis plusieurs emplacements, elle indique aussi si le 400 est universel ou lié à la configuration de bordure d'une seule région.

Erreurs associées

La famille plus large des codes d'erreur client et serveur est couverte dans l'aperçu des codes 4xx. Voir aussi 403 Forbidden pour les requêtes que le serveur a comprises et refusées, 404 Not Found pour les requêtes visant une ressource qui n'existe pas, et 429 Too Many Requests pour les requêtes rejetées à cause d'un débit plutôt que d'une syntaxe.

Questions fréquentes

Pourquoi vider les cookies corrige-t-il une erreur 400 ?

Parce que les cookies voyagent en tant qu'en-têtes de requête à chaque requête, et qu'un serveur impose une taille totale d'en-tête maximale. Des années de cookies accumulés, ou un seul cookie corrompu, peuvent pousser le total au-delà de cette limite, et le serveur répond 400 avant même de lire quoi que ce soit d'autre sur la requête.

Une erreur 400 est-elle la même sur tous les sites que je visite ?

Le code et la cause générale, une syntaxe de requête mal formée, sont les mêmes partout, mais la limite exacte qui a été franchie et le libellé exact de la page d'erreur sont fixés par la configuration serveur propre à chaque site.

Mon API doit-elle renvoyer 400 pour une entrée invalide ?

Oui, quand l'entrée échoue à s'analyser ou qu'il lui manque un champ que l'API vérifie au niveau syntaxique. C'est le 400 qui fonctionne comme prévu, pas un bug à corriger en assouplissant la validation.

Un WAF peut-il provoquer une erreur 400 sur une requête qui paraît parfaitement normale ?

Oui. Une règle WAF peut signaler un motif dans une URL, un en-tête ou un corps qui est techniquement du HTTP valide mais qui correspond à une signature défensive, et certaines configurations de WAF répondent par un 400 générique plutôt que par une page de blocage plus précise.

Quelle est la différence entre 400 et 413 ?

413 est le code spécifique pour un corps de requête qui dépasse une limite de taille configurée. Beaucoup de serveurs l'utilisent correctement, mais certains répondent 400 à la place pour la même condition de corps surdimensionné, donc ne présumez pas que le code seul vous indique la cause exacte sans vérifier la documentation ou les journaux propres au serveur.