{"id":257,"date":"2026-06-19T16:28:11","date_gmt":"2026-06-19T16:28:11","guid":{"rendered":"https:\/\/shattered.io\/fr\/2026\/06\/19\/validation-donnees-nodejs\/"},"modified":"2026-06-19T16:29:36","modified_gmt":"2026-06-19T16:29:36","slug":"validation-donnees-nodejs","status":"publish","type":"post","link":"https:\/\/shattered.io\/fr\/2026\/06\/19\/validation-donnees-nodejs\/","title":{"rendered":"Validation des Donn\u00e9es dans Node.js avec express-validator : 12 \u00c9tapes, 30 Min [2026]"},"content":{"rendered":"\n

En juin 2026, l’ANSSI a \u00e9mis un avis d’urgence sur des vuln\u00e9rabilit\u00e9s critiques dans Node.js 22.x et 20.x, dont plusieurs exploitables via des entr\u00e9es non valid\u00e9es. Node.js a \u00e9galement d\u00e9ploy\u00e9 des correctifs de s\u00e9curit\u00e9 le 17 juin 2026 pour les branches 26.x, 24.x et 22.x. R\u00e9sultat : la validation des donn\u00e9es reste le premier rempart contre les attaques par injection, XSS et d\u00e9ni de service dans toute application Node.js. Ce tutoriel couvre la mise en place compl\u00e8te d’une cha\u00eene de validation avec express-validator 7<\/strong>, Joi 17<\/strong> et Zod 3<\/strong>, en 12 \u00e9tapes et 30 minutes.<\/p>\n\n\n\n

Pr\u00e9requis et versions<\/h2>\n\n\n\n

Avant de commencer, v\u00e9rifiez que votre environnement correspond aux versions suivantes. Les exemples de ce tutoriel ont \u00e9t\u00e9 test\u00e9s sous Node.js 24.x LTS, sorti en 2026, et Express 5.x, qui apporte une gestion native des promesses dans les middlewares.<\/p>\n\n\n\n

Outil<\/th>Version minimale<\/th>R\u00f4le<\/th><\/tr><\/thead>
Node.js<\/td>22.x LTS<\/td>Runtime JavaScript c\u00f4t\u00e9 serveur<\/td><\/tr>
npm<\/td>10+<\/td>Gestionnaire de paquets<\/td><\/tr>
Express<\/td>5.x<\/td>Framework web HTTP<\/td><\/tr>
express-validator<\/td>7.x<\/td>Validation et sanitisation des entr\u00e9es<\/td><\/tr>
Joi<\/td>17.x<\/td>Validation par sch\u00e9ma d\u00e9claratif<\/td><\/tr>
Zod<\/td>3.x<\/td>Validation type-safe TypeScript\/JS<\/td><\/tr>
express-mongo-sanitize<\/td>2.x<\/td>Pr\u00e9vention injection NoSQL<\/td><\/tr>
DOMPurify + jsdom<\/td>3.x + 24.x<\/td>Sanitisation HTML c\u00f4t\u00e9 serveur<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Connaissance pr\u00e9alable requise : JavaScript ES2022+, les fondamentaux d’Express (routes, middlewares), et une compr\u00e9hension de base des concepts HTTP (requ\u00eates POST, corps JSON). Si vous d\u00e9butez avec la s\u00e9curit\u00e9 Node.js, lisez d’abord notre article sur l’OWASP Top 10 Node.js<\/a> pour un panorama des risques \u00e0 couvrir.<\/p>\n\n\n\n

Pourquoi la validation des donn\u00e9es Node.js est critique en 2026<\/h2>\n\n\n\n

La validation des entr\u00e9es est le premier rempart contre une large cat\u00e9gorie d’attaques : injection SQL, injection NoSQL, XSS stock\u00e9, d\u00e9bordement de m\u00e9moire par des payloads g\u00e9ants, et contournement de r\u00e8gles m\u00e9tier. Sans validation robuste, n’importe quel champ de formulaire devient une surface d’attaque.<\/p>\n\n\n\n

Selon l’OWASP, les d\u00e9fauts de validation d’entr\u00e9es alimentent directement les cat\u00e9gories A03 (Injection) et A07 (Identification failures) du Top 10 2025. En pratique, un champ email<\/code> non valid\u00e9 dans une requ\u00eate MongoDB peut retourner l’int\u00e9gralit\u00e9 de la base si l’op\u00e9rateur $where<\/code> n’est pas bloqu\u00e9. Une valeur age<\/code> accept\u00e9e sans contr\u00f4le de type peut provoquer une erreur non g\u00e9r\u00e9e qui expose la stack trace au client.<\/p>\n\n\n\n

Node.js traite nativement les corps de requ\u00eate comme des cha\u00eenes ou des objets JSON bruts. Express ne valide rien par d\u00e9faut. Toute la logique de contr\u00f4le doit donc \u00eatre construite dans l’application, couche par couche. Les trois approches compl\u00e9mentaires couvertes ici sont : express-validator<\/strong> pour les validations par champ sur les routes Express, Joi<\/strong> pour les sch\u00e9mas complexes orient\u00e9s objet, et Zod<\/strong> pour les projets TypeScript ou ceux qui veulent une inf\u00e9rence de type automatique.<\/p>\n\n\n\n

L’ANSSI recommande depuis mars 2026 d’appliquer les correctifs Node.js dans les 48 heures suivant leur publication, notamment parce que plusieurs CVE r\u00e9centes touchent le parsing des en-t\u00eates HTTP et le traitement de payloads malform\u00e9s. La validation applicative est le filet de s\u00e9curit\u00e9 qui intercepte les donn\u00e9es malveillantes avant qu’elles n’atteignent la couche base de donn\u00e9es. Node.js a corrig\u00e9 huit vuln\u00e9rabilit\u00e9s en janvier 2026, dont trois class\u00e9es critiques, et a publi\u00e9 de nouvelles mises \u00e0 jour de s\u00e9curit\u00e9 le 17 juin 2026 pour les branches 26.x, 24.x et 22.x.<\/p>\n\n\n\n

\u00c9tape 1 : Initialiser le projet et installer les d\u00e9pendances<\/h2>\n\n\n\n

Cr\u00e9ez un nouveau dossier de projet, initialisez npm et installez toutes les biblioth\u00e8ques de validation en une seule commande. Utilisez l’option --save-exact<\/code> pour \u00e9viter les mises \u00e0 jour de version non voulues en production.<\/p>\n\n\n\n

mkdir node-validation-demo && cd node-validation-demo\nnpm init -y\nnpm install --save-exact \\\n  express@5 \\\n  express-validator@7 \\\n  joi@17 \\\n  zod@3 \\\n  express-mongo-sanitize@2 \\\n  dompurify@3 \\\n  jsdom@24 \\\n  multer@1 \\\n  helmet@8<\/code><\/pre>\n\n\n\n
Une fois l’installation termin\u00e9e, v\u00e9rifiez les versions install\u00e9es avec npm list --depth=0<\/code>. Votre package.json<\/code> doit lister express 5.x et express-validator 7.x. Cr\u00e9ez ensuite la structure de fichiers suivante pour ce tutoriel :<\/p>\n\n\n\n
node-validation-demo\/\n\u251c\u2500\u2500 src\/\n\u2502   \u251c\u2500\u2500 app.js                   # Point d'entr\u00e9e Express\n\u2502   \u251c\u2500\u2500 validators\/\n\u2502   \u2502   \u251c\u2500\u2500 user.validator.js    # R\u00e8gles express-validator\n\u2502   \u2502   \u251c\u2500\u2500 user.schema.joi.js   # Sch\u00e9ma Joi\n\u2502   \u2502   \u2514\u2500\u2500 user.schema.zod.js   # Sch\u00e9ma Zod\n\u2502   \u251c\u2500\u2500 middlewares\/\n\u2502   \u2502   \u251c\u2500\u2500 validate.js          # Middleware centralis\u00e9 express-validator\n\u2502   \u2502   \u251c\u2500\u2500 validate-schema.js   # Factory Joi \/ Zod\n\u2502   \u2502   \u251c\u2500\u2500 sanitize-html.js     # Sanitisation XSS avec DOMPurify\n\u2502   \u2502   \u2514\u2500\u2500 upload.js            # Configuration Multer s\u00e9curis\u00e9e\n\u2502   \u2514\u2500\u2500 routes\/\n\u2502       \u2514\u2500\u2500 user.routes.js       # Routes Express\n\u251c\u2500\u2500 uploads\/                     # Dossier pour les fichiers upload\u00e9s\n\u2514\u2500\u2500 package.json<\/code><\/pre>\n\n\n\n
Cette structure s\u00e9pare clairement les responsabilit\u00e9s : les fichiers validators\/<\/code> d\u00e9finissent les r\u00e8gles, les fichiers middlewares\/<\/code> les appliquent et g\u00e8rent les erreurs, et les routes assemblent les deux. Cette s\u00e9paration facilite les tests unitaires et la r\u00e9utilisation des r\u00e8gles entre plusieurs routes.<\/p>\n\n\n\n
\u00c9tape 2 : Configurer Express avec les middlewares de s\u00e9curit\u00e9 de base<\/h2>\n\n\n\n
Avant m\u00eame d’ajouter la validation m\u00e9tier, configurez Express avec les middlewares de s\u00e9curit\u00e9 essentiels. Helmet configure automatiquement 15 en-t\u00eates HTTP de s\u00e9curit\u00e9 en une seule ligne. La limite de taille du corps JSON \u00e0 10 Ko prot\u00e8ge contre les attaques par d\u00e9ni de service via des payloads surdimensionn\u00e9s.<\/p>\n\n\n\n
\/\/ src\/app.js\nconst express = require('express');\nconst helmet = require('helmet');\nconst mongoSanitize = require('express-mongo-sanitize');\n\nconst app = express();\n\n\/\/ En-t\u00eates de s\u00e9curit\u00e9 HTTP (CSP, HSTS, X-Frame-Options, etc.)\napp.use(helmet());\n\n\/\/ Parser JSON avec limite de taille stricte\napp.use(express.json({ limit: '10kb' }));\napp.use(express.urlencoded({ extended: true, limit: '10kb' }));\n\n\/\/ Supprime les op\u00e9rateurs MongoDB des entr\u00e9es ($where, $gt, $regex, etc.)\napp.use(mongoSanitize({\n  replaceWith: '_',\n  onSanitize: ({ req, key }) => {\n    console.warn(`[S\u00c9CURIT\u00c9] Tentative d'injection NoSQL bloqu\u00e9e : champ \"${key}\"`);\n  }\n}));\n\nconst userRoutes = require('.\/routes\/user.routes');\napp.use('\/api\/users', userRoutes);\n\nmodule.exports = app;<\/code><\/pre>\n\n\n\n
La ligne express.json({ limit: '10kb' })<\/code> est fondamentale. Sans limite, un attaquant peut envoyer un payload JSON de plusieurs centaines de m\u00e9gaoctets pour saturer la m\u00e9moire du processus Node.js. Helmet configure notamment l’en-t\u00eate X-Content-Type-Options: nosniff<\/code>, qui emp\u00eache le navigateur d’interpr\u00e9ter des r\u00e9ponses JSON comme du HTML ex\u00e9cutable. Pour une configuration compl\u00e8te de Helmet, consultez notre guide sur les en-t\u00eates de s\u00e9curit\u00e9 HTTP en Node.js<\/a>.<\/p>\n\n\n\n
\u00c9tape 3 : Valider les champs simples avec express-validator<\/h2>\n\n\n\n
express-validator est la biblioth\u00e8que de validation la plus utilis\u00e9e dans l’\u00e9cosyst\u00e8me Express, avec plus de 25 millions de t\u00e9l\u00e9chargements hebdomadaires sur npm. Sa version 7 introduit une API enti\u00e8rement bas\u00e9e sur les promesses et une meilleure prise en charge des middlewares asynchrones d’Express 5.<\/p>\n\n\n\n
Cr\u00e9ez le fichier de r\u00e8gles de validation pour l’inscription d’un utilisateur :<\/p>\n\n\n\n
\/\/ src\/validators\/user.validator.js\nconst { body } = require('express-validator');\n\nconst registerValidation = [\n  body('email')\n    .isEmail()\n    .withMessage('Adresse e-mail invalide')\n    .normalizeEmail()\n    .isLength({ max: 254 })\n    .withMessage('E-mail trop long (max 254 caract\u00e8res RFC 5321)'),\n\n  body('username')\n    .isString()\n    .withMessage(\"Le nom d'utilisateur doit \u00eatre une cha\u00eene\")\n    .trim()\n    .escape()\n    .isLength({ min: 3, max: 30 })\n    .withMessage(\"Nom d'utilisateur : entre 3 et 30 caract\u00e8res\")\n    .matches(\/^[a-zA-Z0-9_-]+$\/)\n    .withMessage('Caract\u00e8res autoris\u00e9s : lettres, chiffres, _ et -'),\n\n  body('age')\n    .optional()\n    .isInt({ min: 13, max: 120 })\n    .withMessage(\"L'\u00e2ge doit \u00eatre un entier entre 13 et 120\")\n    .toInt(),\n\n  body('password')\n    .isLength({ min: 12 })\n    .withMessage('Mot de passe : minimum 12 caract\u00e8res')\n    .matches(\/^(?=.*[a-z])(?=.*[A-Z])(?=.*\\d)(?=.*[\\W_])\/)\n    .withMessage('Le mot de passe doit contenir majuscule, minuscule, chiffre et symbole'),\n];\n\nmodule.exports = { registerValidation };<\/code><\/pre>\n\n\n\n
D\u00e9taillons les m\u00e9thodes cl\u00e9s. La m\u00e9thode .normalizeEmail()<\/code> convertit l’adresse en minuscules et supprime les alias courants (les points dans les adresses Gmail). La m\u00e9thode .escape()<\/code> remplace les caract\u00e8res HTML dangereux (<<\/code>, ><\/code>, &<\/code>, "<\/code>) par leurs entit\u00e9s HTML. La m\u00e9thode .toInt()<\/code> caste la valeur en nombre entier JavaScript, \u00e9vitant les comparaisons de type cha\u00eene dans la logique m\u00e9tier.<\/p>\n\n\n\n
La r\u00e8gle .matches(\/^[a-zA-Z0-9_-]+$\/)<\/code> sur le nom d’utilisateur applique une liste blanche de caract\u00e8res autoris\u00e9s. C’est l’approche recommand\u00e9e par l’OWASP : valider ce qui est accept\u00e9 plut\u00f4t que de chercher \u00e0 bloquer ce qui est interdit. Un attaquant peut toujours trouver un vecteur d’injection non anticip\u00e9 ; une liste blanche r\u00e9duit drastiquement la surface d’attaque.<\/p>\n\n\n\n
\u00c9tape 4 : Cr\u00e9er le middleware de gestion des erreurs de validation<\/h2>\n\n\n\n
La validation ne sert \u00e0 rien si les erreurs ne sont pas intercept\u00e9es et renvoy\u00e9es correctement au client. Cr\u00e9ez un middleware r\u00e9utilisable qui v\u00e9rifie le r\u00e9sultat de validation apr\u00e8s chaque r\u00e8gle et renvoie une r\u00e9ponse 400 structur\u00e9e si des erreurs sont pr\u00e9sentes.<\/p>\n\n\n\n
\/\/ src\/middlewares\/validate.js\nconst { validationResult } = require('express-validator');\n\nconst validate = (req, res, next) => {\n  const errors = validationResult(req);\n\n  if (!errors.isEmpty()) {\n    return res.status(400).json({\n      status: 'error',\n      message: 'Donn\u00e9es invalides',\n      errors: errors.array().map(err => ({\n        field: err.path,\n        message: err.msg,\n        value: err.value\n      }))\n    });\n  }\n\n  next();\n};\n\nmodule.exports = validate;<\/code><\/pre>\n\n\n\n
Voici un exemple de r\u00e9ponse renvoy\u00e9e quand le formulaire contient des erreurs :<\/p>\n\n\n\n
{\n  \"status\": \"error\",\n  \"message\": \"Donn\u00e9es invalides\",\n  \"errors\": [\n    {\n      \"field\": \"email\",\n      \"message\": \"Adresse e-mail invalide\",\n      \"value\": \"pas-un-email\"\n    },\n    {\n      \"field\": \"password\",\n      \"message\": \"Mot de passe : minimum 12 caract\u00e8res\",\n      \"value\": \"court\"\n    }\n  ]\n}<\/code><\/pre>\n\n\n\n
Cette r\u00e9ponse structur\u00e9e permet au client (un front-end React ou Vue.js) d’afficher les erreurs par champ sans analyser un message g\u00e9n\u00e9rique. Notez que la cl\u00e9 value<\/code> expose la valeur soumise : dans un formulaire public, vous pouvez supprimer ce champ pour \u00e9viter de renvoyer des donn\u00e9es sensibles comme un mot de passe. En environnement de d\u00e9veloppement, il est utile de le conserver pour d\u00e9boguer.<\/p>\n\n\n\n
Connectez maintenant les r\u00e8gles et le middleware \u00e0 une route Express :<\/p>\n\n\n\n
\/\/ src\/routes\/user.routes.js\nconst express = require('express');\nconst { registerValidation } = require('..\/validators\/user.validator');\nconst validate = require('..\/middlewares\/validate');\n\nconst router = express.Router();\n\nrouter.post('\/register',\n  registerValidation,  \/\/ Tableau de r\u00e8gles express-validator\n  validate,            \/\/ Middleware qui intercepte les erreurs\n  async (req, res) => {\n    \/\/ Ici, req.body contient uniquement des donn\u00e9es valid\u00e9es et sanitis\u00e9es\n    const { email, username, age, password } = req.body;\n\n    \/\/ Logique m\u00e9tier : cr\u00e9ation de l'utilisateur en base de donn\u00e9es\n    \/\/ ...\n\n    res.status(201).json({\n      status: 'success',\n      message: 'Utilisateur cr\u00e9\u00e9 avec succ\u00e8s'\n    });\n  }\n);\n\nmodule.exports = router;<\/code><\/pre>\n\n\n\n
\u00c9tape 5 : Valider des sch\u00e9mas complexes avec Joi<\/h2>\n\n\n\n
Pour les structures JSON imbriqu\u00e9es (tableaux d’objets, sch\u00e9mas conditionnels, d\u00e9pendances entre champs), Joi offre une expressivit\u00e9 sup\u00e9rieure \u00e0 express-validator. Joi permet de d\u00e9finir un sch\u00e9ma complet en un seul objet et de valider l’int\u00e9gralit\u00e9 du corps de la requ\u00eate en une seule op\u00e9ration.<\/p>\n\n\n\n
\/\/ src\/validators\/user.schema.joi.js\nconst Joi = require('joi');\n\nconst createOrderSchema = Joi.object({\n  userId: Joi.string().uuid({ version: 'uuidv4' }).required(),\n\n  items: Joi.array().items(\n    Joi.object({\n      productId: Joi.string().alphanum().min(8).max(24).required(),\n      quantity: Joi.number().integer().min(1).max(99).required(),\n      unitPrice: Joi.number().positive().precision(2).required()\n    })\n  ).min(1).max(50).required(),\n\n  shippingAddress: Joi.object({\n    street: Joi.string().max(100).required(),\n    city: Joi.string().max(50).required(),\n    postalCode: Joi.string()\n      .pattern(\/^\\d{5}$\/)\n      .required()\n      .messages({ 'string.pattern.base': 'Code postal fran\u00e7ais : 5 chiffres requis' }),\n    country: Joi.string().valid('FR', 'BE', 'CH', 'LU').default('FR')\n  }).required(),\n\n  couponCode: Joi.string()\n    .alphanum()\n    .length(10)\n    .optional()\n    .when('items', {\n      is: Joi.array().min(3),\n      then: Joi.optional(),\n      otherwise: Joi.forbidden()\n    })\n});\n\nconst validateOrder = (req, res, next) => {\n  const { error, value } = createOrderSchema.validate(req.body, {\n    abortEarly: false,    \/\/ Collecte toutes les erreurs, pas seulement la premi\u00e8re\n    stripUnknown: true,   \/\/ Supprime les champs non d\u00e9finis dans le sch\u00e9ma\n    convert: true         \/\/ Convertit les types si possible (string vers number)\n  });\n\n  if (error) {\n    return res.status(400).json({\n      status: 'error',\n      errors: error.details.map(d => ({\n        field: d.path.join('.'),\n        message: d.message\n      }))\n    });\n  }\n\n  req.body = value;\n  next();\n};\n\nmodule.exports = { validateOrder, createOrderSchema };<\/code><\/pre>\n\n\n\n
L’option stripUnknown: true<\/code> est fondamentale pour la s\u00e9curit\u00e9. Elle supprime automatiquement tous les champs non d\u00e9clar\u00e9s dans le sch\u00e9ma Joi, ce qui emp\u00eache les attaques de mass assignment : un attaquant ne peut pas injecter un champ isAdmin: true<\/code> si ce champ n’est pas pr\u00e9sent dans le sch\u00e9ma. La r\u00e8gle .when()<\/code> sur couponCode<\/code> illustre les validations conditionnelles : un code promo n’est autoris\u00e9 que si la commande contient au moins 3 articles, et est interdit (Joi.forbidden()<\/code>) dans le cas contraire.<\/p>\n\n\n\n
\u00c9tape 6 : Validation type-safe avec Zod<\/h2>\n\n\n\n
Zod est particuli\u00e8rement adapt\u00e9 aux projets TypeScript ou aux projets JavaScript qui souhaitent b\u00e9n\u00e9ficier de l’inf\u00e9rence de type sans compiler TypeScript. La biblioth\u00e8que g\u00e9n\u00e8re automatiquement les types TypeScript \u00e0 partir du sch\u00e9ma de validation, \u00e9liminant la duplication entre les d\u00e9finitions de types et les r\u00e8gles de validation. Zod comptait plus de 22 millions de t\u00e9l\u00e9chargements hebdomadaires sur npm en 2026.<\/p>\n\n\n\n
\/\/ src\/validators\/user.schema.zod.js\nconst { z } = require('zod');\n\nconst loginSchema = z.object({\n  email: z\n    .string({ required_error: \"L'e-mail est obligatoire\" })\n    .email({ message: \"Format d'e-mail invalide\" })\n    .toLowerCase()\n    .trim(),\n\n  password: z\n    .string({ required_error: 'Le mot de passe est obligatoire' })\n    .min(12, 'Minimum 12 caract\u00e8res')\n    .max(128, 'Maximum 128 caract\u00e8res'),\n\n  rememberMe: z.boolean().default(false),\n\n  totpToken: z\n    .string()\n    .length(6, 'Le code TOTP doit contenir 6 chiffres')\n    .regex(\/^\\d{6}$\/, 'Code TOTP : 6 chiffres uniquement')\n    .optional()\n});\n\nconst validateLogin = (req, res, next) => {\n  const result = loginSchema.safeParse(req.body);\n\n  if (!result.success) {\n    const errors = result.error.issues.map(issue => ({\n      field: issue.path.join('.'),\n      message: issue.message\n    }));\n\n    return res.status(400).json({ status: 'error', errors });\n  }\n\n  req.body = result.data;\n  next();\n};\n\nmodule.exports = { validateLogin, loginSchema };<\/code><\/pre>\n\n\n\n
La m\u00e9thode safeParse()<\/code> de Zod ne lance jamais d’exception, contrairement \u00e0 parse()<\/code>. Elle retourne un objet { success: true, data }<\/code> ou { success: false, error }<\/code>, ce qui s’int\u00e8gre proprement dans un flux async\/await sans bloc try\/catch suppl\u00e9mentaire. La transformation .toLowerCase().trim()<\/code> est appliqu\u00e9e directement dans le sch\u00e9ma, garantissant que les donn\u00e9es dans result.data<\/code> sont d\u00e9j\u00e0 normalis\u00e9es. La validation du code TOTP \u00e0 6 chiffres s’int\u00e8gre naturellement dans le sch\u00e9ma de connexion, compl\u00e9mentant l’authentification \u00e0 deux facteurs couverte dans notre article sur l’authentification \u00e0 deux facteurs dans Node.js<\/a>.<\/p>\n\n\n\n
\u00c9tape 7 : Prot\u00e9ger contre les attaques XSS c\u00f4t\u00e9 serveur<\/h2>\n\n\n\n
La m\u00e9thode .escape()<\/code> d’express-validator prot\u00e8ge contre le XSS r\u00e9fl\u00e9chi en encodant les caract\u00e8res HTML. Mais si votre application doit accepter et stocker du HTML (un \u00e9diteur de contenu riche, par exemple), vous avez besoin d’une sanitisation HTML compl\u00e8te, pas d’un simple encodage. DOMPurify avec jsdom permet de filtrer le HTML c\u00f4t\u00e9 serveur en conservant les balises autoris\u00e9es et en supprimant les scripts, gestionnaires d’\u00e9v\u00e9nements et attributs dangereux.<\/p>\n\n\n\n
\/\/ src\/middlewares\/sanitize-html.js\nconst { JSDOM } = require('jsdom');\nconst createDOMPurify = require('dompurify');\n\n\/\/ Cr\u00e9e une instance DOMPurify avec un environnement DOM virtuel\nconst window = new JSDOM('').window;\nconst DOMPurify = createDOMPurify(window);\n\n\/\/ Liste blanche stricte des balises HTML autoris\u00e9es\nconst ALLOWED_TAGS = ['b', 'i', 'em', 'strong', 'a', 'p', 'ul', 'ol', 'li', 'br'];\nconst ALLOWED_ATTR = ['href', 'title'];\n\nconst sanitizeHtmlContent = (content) => {\n  if (typeof content !== 'string') return '';\n\n  return DOMPurify.sanitize(content, {\n    ALLOWED_TAGS,\n    ALLOWED_ATTR,\n    ALLOW_DATA_ATTR: false,   \/\/ Interdit data-* attributes\n    FORBID_SCRIPTS: true,     \/\/ Bloque toute balise script\n    FORBID_TAGS: ['style'],   \/\/ Bloque le CSS inline\n  });\n};\n\nconst sanitizeRichText = (req, res, next) => {\n  const RICH_TEXT_FIELDS = ['bio', 'description', 'content'];\n\n  RICH_TEXT_FIELDS.forEach(field => {\n    if (req.body[field]) {\n      req.body[field] = sanitizeHtmlContent(req.body[field]);\n    }\n  });\n\n  next();\n};\n\nmodule.exports = { sanitizeRichText, sanitizeHtmlContent };<\/code><\/pre>\n\n\n\n
Exemple concret : un attaquant soumet la valeur suivante pour le champ bio<\/code> :<\/p>\n\n\n\n
\/\/ Entr\u00e9e malveillante\n\"<p>Bonjour<\/p><script>document.cookie='stolen='+document.cookie<\/script><img src=x onerror=alert(1)>\"\n\n\/\/ Apr\u00e8s sanitisation DOMPurify\n\"<p>Bonjour<\/p>\"<\/code><\/pre>\n\n\n\n
DOMPurify supprime la balise <script><\/code> et l’attribut onerror<\/code> de la balise <img><\/code>, tout en conservant le contenu HTML l\u00e9gitime. Sans cette sanitisation, le script serait stock\u00e9 en base et ex\u00e9cut\u00e9 dans le navigateur de chaque utilisateur consultant le profil, r\u00e9alisant une attaque XSS stock\u00e9. Ce type de vuln\u00e9rabilit\u00e9 figure r\u00e9guli\u00e8rement dans les rapports de bug bounty avec une s\u00e9v\u00e9rit\u00e9 CVSS entre 7 et 9.<\/p>\n\n\n\n
\u00c9tape 8 : Pr\u00e9venir les injections NoSQL avec MongoDB<\/h2>\n\n\n\n
Les injections NoSQL dans MongoDB exploitent les op\u00e9rateurs de requ\u00eate ($where<\/code>, $gt<\/code>, $regex<\/code>) pour modifier la logique des requ\u00eates. Un exemple classique : un attaquant envoie { \"email\": { \"$gt\": \"\" } }<\/code> comme corps de requ\u00eate de connexion, ce qui retourne le premier utilisateur de la base sans v\u00e9rification de mot de passe. Cette attaque est triviale \u00e0 mener et n’appara\u00eet pas dans les logs applicatifs sans monitoring sp\u00e9cifique.<\/p>\n\n\n\n
\/\/ Protection contre l'injection NoSQL avec validation de type\nconst { body } = require('express-validator');\n\nconst loginValidation = [\n  body('email')\n    .isString()           \/\/ Interdit les objets JSON comme valeur d'email\n    .withMessage(\"L'e-mail doit \u00eatre une cha\u00eene de caract\u00e8res\")\n    .isEmail()\n    .withMessage(\"Format d'e-mail invalide\")\n    .normalizeEmail(),\n\n  body('password')\n    .isString()           \/\/ Interdit { \"$regex\": \".*\" } comme mot de passe\n    .withMessage('Le mot de passe doit \u00eatre une cha\u00eene')\n    .isLength({ min: 1, max: 128 })\n];\n\n\/\/ Dans le contr\u00f4leur, utilisez un cast explicite en string\nconst loginUser = async (req, res) => {\n  const { email, password } = req.body;\n\n  \/\/ S\u00c9CURIS\u00c9 : cast explicite avant la requ\u00eate Mongoose\n  const user = await User.findOne({\n    email: String(email)  \/\/ Double protection contre l'injection NoSQL\n  });\n\n  \/\/ DANGEREUX : ne jamais passer req.body directement \u00e0 MongoDB\n  \/\/ const user = await User.findOne(req.body);\n};<\/code><\/pre>\n\n\n\n
La combinaison des trois niveaux de protection offre une d\u00e9fense en profondeur : express-mongo-sanitize<\/code> supprime les op\u00e9rateurs au niveau du middleware global, la validation .isString()<\/code> rejette les valeurs non-string au niveau de la route, et le cast explicite String(email)<\/code> garantit le type au niveau du contr\u00f4leur. La protection CSRF couvre un vecteur d’attaque compl\u00e9mentaire et est d\u00e9taill\u00e9e dans notre guide sur la protection CSRF dans Node.js<\/a>.<\/p>\n\n\n\n
\u00c9tape 9 : Valider les fichiers upload\u00e9s avec Multer<\/h2>\n\n\n\n
Les uploads de fichiers constituent une surface d’attaque souvent sous-estim\u00e9e. Sans validation, un attaquant peut uploader un fichier PHP d\u00e9guis\u00e9 en image JPEG, un ex\u00e9cutable malveillant, ou un fichier de 10 Go pour saturer le disque. Multer doit \u00eatre configur\u00e9 avec des filtres stricts sur le type MIME, la taille et le nom du fichier.<\/p>\n\n\n\n
\/\/ src\/middlewares\/upload.js\nconst multer = require('multer');\nconst path = require('path');\nconst crypto = require('crypto');\n\nconst ALLOWED_MIME_TYPES = ['image\/jpeg', 'image\/png', 'image\/webp'];\nconst MAX_FILE_SIZE = 5 * 1024 * 1024; \/\/ 5 Mo maximum\n\nconst storage = multer.diskStorage({\n  destination: (req, file, cb) => {\n    cb(null, 'uploads\/');\n  },\n  filename: (req, file, cb) => {\n    \/\/ Nom de fichier al\u00e9atoire : \u00e9vite les collisions et le path traversal\n    const randomName = crypto.randomBytes(16).toString('hex');\n    const ext = path.extname(file.originalname).toLowerCase();\n    cb(null, `${randomName}${ext}`);\n  }\n});\n\nconst fileFilter = (req, file, cb) => {\n  if (!ALLOWED_MIME_TYPES.includes(file.mimetype)) {\n    return cb(\n      new Error(`Type de fichier interdit. Formats accept\u00e9s : JPEG, PNG, WebP`),\n      false\n    );\n  }\n\n  const ext = path.extname(file.originalname).toLowerCase();\n  if (!['.jpg', '.jpeg', '.png', '.webp'].includes(ext)) {\n    return cb(new Error('Extension de fichier invalide'), false);\n  }\n\n  cb(null, true);\n};\n\nconst upload = multer({\n  storage,\n  fileFilter,\n  limits: {\n    fileSize: MAX_FILE_SIZE,\n    files: 1              \/\/ Maximum 1 fichier par requ\u00eate\n  }\n});\n\nmodule.exports = upload;<\/code><\/pre>\n\n\n\n
Le nommage al\u00e9atoire des fichiers avec crypto.randomBytes(16)<\/code> est une protection contre les attaques par chemin de travers\u00e9e (path traversal). Un fichier nomm\u00e9 ..\/..\/..\/..\/etc\/passwd<\/code> par l’attaquant sera renomm\u00e9 en a3f7c82d1e09b456.jpg<\/code> avant d’\u00eatre \u00e9crit sur le disque, emp\u00eachant toute \u00e9criture hors du dossier uploads\/<\/code>. En production, ajoutez une v\u00e9rification des magic bytes avec la biblioth\u00e8que file-type<\/code> pour confirmer le format r\u00e9el du fichier, ind\u00e9pendamment du type MIME d\u00e9clar\u00e9.<\/p>\n\n\n\n
\u00c9tape 10 : Cr\u00e9er un middleware de validation centralis\u00e9 et r\u00e9utilisable<\/h2>\n\n\n\n
Plut\u00f4t que de r\u00e9p\u00e9ter la logique de validation dans chaque route, cr\u00e9ez une factory function qui g\u00e9n\u00e8re un middleware de validation \u00e0 partir d’un sch\u00e9ma Joi ou Zod. Cette approche centralise la gestion des erreurs et facilite les tests unitaires.<\/p>\n\n\n\n
\/\/ src\/middlewares\/validate-schema.js\n\n\/\/ Factory pour les sch\u00e9mas Joi (body, query, params)\nconst validateJoi = (schema, target = 'body') => {\n  return (req, res, next) => {\n    const { error, value } = schema.validate(req[target], {\n      abortEarly: false,\n      stripUnknown: true,\n      convert: true\n    });\n\n    if (error) {\n      return res.status(400).json({\n        status: 'error',\n        source: target,\n        errors: error.details.map(d => ({\n          field: d.path.join('.'),\n          message: d.message.replace(\/\"\/g, \"'\")\n        }))\n      });\n    }\n\n    req[target] = value;\n    next();\n  };\n};\n\n\/\/ Factory pour les sch\u00e9mas Zod\nconst validateZod = (schema, target = 'body') => {\n  return (req, res, next) => {\n    const result = schema.safeParse(req[target]);\n\n    if (!result.success) {\n      return res.status(400).json({\n        status: 'error',\n        source: target,\n        errors: result.error.issues.map(issue => ({\n          field: issue.path.join('.'),\n          message: issue.message\n        }))\n      });\n    }\n\n    req[target] = result.data;\n    next();\n  };\n};\n\nmodule.exports = { validateJoi, validateZod };<\/code><\/pre>\n\n\n\n
Utilisation dans les routes pour valider diff\u00e9rentes sources de donn\u00e9es :<\/p>\n\n\n\n
const { z } = require('zod');\nconst Joi = require('joi');\nconst { validateJoi, validateZod } = require('..\/middlewares\/validate-schema');\nconst { createOrderSchema } = require('..\/validators\/user.schema.joi');\n\n\/\/ Valider le body JSON avec Joi\nrouter.post('\/orders', validateJoi(createOrderSchema), createOrderController);\n\n\/\/ Valider les param\u00e8tres d'URL avec Zod\nconst idSchema = z.object({ id: z.string().uuid(\"ID utilisateur invalide\") });\nrouter.get('\/users\/:id', validateZod(idSchema, 'params'), getUserController);\n\n\/\/ Valider les query strings avec Joi\nconst paginationSchema = Joi.object({\n  page: Joi.number().integer().min(1).default(1),\n  limit: Joi.number().integer().min(1).max(100).default(20),\n  sort: Joi.string().valid('asc', 'desc').default('desc')\n});\nrouter.get('\/products', validateJoi(paginationSchema, 'query'), listProductsController);<\/code><\/pre>\n\n\n\n
\u00c9tape 11 : Tests unitaires de la validation<\/h2>\n\n\n\n
La validation est une logique critique qui doit \u00eatre couverte par des tests. Un sch\u00e9ma de validation cass\u00e9 peut exposer l’application \u00e0 des injections ou provoquer des r\u00e9gressions silencieuses. Utilisez Jest ou le test runner natif de Node.js (disponible depuis Node.js 20) pour tester les sch\u00e9mas sans d\u00e9marrer le serveur.<\/p>\n\n\n\n
\/\/ tests\/user.validator.test.js\nconst { createOrderSchema } = require('..\/src\/validators\/user.schema.joi');\n\ndescribe('Sch\u00e9ma de commande Joi', () => {\n  const validOrder = {\n    userId: '550e8400-e29b-41d4-a716-446655440000',\n    items: [\n      { productId: 'PROD12345678', quantity: 2, unitPrice: 19.99 }\n    ],\n    shippingAddress: {\n      street: '12 rue de la Paix',\n      city: 'Paris',\n      postalCode: '75001',\n      country: 'FR'\n    }\n  };\n\n  test('Accepte une commande valide', () => {\n    const { error } = createOrderSchema.validate(validOrder);\n    expect(error).toBeUndefined();\n  });\n\n  test('Rejette un UUID malform\u00e9', () => {\n    const { error } = createOrderSchema.validate({\n      ...validOrder, userId: 'pas-un-uuid'\n    });\n    expect(error).toBeDefined();\n    expect(error.details[0].path).toContain('userId');\n  });\n\n  test('Rejette un code postal \u00e0 4 chiffres', () => {\n    const { error } = createOrderSchema.validate({\n      ...validOrder,\n      shippingAddress: { ...validOrder.shippingAddress, postalCode: '1234' }\n    });\n    expect(error).toBeDefined();\n  });\n\n  test('Supprime les champs inconnus (stripUnknown)', () => {\n    const { value } = createOrderSchema.validate(\n      { ...validOrder, isAdmin: true, secret: 'payload' },\n      { stripUnknown: true }\n    );\n    expect(value.isAdmin).toBeUndefined();\n    expect(value.secret).toBeUndefined();\n  });\n\n  test('Interdit le couponCode avec moins de 3 articles', () => {\n    const { error } = createOrderSchema.validate({\n      ...validOrder,\n      couponCode: 'PROMO12345'  \/\/ 1 seul article, coupon interdit\n    });\n    expect(error).toBeDefined();\n  });\n});<\/code><\/pre>\n\n\n\n
Le test stripUnknown<\/code> est particuli\u00e8rement important : il v\u00e9rifie que le comportement anti-mass-assignment fonctionne bien et que des champs inject\u00e9s comme isAdmin<\/code> sont effectivement supprim\u00e9s. Ce test doit faire partie de la pipeline CI\/CD pour garantir qu’aucun refactoring ne r\u00e9introduit une vuln\u00e9rabilit\u00e9. Pour renforcer la s\u00e9curit\u00e9 de la gestion des sessions en lien avec la validation, consultez notre guide sur la gestion des sessions dans Node.js<\/a>.<\/p>\n\n\n\n
\u00c9tape 12 : Gestionnaire d’erreurs global et d\u00e9ploiement s\u00e9curis\u00e9<\/h2>\n\n\n\n
En production, quelques configurations suppl\u00e9mentaires renforcent la robustesse de la validation. Express 5 g\u00e8re nativement les erreurs asynchrones, mais il faut quand m\u00eame configurer un gestionnaire d’erreurs global pour les erreurs de Multer et les rejets non captur\u00e9s.<\/p>\n\n\n\n
\/\/ Gestionnaire d'erreurs global Express (apr\u00e8s toutes les routes)\napp.use((err, req, res, next) => {\n  \/\/ Erreurs Multer : fichier trop volumineux\n  if (err.code === 'LIMIT_FILE_SIZE') {\n    return res.status(413).json({\n      status: 'error',\n      message: 'Fichier trop volumineux (maximum 5 Mo)'\n    });\n  }\n\n  \/\/ Type MIME interdit\n  if (err.message && err.message.includes('Type de fichier interdit')) {\n    return res.status(415).json({\n      status: 'error',\n      message: err.message\n    });\n  }\n\n  \/\/ Corps JSON malform\u00e9\n  if (err.type === 'entity.parse.failed') {\n    return res.status(400).json({\n      status: 'error',\n      message: 'Corps de la requ\u00eate JSON invalide'\n    });\n  }\n\n  \/\/ Erreur g\u00e9n\u00e9rique : ne jamais exposer la stack trace en production\n  console.error('[ERROR]', err.message);\n  res.status(500).json({\n    status: 'error',\n    message: 'Erreur interne du serveur'\n  });\n});\n\n\/\/ Protection contre les rejets de promesse non captur\u00e9s\nprocess.on('unhandledRejection', (reason) => {\n  console.error('[UNHANDLED REJECTION]', reason);\n});<\/code><\/pre>\n\n\n\n
En production, activez NODE_ENV=production<\/code>. Express et Helmet ajustent leur comportement dans ce mode : Express supprime les en-t\u00eates qui exposent la version du framework, et les messages d’erreur deviennent moins verbeux. Combinez cette configuration avec les bonnes pratiques de rate limiting dans Node.js<\/a> pour limiter le nombre de tentatives de validation par IP et d\u00e9tecter les scans automatis\u00e9s.<\/p>\n\n\n\n
Comparaison des biblioth\u00e8ques de validation Node.js en 2026<\/h2>\n\n\n\n
Chaque biblioth\u00e8que de validation a ses forces et ses cas d’usage optimaux. Le tableau suivant compare les principales options disponibles dans l’\u00e9cosyst\u00e8me Node.js en 2026 :<\/p>\n\n\n\n
Biblioth\u00e8que<\/th>T\u00e9l\u00e9chargements\/semaine<\/th>Taille bundle<\/th>TypeScript natif<\/th>Meilleur usage<\/th><\/tr><\/thead>
express-validator 7<\/strong><\/td>25M+<\/td>~25 Ko<\/td>Types fournis<\/td>Validation par champ sur routes Express<\/td><\/tr>
Joi 17<\/strong><\/td>12M+<\/td>~145 Ko<\/td>Types fournis<\/td>Sch\u00e9mas complexes, conditions entre champs<\/td><\/tr>
Zod 3<\/strong><\/td>22M+<\/td>~55 Ko<\/td>Inf\u00e9rence native<\/td>Projets TypeScript, monorepo front+back<\/td><\/tr>
Yup<\/strong><\/td>9M+<\/td>~40 Ko<\/td>Types fournis<\/td>Formulaires React\/front-end avec Formik<\/td><\/tr>
class-validator<\/strong><\/td>5M+<\/td>~60 Ko<\/td>D\u00e9corateurs TS<\/td>NestJS avec d\u00e9corateurs TypeScript<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Pour un projet Express classique sans TypeScript, express-validator<\/strong> est le choix naturel : il s’int\u00e8gre directement comme middleware, sa syntaxe cha\u00een\u00e9e est lisible, et sa communaut\u00e9 large garantit une documentation abondante. Pour des sch\u00e9mas imbriqu\u00e9s complexes ou des validations conditionnelles, Joi<\/strong> offre une expressivit\u00e9 sup\u00e9rieure. Pour les nouveaux projets TypeScript, Zod<\/strong> est devenu le standard de facto en 2025-2026 gr\u00e2ce \u00e0 l’inf\u00e9rence de type automatique.<\/p>\n\n\n\n
6 pi\u00e8ges courants \u00e0 \u00e9viter absolument<\/h2>\n\n\n\n
Pi\u00e8ge 1 : Valider sans sanitiser.<\/strong> Beaucoup de d\u00e9veloppeurs ajoutent .isEmail()<\/code> mais oublient .normalizeEmail()<\/code> et .escape()<\/code>. La validation confirme que la valeur respecte un format attendu, mais sans sanitisation, la valeur valid\u00e9e peut contenir des caract\u00e8res dangereux. Ces deux \u00e9tapes sont compl\u00e9mentaires et doivent toujours \u00eatre combin\u00e9es.<\/p>\n\n\n\n
Pi\u00e8ge 2 : Ne valider que le body et oublier query et params.<\/strong> Les param\u00e8tres d’URL (req.params.id<\/code>) et les query strings (req.query.page<\/code>) sont aussi des entr\u00e9es utilisateur. Une injection peut passer par GET \/users\/..\/..\/etc\/passwd<\/code> ou GET \/products?limit=999999<\/code>. Validez syst\u00e9matiquement les trois sources.<\/p>\n\n\n\n
Pi\u00e8ge 3 : Faire confiance au type MIME des fichiers upload\u00e9s.<\/strong> Le champ file.mimetype<\/code> de Multer provient de l’en-t\u00eate Content-Type<\/code> envoy\u00e9 par le client, qui peut \u00eatre falsifi\u00e9 avec n’importe quel outil HTTP. Un fichier PHP renomm\u00e9 photo.jpg<\/code> avec le type MIME image\/jpeg<\/code> passera le filtre Multer de base. Utilisez file-type<\/code> pour v\u00e9rifier les magic bytes r\u00e9els du fichier.<\/p>\n\n\n\n
Pi\u00e8ge 4 : Exposer les d\u00e9tails d’erreur en production.<\/strong> Les messages d’erreur de validation Joi contiennent par d\u00e9faut des informations sur la structure attendue du sch\u00e9ma. En production, ces informations aident l’attaquant \u00e0 affiner ses payloads. Filtrez ou g\u00e9n\u00e9ralisez les messages d’erreur pour les routes publiques, et conservez les messages d\u00e9taill\u00e9s uniquement dans les logs serveur.<\/p>\n\n\n\n
Pi\u00e8ge 5 : Appliquer la validation uniquement \u00e0 l’entr\u00e9e et oublier la sortie.<\/strong> Si votre API retourne des donn\u00e9es de la base directement dans la r\u00e9ponse sans filtrer les champs sensibles (mot de passe hash\u00e9, token de r\u00e9initialisation, r\u00f4les internes), vous exposez des informations critiques. Utilisez les propri\u00e9t\u00e9s select: false<\/code> de Mongoose ou une biblioth\u00e8que de s\u00e9rialisation pour contr\u00f4ler ce qui sort.<\/p>\n\n\n\n
Pi\u00e8ge 6 : Utiliser une liste noire au lieu d’une liste blanche.<\/strong> Interdire <script><\/code> et onerror<\/code> n’est pas suffisant : il existe des dizaines de vecteurs XSS alternatifs (<svg\/onload><\/code>, <math href=\"javascript:...\"><\/code>, encodages Unicode, etc.). La liste noire est un jeu du chat et de la souris perdu d’avance. Utilisez toujours une liste blanche de caract\u00e8res et de balises autoris\u00e9s.<\/p>\n\n\n\n
D\u00e9pannage : 8 probl\u00e8mes fr\u00e9quents<\/h2>\n\n\n\n
Probl\u00e8me 1 : validationResult(req)<\/code> retourne toujours vide.<\/strong> V\u00e9rifiez que les r\u00e8gles de validation sont bien pass\u00e9es comme tableau dans la d\u00e9finition de la route, avant le middleware validate<\/code>. Si les r\u00e8gles sont import\u00e9es comme objet et non comme tableau, express-validator ne les ex\u00e9cute pas. V\u00e9rifiez \u00e9galement que le body parser (express.json()<\/code>) est configur\u00e9 avant les routes.<\/p>\n\n\n\n
Probl\u00e8me 2 : .escape()<\/code> encode les donn\u00e9es stock\u00e9es en base.<\/strong> La m\u00e9thode .escape()<\/code> encode les caract\u00e8res HTML : <<\/code> devient &lt;<\/code>. Si ces donn\u00e9es sont stock\u00e9es dans ce format encod\u00e9, elles s’afficheront avec les entit\u00e9s HTML dans une application React qui utilise dangerouslySetInnerHTML<\/code>. Solution : appliquer .escape()<\/code> uniquement pour les champs affich\u00e9s dans des templates HTML c\u00f4t\u00e9 serveur. Pour les APIs JSON consomm\u00e9es par du JavaScript, pr\u00e9f\u00e9rez sanitiser \u00e0 la sortie.<\/p>\n\n\n\n
Probl\u00e8me 3 : Joi retourne des messages en anglais.<\/strong> Joi g\u00e9n\u00e8re ses messages d’erreur en anglais par d\u00e9faut. Pour les franciser, utilisez le param\u00e8tre messages<\/code> lors de la validation. Vous pouvez cr\u00e9er un fichier de messages globaux r\u00e9utilisable : Joi.defaults(schema => schema.messages({ 'string.email': '{{#label}} doit \u00eatre un e-mail valide' }))<\/code>.<\/p>\n\n\n\n
Probl\u00e8me 4 : Multer retourne LIMIT_FILE_SIZE mais la taille semble correcte.<\/strong> La limite de Multer s’applique \u00e0 la taille brute du payload HTTP, pas au fichier d\u00e9cod\u00e9. Un fichier de 4,8 Mo encod\u00e9 en multipart peut l\u00e9g\u00e8rement d\u00e9passer la limite de 5 Mo \u00e0 cause des headers multipart. R\u00e9duisez l\u00e9g\u00e8rement la limite (4.5 * 1024 * 1024<\/code>) ou augmentez-la si votre cas d’usage le justifie.<\/p>\n\n\n\n
Probl\u00e8me 5 : express-mongo-sanitize<\/code> bloque des donn\u00e9es l\u00e9gitimes.<\/strong> La biblioth\u00e8que supprime tout champ dont le nom commence par $<\/code> ou contient un point. Si votre API accepte des noms de champs dynamiques avec des points (des chemins de propri\u00e9t\u00e9s imbriqu\u00e9es), configurez l’option allowDots: false<\/code> ou g\u00e9rez ces cas avant le middleware global.<\/p>\n\n\n\n
Probl\u00e8me 6 : Zod safeParse<\/code> \u00e9choue sur des types JSON valides.<\/strong> Zod est strict sur les types. Un champ num\u00e9rique envoy\u00e9 comme cha\u00eene (\"age\": \"25\"<\/code> au lieu de \"age\": 25<\/code>) \u00e9chouera \u00e0 la validation z.number()<\/code>. Pour accepter les deux, utilisez z.coerce.number()<\/code> qui tente une conversion automatique. Pour les query strings, qui sont toujours des cha\u00eenes, z.coerce<\/code> est quasi obligatoire.<\/p>\n\n\n\n
Probl\u00e8me 7 : La validation passe mais les donn\u00e9es en base sont incorrectes.<\/strong> Si vous utilisez Mongoose, son sch\u00e9ma applique sa propre validation et ses casts. Dans certains cas, Mongoose peut modifier des valeurs apr\u00e8s votre validation (notamment les nombres et les booleans). Testez le flux complet avec des donn\u00e9es r\u00e9elles et v\u00e9rifiez ce qui est r\u00e9ellement stock\u00e9.<\/p>\n\n\n\n
Probl\u00e8me 8 : DOMPurify c\u00f4t\u00e9 serveur ne fonctionne pas.<\/strong> DOMPurify est con\u00e7u pour le navigateur. Pour une utilisation c\u00f4t\u00e9 serveur avec Node.js, il faut obligatoirement passer une fen\u00eatre DOM via jsdom, comme dans l’exemple de l’\u00e9tape 7. Si vous obtenez l’erreur DOMPurify is not a function<\/code> ou des r\u00e9sultats vides, v\u00e9rifiez que vous utilisez bien createDOMPurify(window)<\/code> avec l’import correct : const createDOMPurify = require('dompurify')<\/code>.<\/p>\n\n\n\n
Conseils avanc\u00e9s pour la validation en production<\/h2>\n\n\n\n
Validation OpenAPI automatique.<\/strong> Si votre API est document\u00e9e avec une sp\u00e9cification OpenAPI 3.x, des biblioth\u00e8ques comme express-openapi-validator<\/code> peuvent g\u00e9n\u00e9rer automatiquement les middlewares de validation \u00e0 partir de votre spec YAML. Cette approche garantit que la validation reste synchronis\u00e9e avec la documentation, \u00e9liminant les d\u00e9rives entre les deux.<\/p>\n\n\n\n
Rate limiting sur les routes de validation.<\/strong> Les erreurs de validation r\u00e9p\u00e9t\u00e9es depuis une m\u00eame IP signalent souvent un fuzzing automatis\u00e9. Combinez la validation avec un rate limiter par IP et par route pour d\u00e9tecter et bloquer ces scans. Notre guide sur le rate limiting dans Node.js<\/a> couvre la mise en place avec express-rate-limit et Redis pour les environnements distribu\u00e9s.<\/p>\n\n\n\n
Logging structur\u00e9 des erreurs de validation.<\/strong> Enregistrez les erreurs de validation avec l’IP source, l’user agent, le champ concern\u00e9 et la valeur rejet\u00e9e (en masquant les mots de passe). Ces logs permettent de d\u00e9tecter des patterns d’attaque et de r\u00e9pondre aux exigences d’audit RGPD en cas d’incident. Utilisez Pino ou Winston pour g\u00e9n\u00e9rer des logs JSON analysables par ELK Stack ou Datadog.<\/p>\n\n\n\n
Validation c\u00f4t\u00e9 client ET c\u00f4t\u00e9 serveur.<\/strong> La validation c\u00f4t\u00e9 client am\u00e9liore l’exp\u00e9rience utilisateur. Mais n’importe quel outil HTTP (curl, Postman, Burp Suite) peut contourner la validation front-end. Les deux niveaux sont compl\u00e9mentaires. Si vous utilisez Zod, partagez le m\u00eame sch\u00e9ma entre le front-end et le back-end dans un monorepo pour une coh\u00e9rence parfaite des r\u00e8gles.<\/p>\n\n\n\n
Versioning des sch\u00e9mas de validation.<\/strong> Les sch\u00e9mas \u00e9voluent avec votre API. Pour les APIs \u00e0 plusieurs versions (\/v1<\/code>, \/v2<\/code>), cr\u00e9ez des sch\u00e9mas distincts par version. Un changement de validation peut casser des clients l\u00e9gitimes si les r\u00e8gles deviennent plus strictes sans pr\u00e9avis. La strat\u00e9gie de versioning doit \u00eatre document\u00e9e dans votre changelog et communiqu\u00e9e aux consommateurs de l’API.<\/p>\n\n\n\n
Projet complet : d\u00e9marrage rapide<\/h2>\n\n\n\n
Voici le point d’entr\u00e9e complet int\u00e9grant toutes les couches de s\u00e9curit\u00e9 couvertes dans ce tutoriel. Ce fichier src\/app.js<\/code> peut servir de base pour n’importe quelle API Node.js en production :<\/p>\n\n\n\n
\/\/ src\/app.js - Application compl\u00e8te avec toutes les couches de validation\nconst express = require('express');\nconst helmet = require('helmet');\nconst mongoSanitize = require('express-mongo-sanitize');\n\nconst app = express();\n\n\/\/ COUCHE 1 : En-t\u00eates de s\u00e9curit\u00e9 HTTP\napp.use(helmet());\n\n\/\/ COUCHE 2 : Parsing avec limites strictes\napp.use(express.json({ limit: '10kb' }));\napp.use(express.urlencoded({ extended: true, limit: '10kb' }));\n\n\/\/ COUCHE 3 : Sanitisation NoSQL globale\napp.use(mongoSanitize({ replaceWith: '_' }));\n\n\/\/ COUCHE 4 : Routes avec validation par route\napp.use('\/api\/users', require('.\/routes\/user.routes'));\n\n\/\/ COUCHE 5 : Gestionnaire d'erreurs global\napp.use((err, req, res, next) => {\n  if (err.code === 'LIMIT_FILE_SIZE')\n    return res.status(413).json({ status: 'error', message: 'Fichier trop volumineux' });\n  if (err.type === 'entity.parse.failed')\n    return res.status(400).json({ status: 'error', message: 'JSON invalide' });\n  console.error('[ERROR]', err.message);\n  res.status(500).json({ status: 'error', message: 'Erreur interne' });\n});\n\nconst PORT = process.env.PORT || 3000;\napp.listen(PORT, () => console.log(`API d\u00e9marr\u00e9e sur le port ${PORT}`));<\/code><\/pre>\n\n\n\n
Test de l’API avec curl pour valider le bon fonctionnement :<\/p>\n\n\n\n
# Test d'une inscription valide\ncurl -X POST http:\/\/localhost:3000\/api\/users\/register \\\n  -H 'Content-Type: application\/json' \\\n  -d '{\"email\":\"alice@example.com\",\"username\":\"alice_dev\",\"password\":\"MotDePasse$ecur1t3\",\"age\":28}'\n\n# R\u00e9ponse attendue\n{\"status\":\"success\",\"message\":\"Utilisateur cr\u00e9\u00e9 avec succ\u00e8s\"}\n\n# Test avec donn\u00e9es invalides\ncurl -X POST http:\/\/localhost:3000\/api\/users\/register \\\n  -H 'Content-Type: application\/json' \\\n  -d '{\"email\":\"pas-un-email\",\"username\":\"a\",\"password\":\"court\"}'\n\n# R\u00e9ponse attendue\n{\n  \"status\": \"error\",\n  \"message\": \"Donn\u00e9es invalides\",\n  \"errors\": [\n    {\"field\":\"email\",\"message\":\"Adresse e-mail invalide\",\"value\":\"pas-un-email\"},\n    {\"field\":\"username\",\"message\":\"Nom d'utilisateur : entre 3 et 30 caract\u00e8res\",\"value\":\"a\"},\n    {\"field\":\"password\",\"message\":\"Mot de passe : minimum 12 caract\u00e8res\",\"value\":\"court\"}\n  ]\n}\n\n# Test d'injection NoSQL bloqu\u00e9e\ncurl -X POST http:\/\/localhost:3000\/api\/users\/login \\\n  -H 'Content-Type: application\/json' \\\n  -d '{\"email\":{\"$gt\":\"\"},\"password\":\"nimportequoi\"}'\n\n# R\u00e9ponse attendue : 400 - L'e-mail doit \u00eatre une cha\u00eene de caract\u00e8res<\/code><\/pre>\n\n\n\n
Ressources de r\u00e9f\u00e9rence<\/h2>\n\n\n\n