Erreur 400 Bad Request : 6 solutions pour la corriger

Une page qui refuse de se charger, avec un message « Bad Request » à l’écran : c’est l’erreur 400, l’un des codes d’erreur HTTP les plus fréquents. Le serveur signale ainsi que la requête envoyée par le navigateur est incorrecte ou mal formée. Elle touche aussi bien le développeur qui débogue une API que l’internaute qui tombe dessus en pleine navigation, sans rien comprendre à ce qui bloque. Derrière un simple écran blanc se cachent des causes très différentes, du cookie corrompu au pare-feu applicatif un peu trop nerveux.

Qu’est-ce que l’erreur 400 Bad Request ?

Le code HTTP 400 « Bad Request » apparaît quand le serveur ne parvient pas à traiter la demande, parce que sa syntaxe ne correspond pas à ce qu’il attend. Peu importe le navigateur : Chrome, Firefox ou Edge donnent le même résultat, puisque la vérification se fait côté serveur, pas côté client. La norme HTTP place cette erreur tôt dans le cycle de traitement, dès la réception de la requête, avant même que le serveur ne s’occupe du contenu ou de la logique métier. La documentation MDN sur le code 400, alignée sur la RFC 9110, décrit la même mécanique : syntaxe invalide, message mal formé ou routage trompeur.

Le message d’erreur n’indique presque jamais la cause précise. Il faut donc creuser. Caractères illégaux dans la requête, taille qui dépasse une limite fixée côté serveur, en-tête manquant : chaque cas se traite différemment, et deviner ne mène nulle part. Une inspection méthodique, requête par requête, reste le seul moyen d’aller vite.

Quels sont les principaux déclencheurs de l’erreur 400 ?

Plusieurs facteurs techniques provoquent une erreur 400. Le cas le plus fréquent : une URL mal saisie ou contenant des caractères non supportés par le protocole HTTP. Viennent ensuite les problèmes de taille, cookies trop volumineux, paramètres GET/POST mal structurés, ou requête qui dépasse la limite fixée par le serveur web.

Certaines extensions de navigateur ajoutent aussi des en-têtes que le serveur ne sait pas interpréter. Même chose avec les proxys, les VPN ou des configurations réseau complexes : le risque grimpe si les paquets sont modifiés en cours de route, sans que l’utilisateur s’en rende compte. Un antivirus qui inspecte le trafic HTTPS en profondeur produit parfois le même effet.

Erreurs de syntaxe et données corrompues

C’est souvent la structure de la requête HTTP elle-même qui pose problème. Un copier-coller d’URL avec des espaces ou des caractères réservés (%, &, <, >) suffit à créer un conflit ; un caractère accentué mal encodé dans un paramètre GET produit le même type de blocage. Un cookie corrompu produit un effet comparable, en pire : l’erreur revient à chaque visite du site, tant que le cookie n’est pas supprimé manuellement.

Un exemple concret aide à visualiser le problème. Une URL du type exemple.com/page?text=bonjour%%20monde contient un double caractère % invalide : l’espace, normalement encodé en %20, tombe ici sur une séquence que le serveur ne sait pas décoder, d’où le rejet immédiat. Les caractères {, $, [ ou | dans une URL produisent le même effet. Autre variante fréquente : le message précis « Request Header Or Cookie Too Large », renvoyé quand les cookies ou en-têtes dépassent la limite du serveur. Certains serveurs répondent alors 431 plutôt que 400 ; les deux codes signalent un problème voisin, mais 431 cible spécifiquement la taille des en-têtes, quand 400 reste plus générique.

Les API tombent dans le même piège lors des échanges entre serveurs ou applications. Une donnée manquante, un encodage incorrect ou un en-tête de sécurité absent, et la transaction échoue immédiatement avec un retour « bad request ».

Limitations serveur et filtrages applicatifs

Certains serveurs web imposent des règles strictes sur la longueur des éléments d’une requête : chemin d’URL, corps, valeurs de paramètres. Un formulaire trop rempli qui dépasse ces limites déclenche automatiquement une erreur 400, avant même que le code applicatif n’entre en jeu. La limite tourne le plus souvent autour de 8 Ko pour la taille cumulée des en-têtes et cookies, avec une directive précise selon le serveur : large_client_header_buffers sur Nginx, LimitRequestFieldSize sur Apache. Un cookie de session trop chargé, ou l’empilement de plusieurs cookies tiers, suffit à dépasser ce seuil.

Les mécanismes de filtrage applicatif ou de protection anti-attaque changent parfois la donne. Un serveur qui détecte une activité suspecte, bot, tentative d’injection, en-tête falsifié, répond souvent par une erreur 400 pour couper court avant que ça n’aille plus loin.

Comment diagnostiquer et résoudre efficacement une erreur 400 ?

Trouver la cause d’une erreur 400 demande souvent plusieurs vérifications, côté client comme côté serveur. Premier réflexe pour l’internaute : vider le cache et les cookies du navigateur. Ça suffit dans une bonne partie des cas. Retaper l’adresse à la main dans la barre du navigateur élimine aussi les fautes de frappe ou les caractères parasites qui traînent après un copier-coller.

Pour une application ou un service précis, tester depuis un autre terminal ou un autre réseau aide à savoir si le problème vient de la machine locale. Une commande simple comme curl -v sur l’URL en question révèle souvent l’en-tête ou le paramètre fautif en quelques secondes, sans installer quoi que ce soit. Désactiver temporairement plugins, proxy ou VPN élimine aussi les interférences logicielles qui pourraient être en cause.

Étapes server-side et outils de journalisation

Côté administrateur système, les logs du serveur restent la première source d’information : ils révèlent les schémas qui reviennent à chaque rejet et précisent souvent quel champ, paramètre ou composant fait échouer la requête.

Des outils comme ngrok, Fiddler ou Charles Proxy servent à intercepter la transaction HTTP complète et à l’examiner ligne par ligne, en-têtes compris. Utile pour accélérer un diagnostic qui traîne depuis plusieurs heures sans piste sérieuse.

Réinitialiser ou adapter la configuration

Quand des règles de pare-feu applicatif (WAF) ou des modules tiers ont ajouté des restrictions personnalisées, comme sur Cloudflare ou avec mod_security, ajuster ou lever certains filtres se justifie, une fois la vérification faite. Désactiver le plugin problématique ou augmenter la taille maximale des requêtes acceptées aide à isoler la source réelle du problème.

Les services tiers qui exposent une API publique imposent souvent leurs propres règles anti-abus. Suivre leur documentation officielle à la lettre reste le seul moyen fiable de faire passer la requête sans accroc, plutôt que de multiplier les essais au hasard.

Comparatif des méthodes de résolution courantes

Voici un tableau récapitulatif des correctifs pour l’erreur 400, côté utilisateur et côté serveur, avec leur efficacité observée en pratique.

Où situer l’erreur 400 face aux autres codes HTTP ?

L’erreur 400 Bad Request fait partie d’une famille plus large de codes qui signalent des anomalies de communication sur le Web. La 404, par comparaison, indique juste que la ressource cherchée n’existe pas ; la 401 pointe un problème d’authentification. Les codes 403 et 451 couvrent respectivement les accès interdits et les contenus censurés.

Ce qui distingue le code 400, c’est le moment où il intervient : juste après la réception de la requête, avant tout traitement métier ou décision d’acheminement. C’est un problème de forme, pas d’autorisation ni de disponibilité : la requête doit respecter la structure attendue par le protocole, point final.