Déni de service : consommation de ressources, formulaires web et API

Les vulnérabilités de déni de service applicatif (AppDoS) diffèrent des attaques volumétriques réseau. Elles ne nécessitent pas un grand volume de trafic : quelques requêtes soigneusement construites peuvent épuiser le CPU, la mémoire, les connexions à la base de données ou le stockage d'un serveur. L'impact est la rendre l'application indisponible pour les utilisateurs légitimes.

Consommation incontrôlée de ressources

Certaines opérations sont intrinsèquement coûteuses et peuvent être déclenchées par des données malveillantes. ReDoS (Regular Expression Denial of Service) : des expressions régulières vulnérables à des entrées provoquant un backtracking exponentiel. Billion Laughs XML : entités XML imbriquées qui s'expandent exponentiellement en mémoire. Zip bomb : archive compressée dont le contenu décompressé dépasse des gigaoctets. Hash DoS : envoi de nombreuses clés JSON qui produisent des collisions de hash dans la table de hachage du serveur.

Exemple de ReDoS : expression régulière vulnérable

// Expression vulnérable : groupes imbriqués avec quantificateurs
const re = /^(a+)+$/;

// Pour l'entrée 'aaaaaaaaaaaaaaab', le backtracking est exponentiel
console.time();
re.test('aaaaaaaaaaaaaaab');  // Peut durer des secondes ou minutes
console.timeEnd();

// Utiliser un moteur de regex sans backtracking (RE2) :
const RE2 = require('re2');
const re2 = new RE2('^(a+)+$');
re2.test('aaaaaaaaaaaaaaab');  // Temps linéaire garanti

Absence de rate limiting sur les formulaires

Un formulaire web sans limitation du taux de soumission peut être utilisé pour épuiser les ressources du serveur ou les services tiers. Formulaire d'inscription : envoi de milliers d'emails de confirmation, saturation de la base de données. Formulaire de contact : saturation de la boîte email et du service d'envoi. Formulaire de recherche : requêtes SQL lourdes répétées en continu. Formulaire d'upload : saturation du stockage.

Rate limiting par IP (Express.js / express-rate-limit)

const rateLimit = require('express-rate-limit');

// Limiter les soumissions de formulaire de contact
const contactLimiter = rateLimit({
  windowMs: 60 * 60 * 1000,  // 1 heure
  max: 5,                     // 5 soumissions par heure par IP
  message: 'Trop de messages envoyés. Réessayez dans une heure.',
  standardHeaders: true,
  legacyHeaders: false,
});

app.post('/contact', contactLimiter, handleContact);

Restrictions inadéquates des ressources système

Les opérations sans limites explicites peuvent épuiser les ressources du serveur. Taille maximale des fichiers uploadés : sans limite, un attaquant peut saturer le disque avec un seul upload. Résultats de recherche sans pagination : une requête qui retourne des millions de lignes sature la mémoire. Traitement d'images sans limite : une image de grande taille décompressée consomme une quantité mémoire excessive. Timeout des opérations longues : une requête qui dure plusieurs minutes monopolise un thread.

Déni de service sur API

Les APIs GraphQL sont particulièrement exposées aux attaques de DoS par requêtes complexes. Une requête GraphQL peut demander des données avec de nombreuses imbrications et des listes, générant des milliers de requêtes SQL. La limite de profondeur des requêtes et la limite du coût de calcul (query cost analysis) sont des protections spécifiques à GraphQL. Pour les APIs REST, le rate limiting par endpoint et par utilisateur est la protection de base.