- explores the different security vulnerabilities found in the core Angular and React projects
- Reviews the severity breakdown for each of the vulnerabilities and their differences
- Reviews the time gap from when a vulnerability was disclosed until it was fixed, as well as the time gap until the time at which an upgrade was finally published (time-to-fix, time-to- release)
We start off by charting the monthly download counts for the angular and @angular/core npm packages, which represent Angular v1.x and Angular v2.0 and above, respectively.
Looks like Angular v1.x is still very much a considerable player within the Angular market-share, representing 28% of all Angular downloads across all versions.
While Angular has reached many more major version releases since 1.x, the reality is that users continue to download this older version millions of times a month.
If AngularJS (Angular 1.x) are so popular, let's look closer at the security vulnerabilities that lie within.
I didn't use
npm audit, why? see below just following this take.
So, using Snyk to scan security vulnerabilities I found 19 vulnerabilities across six different release branches of Angular v1.x, with the minor version breakdown as itemized in the graph that appears below.
Without a CVE, vulnerabilities can only be tracked by dedicated analysts who manage and track open-source activity with customized methods; few solutions provide this option.
Tools such as npm audit do some tracking, but miss many of the vulnerabilities that lack a CVE as well. For instance,
npm audit, which is bundled by default with npm client, unfortunately misses all twenty three Angular v1.x vulnerabilities and all React vulnerabilities, and so relying on
npm audit can provide developers with a false sense of confidence.
Snyk on the other hand, has tracked twenty three Angular v1.x security vulnerabilities in total, none of them includes a CVE reference because they were not disclosed through any of the officially-recognized CVE programs.
This isn’t necessarily a failing on the part of Angular, but rather common practice, as CVEs were designed with commercial vendors in mind, requiring substantial time and expertise to file – and this doesn’t always scale well for open source.
This is by the way the same case with React - where-as
npm audit is not picking any vulnerabilities, yet Snyk does.
For the purposes of this report, I considered the
prop-types libraries to be the “core” React modules since, together, they often make up the foundation for web applications built in React.
All three are Cross-Site Scripting (XSS) vulnerabilities. The two XSS vulnerabilities in the React npm package are quite old and include the 0.5.x versions dated back to 2013, and the versions prior to 0.14 that were disclosed in 2015.
The XSS vulnerability in the react-dom v16.x release branch, on the other hand, is quite recent and was disclosed just over a year ago, in August 2018.
This vulnerability, however, only occurs when other pre-conditions exist as well, such as using the react- dom library within a server-side rendering context. Nevertheless, it is always advisable to stay up-to- date with security fixes and to upgrade your open source components as early as possible, in order to avoid any unnecessary security risks.
If you're curious to read more on Angular vs React: Security Bakeoff 2019 you're welcome to download the full report
Or follow-up on any of these blog posts: