Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- Les dépendances multiplient votre surface d'exposition : Express.js implique environ 30 dépendances directes, chacune comportant ses propres chaînes transitives, ce qui signifie que l'exposition liée à la fin de vie (EOL) d'Express.js s'étend bien au-delà du cadre lui-même
- Les migrations précipitées entraînent des chaînes de middleware rompues, des régressions au niveau du routage, une instabilité du système et des dépassements budgétaires qui dépassent de loin le coût d'un support prolongé
- Les options de support étendu garantissent une couverture de sécurité continue pour les versions d'Express.js arrivées en fin de vie, tout en vous permettant de planifier vos mises à niveau selon votre propre calendrier, et non selon celui imposé par le fournisseur.
Si vous utilisez Express.js en production — et statistiquement, il y a de fortes chances que ce soit le cas —, vous avez sans doute déjà vécu ce genre de situation. Peut-être lors d’un audit des dépendances. Peut-être à la lecture d’un commentaire enfoui dans le fil de discussion d’un ticket GitHub. Peut-être lorsqu’un collègue vous a transféré un article dont l’objet commençait par « Attention… »
Express.js est à la base d’une grande partie de l’infrastructure backend d’Internet. C’est le framework qui a appris à toute une génération de développeurs à créer des API REST, et il continue aujourd’hui encore à faire fonctionner en coulisses des services essentiels dans des entreprises de toutes tailles. Lorsque des avertissements concernant la fin de vie d’Express.js commencent à apparaître dans vos rapports de sécurité, on a facilement l’impression que le sol se dérobe sous nos pieds.
Voici le truc : il n'est pas nécessaire que ce soit une crise. Vous disposez de plus d'options que vous ne le pensez. Voyons ensemble ce que la fin de vie d'Express.js implique concrètement pour votre environnement de production et, surtout, ce que vous pouvez réellement faire pour y remédier sans bouleverser votre feuille de route technique.
Comment fonctionnent réellement les mises à jour d'Express.js
Avant d'aborder la question « bon, qu'est-ce qu'on fait concrètement ? », il est utile de comprendre comment Express.js gère le cycle de vie de ses versions. En effet, contrairement à certains projets aux calendriers rigides et prévisibles, Express a toujours été un peu… plus souple sur ce point.
Express suit ce qu'on pourrait appeler un modèle de prise en charge par version majeure. Le principe de base est simple : lorsqu'une nouvelle version majeure est publiée, la version majeure précédente passe à un statut « prise en charge mais sans toutes les fonctionnalités », et continue de bénéficier de mises à jour de sécurité et de corrections de bogues critiques jusqu'à ce qu'elle soit finalement abandonnée.
Voici comment cela se traduit selon les différentes versions d'Express :
- Express v3.x a atteint sa fin de vie en juillet 2015 après avoir été remplacée par la version 4. Elle n'a plus reçu de mises à jour depuis.
- Express v4.x a été lancé en avril 2014 et bénéficie toujours d'un support officiel à ce jour, ce qui en fait l'une des versions majeures les plus anciennes de l'écosystème JavaScript.
- Express v5.x a été officiellement lancé en octobre 2024, mettant fin à la prise en charge des versions de Node.js antérieures à la v18 et apportant des modifications importantes au routage, à la gestion des promesses et aux API obsolètes.
Le problème ici ne réside pas dans la politique de cycle de vie en soi, mais dans le fait qu’Express a évolué très lentement pendant des années. La version 5 a été en développement pendant plus d’une décennie avant sa sortie officielle. Cette longue période de gestation a conduit les équipes à s’appuyer fortement sur la version 4, et celles-ci doivent désormais faire face à une migration complexe pour rester à jour.
Et si vous utilisez une version plus ancienne ? La fin de vie d'Express.js est déjà un problème d'actualité, et non plus une perspective d'avenir.
Ce que la fin de vie d'Express.js signifie réellement pour votre API en production
Bon, disons qu'une version arrive en fin de vie. Votre API fonctionne toujours. Les points de terminaison répondent. Tout semble aller pour le mieux. Alors, quel est le problème, au juste ?
Voici la vérité dérangeante concernant la fin de vie d'Express.js : ce n'est pas parce que le support prend fin que l'on cesse de découvrir des vulnérabilités. Les pirates ne consultent pas le calendrier des fins de vie avant de rechercher des failles. Et la communauté des chercheurs continue sans aucun doute de trouver des failles dans les logiciels en fin de vie largement déployés, car c'est là que se trouvent les cibles les plus intéressantes.
Express a un historique bien documenté en matière de vulnérabilités CVE qui illustre parfaitement pourquoi cela est important. Voici quelques exemples récents qui ont suscité un vif intérêt :
- CVE-2024-29041 (CVSS 6.1) : Une vulnérabilité de redirection ouverte affectant Express 4.x avant la version 4.19.0. Les attaquants pourraient créer des URL malveillantes contournant les listes d'autorisation de redirection correctement mises en œuvre à l'aide de la méthode res.location() et res.redirect() , redirigeant ainsi les utilisateurs vers des sites externes arbitraires. Cette vulnérabilité a donné lieu à la publication de bulletins de sécurité par IBM pour plusieurs produits d'entreprise, notamment IBM Watson Assistant et IBM MQ Appliance.
- CVE-2024-45296 (CVSS 7,5, Risque élevé) : Une vulnérabilité de type « déni de service par expression régulière » (ReDoS) dans path-to-regexp, une dépendance de routage essentielle utilisée par Express. Un acteur malveillant peut exploiter le backtracking dans les expressions régulières de correspondance de route pour bloquer entièrement la boucle d'événements de Node.js, provoquant ainsi la mise hors service du serveur. L'attaque ne nécessite aucune authentification ni interaction de l'utilisateur ; une seule requête HTTP spécialement conçue suffit. Cette vulnérabilité a affecté toutes les installations d'Express 4.x utilisant des versions vulnérables de path-to-regexp et a donné lieu à la publication de bulletins de sécurité par IBM pour plusieurs produits d'entreprise, dont IBM Safer Payments.
Mais voici le point crucial : sur une version d'Express.js en fin de vie, ces vulnérabilités ne sont pas corrigées. L'équipe Express ne publiera aucun correctif pour les problèmes liés à la version 3.x. Point final. Pour les équipes qui utilisent encore la version 3, et elles sont nombreuses, chaque nouvelle vulnérabilité découverte représente un risque permanent jusqu'à ce qu'elles migrent.
Pour les équipes utilisant la version 4, la situation est différente aujourd’hui (la version 4 bénéficie toujours de mises à jour), mais la tendance est claire. Express v5 existe désormais, et la version 4 finira par suivre la version 3 vers la fin de vie. Se contenter de penser « ça marche, on n’y touche pas » est exactement l’état d’esprit qui conduit à des migrations de dernière minute à terme.
Au-delà du risque immédiat pour la sécurité, les cadres de conformité sont de plus en plus clairs concernant les logiciels en fin de vie. La norme PCI DSS exige que les vulnérabilités critiques soient corrigées dans un délai de 30 jours. Les auditeurs SOC 2 posent des questions précises sur les logiciels non pris en charge utilisés en production. L'utilisation de versions d'Express.js en fin de vie ne constitue plus seulement un risque technique ; c'est aussi un problème de traçabilité.
Le risque caché : l'ensemble de votre chaîne de dépendances
Lorsque la plupart des équipes pensent à la sécurité d'Express.js, elles pensent à Express lui-même. Les routes, les middlewares, la gestion des requêtes et des réponses. C'est la couche la plus évidente.
Mais Express ne fonctionne pas tout seul. Il s'appuie sur un ensemble de dépendances directes, notamment des paquets tels que body-parser, cookie-parser, serve-static, send, path-to-regexp, qs et d'autres encore, qui gèrent en arrière-plan les fonctionnalités essentielles. Chacun de ces paquets possède son propre arbre de dépendances, et chaque dépendance constitue une source potentielle de vulnérabilité.
Une installation type d'Express 4.x implique environ 30 dépendances directes, et lorsque l'on exécute la commande « npm list » pour avoir une vue d'ensemble, le nombre total de paquets augmente considérablement. Chacun de ces paquets doit être mis à jour lorsque des vulnérabilités sont révélées, mais avec une version d'Express.js arrivée en fin de vie, bon nombre d'entre eux ne le seront pas.
L'historique des CVE illustre bien cette situation : la faille CVE-2024-43799 concernait le paquet send (une dépendance d'Express), tandis que la faille CVE-2024-43800 concernait serve-static ; toutes deux ont été révélées dans le même bulletin de sécurité de septembre 2024. Il ne s'agissait pas simplement d'une seule vulnérabilité dans un seul paquet. Il s'agissait d'un ensemble de failles liées entre elles, réparties simultanément dans l'arborescence des dépendances.
C'est ce qui rend la fin de vie d'Express.js particulièrement compliquée. Même si le code de votre application est sécurisé, votre chaîne de dépendances peut présenter des failles exploitables que l'audit npm ne détectera pas pour les paquets en fin de vie, car il n'existe aucun correctif à recommander.
Vos options lorsque Express.js arrivera en fin de vie
Bon, votre version d'Express.js est en fin de vie, ou va bientôt l'être. Quelles sont les options réalistes qui s'offrent à vous ?
Deux d'entre elles sont très complexes, coûteuses et risquées. La troisième, le support étendu, est la solution qui résout réellement le problème sans causer de perturbations, et c'est celle que la plupart des équipes auraient aimé découvrir plus tôt.
Option 1 : Passer à Express 5
Voici la réponse « officielle ». Passez à Express v5, installez les derniers correctifs de sécurité, profitez des améliorations : tout le monde y trouve son compte.
Et pour être clair : Express 5 est vraiment meilleur. Les erreurs async/await sont désormais automatiquement transmises au middleware de gestion des erreurs ; il n'est plus nécessaire d'encapsuler manuellement chaque route asynchrone dans un bloc try/catch. La bibliothèque path-to-regexp a été mise à jour vers la version 8.x, ce qui a permis de corriger une catégorie de vulnérabilités ReDoS qui affectaient le routage dans les versions précédentes. La prise en charge de la compression Brotli est intégrée. La qualité globale du code s'est considérablement améliorée après une décennie de travail progressif.
Mais voici ce que signifie concrètement la « mise à niveau vers Express 5 » pour une application de production développée sur la version 4 :
- Version minimale de Node.js : 18 Si vous utilisez une version antérieure de Node.js, vous devrez d'abord mettre à jour le runtime, ce qui a des implications en matière de compatibilité.
- Modifications apportées à la syntaxe des routes : Les routes avec caractères génériques sont passées de app.get(‘*’) à des modèles nommés explicites. Si vous disposez de dizaines de routes génériques, elles doivent toutes être mises à jour.
- Suppression des méthodes obsolètes : app.del() a été supprimée (utilisez app.delete()). req.param() a disparu. res.send(body, status) signature a disparu. Aucun de ces problèmes n'est catastrophique en soi, mais ils doivent tous être identifiés et corrigés.
- Modifications du comportement du parseur de corps : Le option est désormais false dans l'analyse urlencoded. Les applications qui s'appuient sur l'analyse d'objets imbriqués via req.body peuvent se comporter différemment.
- Comportement des middlewares asynchrones : Les gestionnaires de route qui renvoyaient auparavant des valeurs sans notification participent désormais à la gestion des erreurs d'Express. Cela peut modifier subtilement le comportement des middlewares existants.
L'équipe Express a publié des modules de conversion qui automatisent certaines de ces modifications, ce qui est vraiment utile. Pour un petit projet bénéficiant d'une bonne couverture de test, cela pourrait se faire en un sprint. Mais pour une API de grande envergure comportant des centaines de routes, des chaînes de middleware complexes et des années de modèles accumulés ? Il faudra alors une planification minutieuse, des tests exhaustifs et il y a un risque réel de régressions subtiles qui n'apparaîtront qu'une fois la charge de production en place.
Option 2 : Migration vers d'autres frameworks
Certaines équipes, face à la fin de vie d'Express.js, se disent : « Tu sais quoi, c'est peut-être notre chance. »
Fastify, Koa, Hapi, NestJS pour les applications de plus grande envergure, ou même une approche sans framework avec le protocole HTTP pur de Node.js : il existe de véritables alternatives, chacune présentant des arguments convaincants. Fastify, en particulier, a suscité un vif intérêt grâce à ses performances et à sa validation de schéma intégrée. NestJS mérite d'être pris en considération si vous vous orientez vers un développement axé sur TypeScript avec une structure bien définie.
Mais ne nous leurrons pas sur ce qu’implique réellement la migration vers un nouveau framework. Il ne s’agit pas simplement de remplacer une dépendance. Vous devez réécrire chaque route et chaque middleware en utilisant l’API du nouveau framework, refactoriser la gestion des erreurs (qui varie considérablement d’un framework à l’autre), former à nouveau votre équipe aux nouvelles conventions et à la nouvelle documentation, mettre à jour votre pile de tests (qui intègre probablement des aides spécifiques à Express) et vérifier que chaque middleware tiers dont vous dépendez dispose d’équivalents ou fonctionne avec votre nouveau framework.
La flexibilité et les avantages à long terme peuvent tout à fait justifier ce travail dans certaines circonstances. Cependant, les délais et les coûts ont tendance à dépasser largement les estimations initiales, et la maintenance du système existant pendant la mise en place du nouveau système engendre des frais de gestion supplémentaires.
Si vous envisagez de migrer vers Fastify, vous pouvez également consulter notre guide complet sur la fin de vie (EOL) de Fastify afin de comprendre les dates du cycle de vie et les risques associés.
Option 3 : Assistance étendue par un tiers
Voici une solution dont trop d'équipes ignorent l'existence : un support de sécurité étendu proposé par des entreprises spécialisées précisément dans ce domaine.
TuxCare propose une assistance à vie pour les versions d'Express.js arrivées en fin de vie. Ainsi, vous n'êtes pas obligé de procéder à une migration pour laquelle vous n'êtes pas prêt, ni de laisser vos API exposées pendant que vous planifiez celle-ci : vous continuez à utiliser votre version actuelle d'Express.js tout en bénéficiant d'une couverture continue des correctifs de sécurité.
Le principe est simple : vous gagnez du temps et du contrôle. Du temps pour planifier une migration en bonne et due forme, selon vos propres conditions. Et le contrôle sur votre calendrier de mise à jour, au lieu d'être contraint par l'échéance d'un audit de sécurité ou la publication d'une vulnérabilité CVE qui vous oblige à agir.
Le coût réel d'une mise à niveau précipitée vers la version EOL d'Express.js
Voyons ce qui se passe réellement lorsque des équipes procèdent à une migration précipitée d'une API de production parce que les avertissements de fin de vie (EOL) d'Express.js ont finalement atteint un seuil critique sur le tableau de bord de sécurité.
Lorsque cette mise à niveau doit être réalisée dans des délais irréalistes parce que les autorités de contrôle vous mettent la pression, les problèmes prévisibles ne tardent pas à surgir :
- Augmentation de la charge de travail du support : Les bugs subtils qui n'étaient pas apparus lors des tests commencent à se manifester en production. Le comportement modifié du middleware provoque des pannes intermittentes. Votre équipe d'assistance est submergée de tickets, dont la moitié est liée à la migration.
- Instabilité du système : Il se peut qu'une modification du comportement de mise en correspondance des routes perturbe l'intégration avec un service en aval. Il se peut qu'un changement de paramètre par défaut du parseur de corps de message entraîne le rejet silencieux, par un point de terminaison spécifique, de charges utiles auparavant valides. Ce sont ces problèmes qui génèrent des alertes à 3 heures du matin et des SLA très insatisfaisants.
- Accumulation de dette technique : Dans leur empressement à se mettre en conformité, les équipes commencent à prendre des raccourcis. « Nous refactoriserons cela correctement plus tard » devient une solution de contournement permanente. Six mois après la migration, vous vous retrouvez face à une base de code qui, techniquement, est sur Express 5, mais qui regorge de shims de compatibilité et de nettoyages reportés.
- Dépassements budgétaires : L'estimation initiale était de trois semaines. Huit semaines plus tard, vous êtes toujours en train de gérer des régressions. Ce prestataire que vous avez engagé pour la migration ? Il continue de facturer ses heures. Les fonctionnalités ont été repoussées. Le coût d'opportunité est bien réel et considérable.
Je ne dis pas qu’il ne faut pas mettre à niveau. À long terme, la mise à niveau est sans aucun doute la bonne solution. Je dis simplement que les mises à niveau précipitées sous la pression de la conformité constituent un risque d’échec bien réel et prévisible, et que l’argument « il faut le faire tout de suite » est rarement valable lorsqu’il existe d’autres options.
La solution simple : un support technique à vie pour les versions d'Express.js arrivées en fin de vie
TuxCare s'y emploie depuis plus de dix ans, en fournissant des correctifs de sécurité pour les systèmes d'exploitation, les environnements d'exécution, les bibliothèques et, désormais, les frameworks d'applications arrivés en fin de vie. L'entreprise a distribué plus de 220 000 correctifs de sécurité à travers l'écosystème open source. Lorsqu'elle affirme savoir comment assurer la sécurité des logiciels en fin de vie à l'échelle de l'entreprise, elle ne se contente pas d'évoquer une capacité théorique. Elle l'a déjà prouvé.
En quoi l'approche de TuxCare est-elle différente ?
Couverture complète de l'arborescence des dépendances : TuxCare ne se contente pas d’appliquer des correctifs à Express ; l’entreprise couvre également vos dépendances directes et les dépendances transitives sous-jacentes, le tout sans frais supplémentaires. Vous vous souvenez de cette longue chaîne de body-parser, serve-static, send, path-to-regexp et tout le reste ? TuxCare s’en charge. Vous ne protégez pas seulement le framework ; vous sécurisez l’ensemble de la surface de dépendance d’Express.js.
Un processus de correction optimisé et automatisé : Le processus de TuxCare combine une automatisation poussée et une validation par des experts. L'équipe surveille le NVD, les avis de sécurité des fournisseurs, les flux de sécurité GitHub et tous les endroits où les vulnérabilités EOL d'Express.js sont divulguées. Lorsqu'un CVE est publié, elle utilise des outils algorithmiques et une automatisation assistée par l'IA pour rétroporter les correctifs de sécurité, puis des experts en sécurité valident chaque correctif avant sa publication. Chaque mise à jour est soumise à des tests d'intégrité, de fonctionnalité et de régression avant d'atteindre vos dépôts. Vous souhaitez voir exactement comment cela fonctionne ? Consultez livre blanc technique de TuxCare sur son processus de correction open source.
Intégration transparente : Les correctifs de TuxCare s'intègrent directement à votre workflow npm existant. Si vous utilisez npm ou Yarn, les paquets ELS fonctionnent tout simplement. Vous n'avez pas besoin de remanier votre pipeline CI/CD ni de former à nouveau votre équipe. Vous continuez à utiliser exactement ce que vous avez déjà mis en place.
Réponse rapide garantie par un accord de niveau de service (SLA) : Lorsque de nouvelles vulnérabilités EOL d'Express.js sont révélées, TuxCare fournit des correctifs dans des délais garantis, soutenus par de véritables accords de niveau de service. Vous n'avez plus à croiser les doigts en espérant que quelqu'un finisse par rétroporter un correctif. Vous bénéficiez de mises à jour de sécurité prêtes à l'emploi sur lesquelles vous pouvez compter pour planifier vos opérations.
Rentabilité : Voici ce qui surprend la plupart des équipes à propos du support étendu : il est généralement bien moins cher que les autres solutions. Lorsque vous additionnez honnêtement le temps d'ingénierie aux tarifs horaires réels, les cycles de test, les honoraires des sous-traitants, les temps d'arrêt potentiels, les retards dans le déploiement des fonctionnalités et le coût d'opportunité, l'ELS ne représente généralement qu'une fraction de ce total. De plus, vous n'épuisez pas votre équipe avec une migration sous haute pression.
Conformité et transparence : Chaque version de TuxCare offre une visibilité complète sur les correctifs appliqués, les vulnérabilités CVE corrigées, les composants modifiés et la manière de vérifier l'ensemble de votre nomenclature logicielle (SBOM). C'est exactement ce dont vous avez besoin pour les audits PCI DSS, les examens SOC 2 et tout autre cadre de conformité qui pose des questions précises sur les logiciels en fin de vie (EOL).
Comment démarrer
Si vous utilisez des versions d'Express.js arrivées en fin de vie et que vous souhaitez connaître les correctifs disponibles, TuxCare met à jour en temps réel un outil de suivi des CVE qui vous permet de voir précisément quelles vulnérabilités ont été corrigées. Consultez les vulnérabilités et les correctifs en temps réel pour Express.
Vous souhaitez avoir une vue d'ensemble des versions prises en charge, des tarifs et de la mise en œuvre ? Rendez-vous sur la page « Assistance à vie pour Express » de TuxCare pour plus de détails.
Ne laissez pas Express.jsmette vos API en danger
Express.js a connu un parcours extraordinaire. Il a démocratisé le développement JavaScript côté serveur, il est à la base d'une part considérable des API mondiales, et il continue d'être activement maintenu et amélioré avec la version 5. Ce n'est pas rien.
Mais si vous utilisez des versions d'Express.js en fin de vie (EOL) en production, qu'il s'agisse de la version 3, qui est en fin de vie depuis 2015, ou d'une installation de la version 4 qui va finir par être dépréciée, « ça fonctionne encore » ne signifie pas pour autant « c'est encore sécurisé ».
Voici ce qu’il faut vraiment savoir : la fin de vie d’Express.js ne doit pas nécessairement vous mettre dans l’embarras. Vous avez le choix. Vous pouvez planifier une migration réfléchie vers Express 5 lorsque cela s’avère vraiment judicieux pour votre équipe et votre base de code. Vous pouvez évaluer d’autres frameworks s’il existe une véritable raison architecturale de changer. Ou vous pouvez recourir au support prolongé pour garantir la sécurité et la conformité tout en prenant ces décisions selon votre propre calendrier, plutôt que selon celui d’un audit de sécurité.
Les équipes qui gèrent efficacement les situations de fin de vie (EOL) d'Express.js ne sont pas nécessairement celles qui disposent des budgets les plus importants ou des bases de code les plus récentes. Ce sont celles qui identifient les risques dès le début, qui comprennent les ressources dont elles disposent réellement et qui font des choix mûrement réfléchis plutôt que des choix dictés par la situation.
Si la fin de vie d'Express.js vous préoccupe actuellement, cela vaut la peine de découvrir ce que propose TuxCare. Vous vous rendrez peut-être compte que la meilleure chose à faire n'est pas de vous précipiter dans une migration pour laquelle vous n'êtes pas prêt, mais plutôt de sécuriser ce que vous avez déjà développé tout en planifiant la mise à niveau que vous souhaitez réellement effectuer.
Découvrez le service « Endless Lifecycle Support » de TuxCare pour les logiciels open source pour découvrir comment une assistance prolongée peut protéger l'ensemble de votre pile open source aussi longtemps que vous en avez besoin.
