Angular vs React : duel de sécurité 2019

Bienvenue dans le rapport 2019 de Snyk sur l’état de la sécurité des frameworks JavaScript.

Téléchargez le rapport ici.

Commençons par examiner les différentes vulnérabilités de sécurité découvertes dans les projets principaux Angular et React. Nous passons ensuite en revue le niveau de gravité de chaque vulnérabilité et examinons les différences entre les deux. Enfin, pour les deux projets, nous étudions le délai entre la divulgation d’une vulnérabilité et sa correction, ainsi que le délai jusqu’à la publication d’une mise à niveau (délai de correction et délai de publication) pour chaque cas.

Projet Angular principal : aperçu des vulnérabilités de sécurité

Pour étudier les projets Angular principaux, nous nous sommes intéressés plus particulièrement aux vulnérabilités de sécurité de la branche v1.x, également appelée AngularJS. AngularJS est la version obsolète d’Angular la plus utilisée. Elle a été officiellement prise en charge et maintenue jusqu’au 30 juin 2021 — AngularJS 1.7 LTS.

Nous avons représenté graphiquement le nombre mensuel de téléchargements des packages npm angular et @angular/core, qui correspondent respectivement à Angular v1.x et à Angular v2.0 et versions ultérieures. D’après les données examinées, Angular v1.x reste un acteur important de la part de marché d’Angular, représentant 28 % de tous les téléchargements d’Angular, toutes versions confondues. Bien qu’Angular ait connu depuis la version 1.x de nombreuses versions majeures, les utilisateurs continuent, dans les faits, à télécharger chaque mois des millions de fois cette ancienne version.

Le graphique ci-dessus montre à quel point les versions Angular 1.x sont populaires par rapport aux autres options Angular : les versions Angular 2.0 et ultérieures sont représentées ensemble par la ligne jaune. On constate sur le graphique qu’Angular v1.x à lui seul représente environ un tiers (28 % exactement) de tous les téléchargements d’Angular (versions récentes et anciennes) à ce jour.

Nous pouvons supposer que l’utilisation persistante des versions Angular 1.x s’explique par la présence d’applications existantes, toujours maintenues par des entreprises de taille moyenne et de grande taille. Pour ces organisations, les évolutions technologiques et les parcours de migration sont très coûteux, mais les applications doivent tout de même être maintenues et mises en production régulièrement.

Cette hypothèse souligne encore davantage la nécessité critique de suivre les vulnérabilités de sécurité dans les composants open source, comme le framework Angular, y compris dans les anciennes versions. Cela permet de corriger rapidement les vulnérabilités détectées dans les applications déployées en production et d’éviter qu’elles ne s’aggravent et ne détériorent la posture de sécurité d’une entreprise au fil du temps.

Compte tenu de ces problèmes, nous avons relevé au total 19 vulnérabilités dans six branches de versions différentes d’Angular v1.x, réparties entre les versions mineures comme indiqué dans le graphique ci-dessous.

Angular et React : des bases de données de vulnérabilités fiables sont essentielles pour détecter les problèmes de sécurité

Bien que Snyk ait suivi vingt-trois vulnérabilités de sécurité d’Angular v1.x, aucune ne possède de référence CVE, car elles n’ont pas été divulguées dans le cadre d’un programme CVE officiellement reconnu. Il ne s’agit pas nécessairement d’une lacune d’Angular, mais plutôt d’une pratique courante : les CVE ont été conçues pour les éditeurs commerciaux, et leur attribution exige beaucoup de temps et d’expertise — ce qui n’est pas toujours adapté aux projets open source.

Sans CVE, seules des personnes spécialisées peuvent suivre les vulnérabilités, en surveillant l’activité open source à l’aide de méthodes personnalisées. Peu de solutions proposent cette possibilité.

Des outils comme npm audit assurent un certain suivi, mais passent eux aussi à côté de nombreuses vulnérabilités sans CVE. Par exemple, npm audit, intégré par défaut au client npm, ne détecte malheureusement aucune des vingt-trois vulnérabilités d’Angular v1.x ni aucune des vulnérabilités de React. Se fier à npm audit peut donc donner aux développeurs un faux sentiment de sécurité.

Tout cela contraste avec la base de données des vulnérabilités de Snyk pour Angular 1.x, qui, par exemple, signale onze vulnérabilités de sécurité pour Angular v1.2.32 :

Examinons les résultats de l’analyse Snyk suivante pour un projet Angular :

Ces vulnérabilités sont signalées dans l’interface utilisateur de Snyk ou avec l’outil Snyk CLI. De plus, l’interface utilisateur de Snyk crée automatiquement des PR de correction pour mettre à niveau les packages vulnérables, grâce à des intégrations avec des systèmes comme GitHub.

La situation est similaire pour React : npm audit ne détecte aucune des trois vulnérabilités qui lui sont liées. Parmi les trois vulnérabilités connues du public (deux affectant la bibliothèque principale react et une affectant la bibliothèque principale react-dom), seule cette dernière possède un identifiant CVE suivi dans la National Vulnerability Database (https://nvd.nist.gov).

Projet React principal : aperçu

Pour ce rapport, nous avons considéré les bibliothèques react, react-dom et prop-types comme les modules « principaux » de React, car elles constituent souvent ensemble le socle des applications web développées avec React.

Pour ces modules principaux, nous avons relevé trois vulnérabilités au total : deux dans react et une dans react-dom.

Les trois sont des vulnérabilités de type cross-site scripting (XSS). Les deux vulnérabilités XSS du package npm React sont assez anciennes : elles concernent les versions 0.5.x datant de 2013 ainsi que les versions antérieures à 0.14, divulguées en 2015.

En revanche, la vulnérabilité XSS de la branche de versions v16.x de react-dom est assez récente : elle a été divulguée il y a un peu plus d’un an, en août 2018. Cette vulnérabilité ne se produit toutefois que si d’autres conditions sont réunies, par exemple lorsque la bibliothèque react-dom est utilisée dans un contexte de rendu côté serveur. Il est néanmoins toujours recommandé d’appliquer rapidement les correctifs de sécurité et de mettre à niveau vos composants open source afin d’éviter tout risque inutile.

À la une : Preact, une alternative à React

Outre ces trois vulnérabilités du projet React principal, nous avons également suivi une vulnérabilité de sécurité liée à la désérialisation de données non fiables dans Preact, de gravité modérée. De nombreux développeurs préférant Preact à React pour sa légèreté et sa rapidité, nous avons jugé utile de l’examiner de plus près. Cette vulnérabilité Preact de gravité modérée affecte les versions préliminaires de la branche 10.0.0 publiées en mars et avril 2019.

Nous vous recommandons vivement de télécharger la version complète du rapport au format numérique. Nous avons également publié les sections générales suivantes sous forme d’articles de blog :

• Rapport 2019 sur l’état de la sécurité des frameworks JavaScript

• Angular vs React : duel de sécurité 2019

• Comparaison côte à côte des vulnérabilités de sécurité d’Angular et de React en 2019

• Angular vs React : le risque de sécurité des dépendances indirectes

• Comparaison des pratiques de codage sécurisé de React et Angular

• 84 % des sites web sont affectés par des vulnérabilités XSS de jQuery