Angular vs React: security bakeoff 2019
2019年10月30日
0 分で読めますWelcome to Snyk's State of JavaScript frameworks security report 2019.
Let’s begin this report by exploring the different security vulnerabilities found in the core Angular and React projects. We then review the severity breakdown for each of the vulnerabilities and we inspect the differences between the two. Lastly, for both projects, we review 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) for each of the cases.
Core Angular project: security vulnerabilities overview
When we looked at core Angular projects, we specifically investigated security vulnerabilities in the v1.x branch, also referred to as AngularJS. AngularJS is the most widely-used outdated version of Angular, officially supported and maintained until June 30, 2021- AngularJS 1.7 LTS.
We charted the monthly download counts for the angular and @angular/core npm packages, which represent Angular v1.x and Angular v2.0 and above, respectively. According to the data we reviewed, we found that 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.
The above graph demonstrates just how popular the Angular 1.x versions are relative to the other Angular options: the Angular 2.0 and above versions are represented together by the yellow line; we can see from the graph that Angular v1.x alone represents about a third (28% to be exact) of all Angular (new and old) downloads ever.
We can speculate that the continued use of Angular 1.x versions may be due to legacy applications that are still maintained by medium and large enterprises. For these organizations, technology change and migration paths are very costly, but applications still need to be maintained and released regularly.
It is this assumption that emphasizes, even more, for the critical need to track security vulnerabilities in open source components such as the Angular framework including for older versions, in order to quickly address any vulnerabilities identified in production-deployed applications and ensure these do not escalate and worsen a company’s security posture over time.
With these issues in mind, in total, we 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.
Angular and React: good vulnerability databases are key to surface security issues
Though Snyk has tracked twenty threeAngular v1.x security vulnerabilities, 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.
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 auditdo 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 auditcan provide developers with a false sense of confidence.
All of this is in contrast to Snyk’s vulnerability database for Angular 1.x which, for example, reports eleven security reports eleven security vulnerabilities for Angular v1.2.32:
Version | Published | License | Direct vulnerabilities |
|
| MIT | 3 medium |
|
|
|
|
|
|
| |
|
| 3 high |
Let's look at the following Snyk scan results for an Angular project:
These vulnerabilities are reported through the Snyk UI or the Snyk CLI tool. What's more, the Snyk UI automatically creates fix PRs to upgrade vulnerable packages for the developers, through integrations with systems such as GitHub.
The situation with React is similar - npm audit misses all three React related vulnerabilities. Out of the three publicly known vulnerabilities (two affecting the react core library, and one affecting the react-dom core library), only the latter has a CVE assigned that is tracked in the National Vulnerability Database (https://nvd.nist.gov).
Core React project: overview
For the purposes of this report, we considered the react, react-dom, and prop-typeslibraries to be the “core” React modules since, together, they often make up the foundation for web applications built in React.
For these core modules, we found three vulnerabilities in total; two in react and one in react-dom.
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.
Spotlight: Preact — a React alternative
In addition to these three core Reach project vulnerabilities, we also tracked a medium Deserialization of Untrusted Data security vulnerability in Preact. As many developers prefer Preact over React, for being lightweight and faster, we thought it was worth having a closer look. This medium-severity Preact vulnerability affects the 10.0.0 pre-release branch versions from March and April 2019.
We highly recommend downloading the full version of the report in its digital format, but have also made the following general sections available as blog posts: