Erreur 400 Bad Request : signification et solutions

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

400 Bad Request est un code de statut HTTP qui signifie que le serveur a reçu votre requête mais refuse de la traiter parce que quelque chose dans la requête elle-même semble incorrect. La norme HTTP (RFC 9110, section 15.5.1) la définit comme l'incapacité ou le refus du serveur de traiter une requête « en raison de quelque chose perçu comme une erreur du client », par exemple une syntaxe mal formée, un cadrage de message invalide ou un routage de requête trompeur.

Contrairement à une erreur 500, qui signifie que le serveur a planté, une erreur 400 désigne la requête : l'URL, les en-têtes, les cookies ou les données envoyés par votre navigateur ou votre application. Pour tous les autres visiteurs, le site fonctionne généralement très bien.

C'est une bonne nouvelle pour les visiteurs, car la solution se trouve en général de votre côté et prend une minute : un lien mal saisi ou un cookie corrompu est à l'origine de la plupart des erreurs 400.

À quoi ressemble une erreur 400

Le message dépend du logiciel serveur, et le texte complémentaire est souvent le meilleur indice de la cause :

Quelles sont les causes d'une erreur 400 Bad Request ?

• Une URL mal formée. Un signe % égaré, une espace, un caractère qui aurait dû être encodé, ou un lien tronqué ou collé deux fois.

• Des cookies corrompus ou trop volumineux. Les sites qui déposent de nombreux cookies (connexions, tests A/B, statistiques) peuvent faire dépasser à l'en-tête Cookie la limite du serveur. Un cookie endommagé lors d'une mise à jour peut aussi être rejeté.

• Des en-têtes de requête trop volumineux. En plus des cookies, les longs jetons d'authentification ou les en-têtes ajoutés par des extensions et des proxys s'additionnent.

• Des données invalides envoyées à une API. Champs obligatoires manquants, JSON mal formé ou mauvais en-tête Content-Type.

• Du HTTP envoyé à un port HTTPS. Fréquent derrière les répartiteurs de charge et les reverse proxies.

• Un fichier trop volumineux. Beaucoup de serveurs répondent 413 Content Too Large, mais certaines applications et frameworks renvoient 400 à la place.

Solution 1 : vérifiez l'URL

Examinez attentivement la barre d'adresse. Problèmes à repérer :

• Un % qui n'est pas suivi de deux caractères hexadécimaux (%20 est correct, %2 ou %zz ne l'est pas).

• Des espaces, { }, |, \ ou d'autres caractères inhabituels, surtout dans les liens copiés depuis un e-mail, un PDF ou une messagerie.

• Un lien collé deux fois (https://example.com/https://example.com/...) ou coupé en cours de route.

• Une URL très longue avec des paramètres de suivi. Supprimez tout à partir du ? et réessayez.

Si vous avez suivi un lien depuis un autre site, allez plutôt sur la page d'accueil du site et naviguez jusqu'à la page depuis celle-ci.

Solution 2 : effacez les cookies de ce seul site

Cela corrige la plupart des erreurs 400 sur les sites que vous avez déjà visités, en particulier les messages qui parlent de cookies ou d'en-têtes « too large » ou « too long ». Inutile d'effacer les cookies de tous les sites, seulement ceux de celui-ci :

• Chrome / Edge : cliquez sur l'icône à gauche de la barre d'adresse → Cookies et données de site (ou Paramètres des sites) → supprimez les données du site, puis rechargez la page.

• Firefox : cliquez sur le cadenas → Effacer les cookies et les données de site…

• Safari (Mac) : Safari → Réglages → Confidentialité → Gérer les données de sites web… → recherchez le site → Supprimer.

• iPhone : Réglages → Apps → Safari → Avancé → Données de sites web → balayez le site vers la gauche pour le supprimer.

Solution 3 : essayez la navigation privée, puis videz le cache

Ouvrez la page dans une fenêtre de navigation privée (Ctrl + Maj + N dans Chrome et Edge, Ctrl + Maj + P dans Firefox, Cmd + Maj + N dans Safari). Les fenêtres privées démarrent sans cookies ni extensions : si la page y fonctionne, la solution 2 ou la solution 4 réglera le problème durablement.

Si la navigation privée échoue aussi, videz le cache du navigateur (Ctrl + Maj + Suppr → Images et fichiers en cache) et, en dernier recours, videz votre cache DNS. Le DNS est rarement la cause d'une erreur 400, mais après un changement de serveur d'un site, une adresse obsolète peut vous envoyer vers un serveur qui rejette votre requête.

Solution 4 : désactivez les extensions et vérifiez la taille des fichiers

Les extensions qui modifient les requêtes, comme les outils de confidentialité, les éditeurs d'en-têtes, les chercheurs de codes promo et certains bloqueurs de publicités, peuvent ajouter ou modifier des en-têtes d'une manière que le serveur rejette. Désactivez-les toutes, rechargez la page, puis réactivez-les une par une pour trouver la coupable.

Si l'erreur apparaît lors d'un envoi de fichier, essayez un fichier plus petit. Compressez les images ou découpez les gros fichiers. Cela vous indique si le serveur rejette la taille, même s'il la signale par une erreur 400 au lieu d'une 413.

Pour les propriétaires de sites : trouver la cause des erreurs 400

Si des utilisateurs signalent des erreurs 400 sur votre site, partez du message exact qu'ils voient et de vos logs serveur. nginx et Apache journalisent la raison au niveau info : relevez temporairement le niveau du log d'erreurs si vous ne la voyez pas, et le log d'accès indique quelles URL renvoient 400. L'outil En-têtes HTTP de DNS Robot affiche le code de statut, le logiciel serveur et chaque en-tête Set-Cookie envoyé par une page, ce qui aide à repérer les cookies qui ne cessent de grossir.

# Quelles requêtes reçoivent un 400 ? (format de log nginx combined)
sudo awk '$9 == 400 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# Les raisons journalisées par nginx (nécessite error_log ... info;)
sudo grep -i "client sent\|too large\|bad request" /var/log/nginx/error.log | tail -20

« Request Header Or Cookie Too Large »

nginx lit les en-têtes de requête dans des tampons définis par large_client_header_buffers, par défaut 4 tampons de 8 Ko. Une seule ligne d'en-tête, généralement l'en-tête Cookie, qui ne tient pas dans un tampon déclenche cette erreur 400. La limite équivalente d'Apache est LimitRequestFieldSize, 8 190 octets par défaut.

La bonne solution consiste à envoyer moins : supprimez les cookies dont vous n'avez plus besoin, gardez des cookies de session légers et limitez les cookies aux chemins et sous-domaines qui les utilisent. Si vous avez vraiment besoin d'en-têtes plus volumineux, par exemple pour de gros jetons d'authentification unique (SSO), relevez la limite :

# nginx (bloc http ou server)
large_client_header_buffers 4 16k;

# Équivalent Apache (httpd.conf / vhost)
# LimitRequestFieldSize 16380

« The plain HTTP request was sent to HTTPS port »

nginx renvoie cette erreur 400 quand quelque chose envoie du HTTP en clair à un port sur lequel nginx attend du TLS, généralement le 443. Les causes typiques sont un répartiteur de charge ou un proxy qui transfère du trafic http:// vers le port 443, un lien du type http://example.com:443, ou un ancien réglage ssl on; qui fait attendre du TLS à un port qui ne devrait pas.

Vérifiez que chaque ligne listen correspond à ce qui arrive dessus : listen 443 ssl; pour le HTTPS et listen 80; pour le HTTP en clair, avec une redirection du 80 vers le 443. Assurez-vous aussi que le proxy placé devant parle HTTPS au port 443 (ou HTTP au port 80).

Erreurs 400 renvoyées par les API

Les API utilisent le code 400 pour les requêtes qui échouent à la validation. Si vous appelez une API, lisez le corps de la réponse, car la plupart des API indiquent quel champ est incorrect. Vérifiez ensuite que vous envoyez un JSON valide, le bon en-tête Content-Type: application/json et tous les paramètres obligatoires.

Si vous développez une API, renvoyez un corps qui nomme le problème (par exemple {"error": "email is required"}), et envisagez 422 Unprocessable Content pour les requêtes bien formées mais sémantiquement invalides, en réservant 400 aux requêtes impossibles à analyser.

400 vs 401, 403, 404, 413, 429 et 431

Nos guides sur les codes voisins : 403 Forbidden, 401 Unauthorized et 429 Too Many Requests. Pour les redirections qui tournent en boucle au lieu d'échouer, consultez ERR_TOO_MANY_REDIRECTS, et le Vérificateur de redirections affiche chaque étape.