Limites de taille des requêtes : durcir l'analyse du corps pour prévenir les DoS

Pourquoi les requêtes surdimensionnées posent un vrai problème

Les requêtes trop volumineuses semblent souvent inoffensives jusqu'à ce qu'elles mettent une application à genoux. Un seul upload massif, un gros blob JSON ou une requête coincée dans une boucle de retry peut consommer la mémoire et le CPU, ralentir tout le monde, et parfois planter le serveur.

Quelques termes simples :

• Payload : les données envoyées par le client.
• Corps (Body) : où ces données résident dans une requête HTTP (par exemple JSON ou un fichier).
• Parseur : le code (ou la librairie) qui lit le corps et le transforme en quelque chose que votre appli peut utiliser, comme un objet, une chaîne ou un fichier enregistré.

Le risque n'est pas seulement « des hackers ». Beaucoup d'incidents sont accidentels : un bug mobile qui envoie une requête de 50 Mo, un frontend qui base64-encode une image dans du JSON, ou une intégration qui continue d'ajouter des champs jusqu'à ce que le corps devienne massif. Le résultat peut ressembler à un déni de service même si personne n'avait de mauvaise intention.

Bien sûr, cette faiblesse est facile à abuser. Si votre serveur accepte des bodies illimités, un attaquant peut envoyer des requêtes très volumineuses (ou beaucoup de moyennes) et forcer un parsing coûteux. Cela peut priver votre appli de mémoire, remplir des disques et bloquer le trafic légitime.

Les limites de taille importent, mais ce n'est pas « régler et oublier ». Des limites trop basses cassent de vrais utilisateurs (surtout pour les uploads). Des limites trop hautes laissent toujours place à des pics mémoire. L'objectif est un défaut sûr, avec des exceptions claires pour les quelques endpoints qui ont réellement besoin de corps plus grands.

Ce qui peut mal se passer quand vous acceptez de gros payloads

Accepter « tout ce que le client envoie » est une façon rapide de transformer un endpoint en source d'indisponibilité. Sans limites de taille, un seul POST surdimensionné peut pousser votre appli en forte consommation mémoire, temps de réponse longs et pannes en cascade.

Le premier impact est souvent la mémoire. Beaucoup de frameworks bufferisent tout le corps avant que votre handler ne s'exécute. Un gros payload JSON ou un upload multipart peut être copié plusieurs fois pendant le buffering, le décodage et la validation. Cela multiplie le coût mémoire, et il ne faut pas beaucoup de requêtes concurrentes pour épuiser un conteneur ou une VM.

Le CPU est le problème suivant. Parser un JSON immense coûte cher, et des objets profondément imbriqués peuvent aggraver la situation. Même si le payload est « valide », le serveur peut passer des secondes à transformer des octets en objets, laissant moins de CPU pour le vrai travail. Certains parseurs effectuent du travail supplémentaire sur de grandes entrées (coercition, validation), ce qui augmente le coût par requête.

Les corps surdimensionnés occupent aussi des workers. Un upload lent maintient une connexion ouverte, occupant un thread worker ou la boucle d'événements et repoussant les autres utilisateurs vers des timeouts. Sous charge, les retries s'accumulent et amplifient les dégâts.

Les uploads peuvent aussi endommager silencieusement votre disque. Si des fichiers temporaires atterrissent au mauvais endroit (ou ne sont jamais nettoyés), une rafale de grosses requêtes peut remplir le disque et faire planter des parties non liées de l'application.

Les équipes sous-estiment souvent les coûts « secondaires » : pics de bande passante et factures cloud (surtout quand les clients retentent), files d'attente en arrière-plan plus lentes à cause de la pression CPU/mémoire, logs bruyants, et angles morts parce que certaines erreurs surviennent avant même que le code applicatif ne s'exécute. Un autre souci fréquent est de faire les vérifications d'authentification après avoir déjà parsé le corps, ce qui rend l'abus moins coûteux.

Un scénario réaliste : un endpoint d'inscription accepte du JSON avec un champ « profile ». Un client buggy envoie un blob de 50 Mo. Le serveur le bufferise, le parse, et se bloque. Ajoutez quelques autres en parallèle et le service devient non réactif.

Où appliquer les limites pour qu'elles soient efficaces

Les limites de taille les plus fiables sont appliquées à plusieurs niveaux. Si vous ne définissez une limite que dans l'app, le serveur peut quand même passer du temps et de la mémoire à lire un corps géant avant que votre code ne le rejette. Si vous ne mettez une limite qu'à la périphérie, vous voudrez peut-être des contrôles plus stricts pour certains endpoints.

1) Couche edge : arrêter les requêtes surdimensionnées avant qu'elles n'atteignent l'app

Votre première ligne de défense doit être la couche qui reçoit le trafic en premier, comme un CDN, un load balancer, un reverse proxy ou une API gateway. C'est là que vous pouvez rejeter les bodies surdimensionnés tôt, renvoyer un HTTP 413 et éviter d'occuper les workers de l'app. Cela aide aussi contre les uploads lents et volumineux qui visent à maintenir des connexions ouvertes.

Gardez la limite edge stricte pour le trafic général. Si vous avez besoin d'uploads plus gros, gérez-les via un chemin/service séparé plutôt que d'augmenter la limite pour tout le monde.

2) Couche application : ajouter des limites par endpoint et des valeurs par défaut plus sûres

Dans l'application, appliquez à nouveau des limites pour que chaque endpoint ait le plafond approprié. Un endpoint de login doit accepter un petit JSON. Un endpoint de photo de profil peut accepter plus.

Un schéma pratique est d'avoir une petite taille maximale globale pour la plupart des routes API, avec des plafonds par route pour les exceptions. Les endpoints publics doivent être plus stricts que ceux authentifiés. Rejetez tôt quand c'est possible (vérifier Content-Length quand il est présent), et utilisez des timeouts pour la lecture du corps, pas seulement pour le traitement.

Les uploads méritent un traitement spécial. Considérez les uploads de fichiers comme un flux différent des API JSON classiques, car les uploads peuvent déclencher de gros pics mémoire si un parseur bufferise tout. Privilégiez le streaming ou le traitement par morceaux, écrivez sur disque ou stockage objet, et validez le type et la taille du fichier avant de faire des opérations coûteuses.

Comment choisir des limites sûres sans casser les utilisateurs

Commencez par lister chaque endpoint qui accepte un corps. Les limites ne sont sûres que si elles correspondent à l'usage réel. La façon la plus rapide d'y parvenir est d'inventorier ce que vous acceptez réellement, pas ce que vous supposez accepter.

Regroupez les endpoints selon ce qu'ils doivent recevoir. Les APIs JSON ont généralement les plafonds les plus petits. Les formulaires sont au milieu. Les uploads de fichiers nécessitent des limites plus hautes. Les webhooks peuvent vous surprendre avec des rafales occasionnelles.

Un point de départ pratique est de définir des valeurs par défaut strictes et d'augmenter les limites seulement lorsqu'il y a une raison claire. Par exemple :

• Endpoints JSON : 16 KB à 256 KB
• Formulaires (sans fichiers) : 64 KB à 512 KB
• Uploads de fichiers : 5 MB à 25 MB (seulement sur des routes spécifiques)
• Webhooks : 256 KB à 2 MB (selon la doc et les logs du fournisseur)

Ces chiffres ne sont pas universels, mais le schéma compte : la plupart des routes doivent rester petites, et seules quelques-unes doivent être autorisées à être grandes.

Quand vous choisissez un plafond, souvenez-vous que vous limitez plus que les « données utilisateur ». Headers, cookies et délimiteurs multipart ajoutent de l'overhead. Le base64 gonfle aussi le contenu d'environ un tiers. Une image de 2 MB insérée dans du JSON peut arriver proche de 2,7 MB avant que votre application n'ait commencé le traitement.

Planifiez les exceptions de manière explicite. Si un endpoint a réellement besoin de 25 MB, donnez 25 MB uniquement à cet endpoint et laissez le défaut bas, plutôt que d'affecter toute l'application avec « illimité ». Notez qui utilise l'exception, ce qu'ils envoient et quelle est une limite raisonnable.

Un signe courant est un endpoint générique unique (comme /api/save) qui accepte n'importe quoi. Le séparer en un petit endpoint JSON et un endpoint upload souvent stoppe les pics mémoire soudains sans nuire aux utilisateurs normaux.

Règles d'analyse du corps qui réduisent les pics mémoire et CPU

La façon la plus rapide de déclencher des pics est de laisser votre appli deviner ce que contient le corps, puis le parser automatiquement. Durcir l'analyse du corps signifie être strict : n'acceptez que ce que vous attendez, et ne parsez que lorsque c'est vraiment nécessaire.

Commencez par une allowlist de Content-Types par endpoint. Si un endpoint est censé recevoir du JSON, acceptez seulement application/json (et les variantes exactes que vous supportez). Si le Content-Type est manquant ou inconnu sur un endpoint qui attend un body, rejetez tôt. Cela évite des parsings accidentels de gros textes, des encodages étranges ou des entrées qui font trop travailler votre parseur.

Mettre des garde-fous sur le parsing JSON

Si votre framework le permet, plafonnez la complexité JSON, pas seulement la taille. Une petite requête peut être coûteuse si elle est profondément imbriquée ou a des milliers de clés.

Bons défauts à considérer :

• Profondeur JSON max (exemple : 20 à 50 niveaux)
• Nombre maximal de champs (exemple : 1 000 à 10 000 clés)
• Longueur maximale des chaînes pour les champs individuels (exemple : 10 KB à 100 KB)
• Gestion UTF-8 stricte (rejeter les séquences invalides)
• Échouer rapidement sur les clés dupliquées (si supporté)

Ensuite, désactivez le parsing automatique sur les routes qui n'en ont pas besoin. Beaucoup d'apps parsent le JSON globalement pour chaque requête, y compris les checks de santé, les endpoints de vérification de webhook et les routes GET simples. C'est du travail inutile et une cible facile.

Pour les uploads, préférez le streaming (traiter par morceaux) plutôt que de lire le fichier entier en mémoire avant de l'écrire sur disque ou stockage objet. Combinez le streaming avec des limites de taille pour qu'une seule requête ne puisse pas remplir la RAM.

Exemple : un endpoint d'inscription attend un petit JSON. Si le serveur accepte n'importe quel Content-Type et parse automatiquement, un attaquant peut envoyer un payload de plusieurs mégaoctets avec une structure complexe qui paralyse le CPU. Des règles strictes sur le Content-Type et des plafonds de profondeur/champs transforment cela en un rejet rapide au lieu d'une panne.

Étapes : ajouter des limites et durcir l'analyse

La plupart des pannes liées aux requêtes surdimensionnées touchent des endpoints faciles d'accès : formulaires publics, APIs non authentifiées et webhooks. Commencez par lister chaque route qui accepte un body, puis marquez celles qui sont publiques, celles appelées par des tiers et celles qui acceptent des fichiers.

Checklist pratique

Commencez par la périphérie (load balancer, reverse proxy, CDN ou API gateway). Les contrôles edge sont votre première ligne de défense parce qu'ils bloquent la requête avant que votre appli ne dépense de la mémoire à la parser.

• Identifiez les endpoints à haut risque (publics, non authentifiés, webhooks, uploads).
• Définissez des plafonds edge : taille maximale du body, taille maximale des headers et un timeout de lecture court.
• Ajoutez des exceptions par chemin uniquement si vous pouvez les justifier (par ex. une route d'upload).
• Assurez-vous que le edge renvoie HTTP 413 pour les bodies qui dépassent la limite.
• Confirmez que la limite est réellement appliquée (certaines stacks bufferisent avant de rejeter).

Puis verrouillez côté application. Les limites côté app vous protègent lorsque le trafic contourne le edge (appels internes, mauvaise config) et vous permettent d'être plus précis qu'un plafond global unique.

• Appliquez des limites de taille par route et par Content-Type (JSON vs multipart upload).
• Réglez les defaults du parseur : taille JSON max, profondeur maximale et parsing strict (rejeter le JSON invalide ; rejeter les clés dupliquées si possible).
• Évitez de parser en mémoire quand vous pouvez : streamez les uploads et validez type/taille tôt.
• Testez des requêtes normales et volontairement surdimensionnées, y compris les bodies compressés si vous les acceptez.
• Surveillez les logs pour les 413 et les timeouts de lecture pendant une semaine, puis ajustez seulement pour des besoins avérés.

Un cas concret : un endpoint de webhook acceptait du JSON sans plafond. Un payload surdimensionné a suffi à augmenter la mémoire et redémarrer le service. Une petite limite JSON par route sur le webhook (tout en autorisant des limites plus grandes seulement sur les routes authentifiées d'upload) empêche le pic sans casser le trafic normal.

Gestion des échecs : sûre et conviviale

Une fois que vous imposez des limites, la question suivante est : que voit le client quand il dépasse la limite ? Une bonne gestion d'échec arrête l'attaque (ou l'accident) tôt, mais indique aussi au véritable utilisateur comment corriger la requête.

Utilisez des codes qui correspondent au problème. Un payload trop grand doit retourner 413 Payload Too Large. Un body que vous n'acceptez pas (par ex. envoyer du XML à un endpoint JSON-only) doit retourner 415 Unsupported Media Type. Si la requête est malformée, 400 Bad Request suffit généralement. Un message d'erreur approprié aide les clients à éviter des retries aveugles.

Gardez les messages courts et pratiques. Indiquez ce qu'il faut changer : « Fichier trop volumineux. Max 10 MB. » ou « Seul application/json est supporté. » N'échoez pas les bodies ni les headers dans la réponse pour réduire le risque de fuite de secrets.

Pour le logging, vous voulez assez de contexte pour déboguer sans stocker le payload rejeté. Un bon compromis : logger l'endpoint et la méthode, le code de statut (413, 415), le Content-Length observé (si fourni) et la limite configurée, le Content-Type, plus un ID de requête et l'ID utilisateur/compte si connu.

Décidez où échouer rapidement par endpoint. Pour des endpoints d'upload publics et des routes d'authentification, échouer au niveau edge évite à l'app tout travail. Pour des endpoints où les limites dépendent de règles propres à la route, l'app devra décider, mais elle doit toujours rejeter avant de parser le corps complet.

Erreurs fréquentes qui entraînent des pannes ou des DoS faciles

La plupart des pannes liées aux requêtes volumineuses ne viennent pas d'« aucune limite ». Elles surviennent quand des limites existent mais sont inégales, contournées, ou appliquées trop tard pour protéger la mémoire.

Un pattern fréquent est de fixer un plafond global unique et de penser que c'est suffisant. Puis une route d'upload, un webhook ou une exception de reverse proxy permet discrètement des bodies beaucoup plus grands. Les attaquants n'ont pas besoin de viser votre API principale, seulement la route faible.

Erreurs récurrentes :

• Limiter les bodies JSON mais oublier les uploads et webhooks (ou définir une tier séparée à « illimité »).
• Augmenter les limites « juste pour aujourd'hui » pour débloquer un client, puis ne jamais revenir en arrière.
• Parser d'abord le corps et vérifier la taille après. Quand vous rejetez, vous avez déjà payé le coût mémoire/CPU.
• Accepter n'importe quel Content-Type et laisser les bibliothèques deviner le parsing, ce qui peut déclencher des chemins de parsing lents ou une décompression inattendue.
• Autoriser des fichiers base64 dans du JSON sans plafonds stricts, de sorte qu'un « fichier de 10 MB » gonfle en transit et en mémoire.

Un autre piège est de bloquer de vrais utilisateurs parce que les limites n'ont jamais été testées. Les clients mobiles peuvent envoyer des headers plus gros. Les webhooks partenaires peuvent inclure des métadonnées verbeuses. Si vous devinez un nombre et le déployez, vous l'apprendrez pendant une période de forte charge.

Mieux vaut tester les limites avec vos vrais clients avant de les faire respecter strictement. Collectez quelques payloads représentatifs (petit, typique, pire cas), définissez des limites avec une marge, et gardez les messages d'erreur clairs.

Vérifications rapides en 15 minutes

Vous n'avez pas besoin d'un projet de sécurité complet pour réduire rapidement le risque. Un passage rapide sur les limites et les paramètres de parsing peut empêcher des pics mémoire soudains et des attaques faciles par DoS.

Contrôle de configuration en 15 minutes

Commencez par la périphérie (load balancer, CDN, reverse proxy ou API gateway). Si elle accepte de gros bodies, votre appli n'aura peut-être jamais la chance de se protéger. Puis examinez vos routes applicatives.

• Confirmez qu'il existe un plafond dur au edge et qu'il est réellement appliqué (testez avec une requête qui le dépasse).
• Choisissez 3 à 5 endpoints qui acceptent des bodies et inscrivez leurs tailles maximales prévues.
• Ajoutez une allowlist Content-Type simple pour les endpoints qui acceptent un body.
• Vérifiez vos réglages de parseur JSON pour une taille max et plafonnez la profondeur ou la complexité si le framework le permet.
• Pour les uploads, évitez de bufferiser tout le fichier en mémoire. Utilisez le streaming ou un flux d'upload dédié.

Test d'échec en 5 minutes

Assurez-vous que l'app échoue de façon sûre et prévisible, avec des réponses claires et des entrées visibles dans les logs et la supervision.

Testez ces réponses de bout en bout :

• HTTP 413 quand le payload est trop grand (et la connexion est fermée proprement).
• HTTP 415 quand le Content-Type n'est pas autorisé.
• Timeouts qui coupent les uploads lents et sans fin.
• Une même IP bruyante ne peut pas déclencher à répétition des parsings coûteux.

Exemple : stopper un pic mémoire réel depuis un seul endpoint

Un endpoint d'inscription public semblait correct en test, puis a commencé à tomber en timeout lors d'un pic de trafic. Le CPU a augmenté, la mémoire a bondi et l'app redémarrait toutes les quelques minutes. Cela ressemblait à « trop d'utilisateurs », mais les logs montraient autre chose : un petit nombre de requêtes prenaient beaucoup plus de temps que les autres.

La cause cachée était la forme du payload, pas seulement le nombre. Des attaquants (et quelques clients buggy) envoyaient des JSON surdimensionnés et des objets profondément imbriqués. Même quand la requête était finalement rejetée par la validation, le serveur avait déjà dépensé du temps et de la mémoire à la lire et à la parser. Quelques-unes de ces requêtes suffisaient à pousser le processus en thrash de GC puis en OOM.

La correction a été simple : limites de taille et règles de parsing plus strictes, appliquées avant la logique applicative.

Ce qui a changé

Nous avons resserré l'endpoint d'inscription pour qu'il n'accepte que ce dont il a besoin :

• Petite taille maximale du body pour les requêtes JSON
• Profondeur maximale pour les objets JSON
• Vérification stricte du Content-Type (seulement JSON)
• Timeouts courts pour la lecture du corps
• Réponses HTTP 413 claires avec un message bref

Après cela, le même pic de trafic n'a plus provoqué de redémarrages. La mémoire est restée stable parce que les gros bodies n'ont jamais atteint le parseur JSON, et les payloads profondément imbriqués étaient rejetés rapidement. Les logs sont aussi devenus plus propres : au lieu de longues traces, on voyait des entrées courtes et cohérentes comme « Payload too large » ou « JSON too deep ».

Pour les vrais utilisateurs, presque rien n'a changé. Les inscriptions normales fonctionnaient toujours. La seule différence visible était que les clients cassés recevaient une erreur claire et rapide au lieu d'une requête qui tournait et d'un timeout générique.

Prochaines étapes et quand demander de l'aide

Avant de changer quoi que ce soit, obtenez un rapide état des lieux de ce que vous protégez. Cela vous aide à éviter de casser des vrais utilisateurs tout en fermant les chemins DoS les plus simples.

Collectez :

• La liste des endpoints qui acceptent des bodies (JSON, forms, uploads)
• Vos limites actuelles de taille (par endpoint et au proxy/serveur)
• Les logs récents pour les 413, timeouts, pics mémoire et requêtes lentes
• Des notes sur qui utilise chaque endpoint et les tailles de payload typiques
• Les jobs en arrière-plan qui postent de gros payloads en interne

Ensuite, déployez les changements dans l'ordre le plus sûr : routes publiques d'abord, puis récepteurs de webhook, puis tout endpoint qui parse du JSON non fiable. Gardez les limites serrées sur ces routes et assouplissez-les seulement si vous avez un besoin utilisateur clair et un flux de parsing sûr.

Après déploiement, empêchez les limites de dériver vers le haut. Sauvegardez quelques requêtes représentatives (une normale, une proche de la limite, une clairement surdimensionnée) et exécutez-les après chaque release pour confirmer le rejet rapide, la gestion correcte du HTTP 413 et la stabilité mémoire/CPU.

Si vous avez hérité d'une base de code générée par IA, un audit ciblé vaut le coup pour repérer des defaults dangereux comme des parseurs avec body illimité, des endpoints d'upload sans plafond et des vérifications d'entrée faibles. FixMyMess (fixmymess.ai) se spécialise dans le diagnostic et la réparation d'applications générées par IA, y compris le resserrement des limites de requête, la correction des chemins de parsing qui bufferisent en mémoire et le renforcement des problèmes de sécurité connexes. Ils proposent aussi un audit gratuit pour identifier les problèmes avant de vous engager dans des changements.