The state of JavaScript

frameworks security
report 2019

A security review of Angular and React

with a sneak peek into Vue.js, Bootstrap and jQuery

powered by
 Table of contents 2 Angular and React module ecosystems:
security risks 19
The security risk of indirect dependencies 20

Remediating vulnerable paths 21

Vulnerabilities in the Angular module ecosystem 22

Introduction 3
Vulnerabilities in the React module ecosystem 25

Spotlight: Next.js security vulnerabilities 27

A word about vulnerabilities 4

3
Key takeaways 5
Angular and React projects:
overall security posture 29

1 Angular and React core projects:

security vulnerabilities 7
Core React project: overview 8
Secure coding 30

HTTP security 31

Spotlight: Preact—a React alternative

Core Angular project: overview

Angular and React: good vulnerability databases are

9

10
4 Security vulnerabilities found in other
frontend ecosystem projects 32
key to surface security issues 12 Vue.js security 33

Angular vs. React: comparing vulnerability severities 14 Bootstrap security 34

Time-to-fix, time-to-release 17 jQuery security 35

 Introduction

In this report, we investigate the state of security for both the Angular and React ecosystems. This report by no means
intends to venture into any rivalries that may exist between the two in terms of whether one or the other is a true
framework - we are not comparing them as competitive frameworks at all. Instead, we review them each as viable
frontend ecosystem alternatives for building your JavaScript projects, while focusing on security risks and best practices
for each and the differences between them.

This report covers:

àà the security practices for each of the two different core projects, both Angular and React

àà the state of security of each of the two different module ecosystems, based on an in-depth look at the
vulnerabilities contained in each of the ecosystems

àà the security practices for other common JavaScript frontend framework alternatives such as Vue.js, Bootstrap
and jQuery

àà the significant security differences between the different alternatives, and particularly between Angular and React

This report reviews the overall security of each framework, their community-powered module ecosystems and the
associated security risks with each; based on these insights, this report ultimately provides actionable security advice for
Angular and React users by highlighting best security practices employed in the field in order to ensure secure code.

All rights reserved. 2019 © Snyk 3

 A word about vulnerabilities

In order to investigate the overall security posture of each of the ecosystems included in this report, amongst the
factors we discuss are security vulnerabilities identified in the different relevant packages. We review and discuss these
vulnerabilities on the landscape of, and sometimes in comparison to, known vulnerabilities. Known vulnerabilities have
been assigned an identification number in the list of Common Vulnerabilities and Exposures (CVEs) maintained by the
CVE Numbering Authorities (CNAs). CVEs are assigned CVSS scores that provide insight into how severe the listed
vulnerabilities are. Learn more about how the severities of vulnerabilities are scored via their CVSS here.

All rights reserved. 2019 © Snyk 4

 Key takeaways

Angular vs. React core project security Angular vs. React module
ecosystem security
àà Angular contains twenty three security vulnerabilities in its
legacy AngularJS project (Angular v1.x). àà Both React and Angular module ecosystems exhibit security

àà No security vulnerabilities were identified in the core Angular vulnerabilities in highly popular frontend library components

framework components. spanning millions of downloads, some of which have no security

fix available to date.
àà React has a few security vulnerabilities; vulnerabilities seem
to be regularly found in its core libraries and disclosed every àà We have witnessed malicious modules impacting both the

couple of years. Angular and the React ecosystems with an attempt to harvest
credit cards, passwords and other sensitive information used in
àà Only one React core project vulnerability has an official CVE
frontend web applications.
assigned. None of the reported Angular vulnerabilities are listed
by CVE at all. Together, these prove the need for a vulnerability àà The Next.js framework exhibited a great commitment to

database that taps into open source community activities, in security by swiftly addressing all five vulnerabilities found

order to surface relevant security issues. throughout the lifetime of their project, offering fixes within
just one week.
àà Snyk reports twenty six security vulnerabilities across
Angular and React core projects, which npm audit falls short of
in its reports.

All rights reserved. 2019 © Snyk 5

 Angular vs. React security posture Frontend ecosystem security

àà Angular has visible and attainable security guidelines, a àà jQuery was downloaded more than 120 million times in
security contact and a responsible disclosure policy, all of the last 12 months and according to W3Techs, jQuery v1.x
which are missing from the React project. is used in 84% of all websites using jQuery, which have four
medium severity XSS vulnerabilities affecting it. In fact, if you’re
àà Angular has broader built-in support for data sanitization and
not using jQuery v3.4.0 and above, which is true for the majority
output encoding in different contexts such as URL attributes
of jQuery users, then you are using a version that includes
in HTML anchor (or, link) elements.
security vulnerabilities.
àà React doesn’t have built-in controls for data sanitization, but
àà Bootstrap has been downloaded 79,185,409 times in the past
rather encodes output by default in most cases and leaves it
twelve months, all while containing seven Cross-Site Scripting
up to developers to address unhandled cases such as refs and
(XSS) vulnerabilities. Three of these were disclosed in 2019.
URL attributes (the latter of which is addressed in the React
Notable community modules such as bootstrap-markdown
v16.9.0 release).
have more than 300,000 downloads in the same time frame,
àà Angular includes support for Cross-Site Request Forgery
despite having no security fix or upgrade path to its XSS
(CSRF) vulnerabilities with a built-in security mechanism
vulnerabilities. bootstrap-select features more than two million
in its HTTP service. React developers need to address these
downloads and has a high severity XSS vulnerability that the
issues independently.
Snyk research team surfaced with the help of their proprietary
threat intelligence system.

àà The Vue.js framework has been downloaded more than 40

million times this past 12 months and records four vulnerabilities
in total for Vue.js core, all of which have been fixed.

All rights reserved. 2019 © Snyk 6

1
Angular and React core projects:
security vulnerabilities

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 React project: overview

For the purposes of this report, we considered the The XSS vulnerability in the react-dom v16.x release
react, react-dom, and prop-types libraries to be branch, on the other hand, is quite recent and was
the “core” React modules since, together, they often disclosed just over a year ago, in August 2018. This
make up the foundation for web applications built vulnerability, however, only occurs when other
in React. pre-conditions exist as well, such as using the react-
dom library within a server-side rendering context.
For these core modules, we found three Nevertheless, it is always advisable to stay up-to-
vulnerabilities in total; two in react and one date with security fixes and to upgrade your open
in react-dom. source components as early as possible, in order to
avoid any unnecessary security risks.
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.

All rights reserved. 2019 © Snyk 8

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.
 Core Angular project: overview

When we looked at core Angular projects, we Angular downloads per version over time
specifically investigated security vulnerabilities
in the v1.x branch, also referred to as AngularJS.
Angular v1.x Angular (newer versions)
AngularJS is the most widely-used outdated (no
longer maintained) version of Angular. 6 mil.

We charted the monthly download counts for the

angular and @angular/core npm packages,
4 mil.
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
2 mil.
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, 0
Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul
the reality is that users continue to download this 2018 2019
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.

All rights reserved. 2019 © Snyk 10

We can speculate that the continued use of Angular 1.x vulnerability count per version
Angular 1.x versions may be due to legacy
applications that are still maintained by medium
8
and large enterprises. For these organizations,
7
technology change and migration paths are very
costly, but applications still need to be maintained
6
and released regularly.

4
It is this assumption that emphasizes, even more, 4
the critical need to track security vulnerabilities 3 3
in open source components such as the Angular
framework including for older versions, in order
2

to quickly address any vulnerabilities identified in

1 1

production-deployed applications and ensure these

0
do not escalate and worsen a company’s security
1.1 1.2 1.3 1.4 1.5 1.6
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 to the right.

All rights reserved. 2019 © Snyk 11

Angular and React: good vulnerability databases
are key to surface security issues

Though Snyk has tracked twenty three Angular v1.x security vulnerabilities, none All of this is in contrast to Snyk’s vulnerability database for Angular 1.x which,
of them includes a CVE reference because they were not disclosed through any of for example, reports eleven security reports eleven security vulnerabilities for
the officially-recognized CVE programs. This isn’t necessarily a failing on the part Angular v1.2.32.
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
Version Published Licenses Direct vulnerabilities
always scale well for open source.
angular 1.6.0-rc.1
21 Nov, 2016 MIT 3  medium
(pre-release)
Without a CVE, vulnerabilities can only be tracked by dedicated analysts who
manage and track open-source activity with customized methods; few solutions angular 1.6.0-rc.0
27 Oct, 2016 MIT 3  medium
provide this option. (pre-release)

angular 1.4.14 11 Oct, 2016 MIT 3  high 6  medium

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 angular 1.2.32 11 Oct, 2016 MIT 3  high 7  medium 1  low

React vulnerabilities, and so relying on npm audit can provide developers with a
false sense of confidence.

All rights reserved. 2019 © Snyk 12

 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).

All rights reserved. 2019 © Snyk 13

Angular vs. React: comparing vulnerability severities

We can gain further insights into the overall risk To easily compare vulnerabilities, the CVSS translates
posed by the security issues that were found for its numerical scores into ranges, associating each
React-based and Angular-based frontend projects range to its severity type.
by exploring their severity scores.
An in-depth explanation of CVSS and its challenges
is available at https://snyk.io/blog/scoring-security-
What is CVSS? vulnerabilities-101-introducing-cvss-for-cve/.

To do this, we should briefly review the scoring

Throughout the report, we refer to CVSS v2 scoring,
system (CVSS). Similarly to the way in which
which is shown in the following table:
general bugs in source code are associated with
a severity such as high or medium, security bugs,
which we refer to as security vulnerabilities, are
Severity Score
also associated with a severity that contributes to
determining the potential risk for an organization. 0.1 - 3.9  low

Security vulnerabilities are assigned severity 4.0 - 6.9  medium

through the Common Vulnerability Scoring System

7.0 - 10.00  high
(CVSS), which is employed as the de-facto standard
by the FIRST organization and is widely used to
score Common Vulnerabilities and Exposures, often
referred to in short as CVEs.

All rights reserved. 2019 © Snyk 14

Angular and React: React core project vulnerability severities over time
CVSS results
While very few vulnerabilities have been discovered
7.1 6.5 6.5
within core React packages, they are all Cross-Site XSS XSS XSS

Scripting vulnerabilities and have been steadily

disclosed every couple of years. Their CVSS scores
range between 6.5 and 7.1—or, in other words, they Dec 2013 March 2015 Aug 2018

are all medium to high severity vulnerabilities.

Time of public disclosure

Looking into Angular v1.x security vulnerabilities, Angular v1.x vulnerability count per year by severity
we can see that Angular v1.5 exhibits the most
vulnerabilities, with seven vulnerabilities in
4
total-three high and four medium. Luckily, the
vulnerabilities further decrease as the version
matures, in terms of both severity and count. In 3
Low
2019, we haven’t yet seen any newly disclosed
vulnerabilities for any Angular versions at all! 2 Medium

High
1

0
2013 2014 2015 2016 2017 2018

All rights reserved. 2019 © Snyk 15

The variety of vulnerability types disclosed across Angular v1.x vulnerability by type
all Angular 1.x versions is hardly a concern but
rather, security risks manifest themselves in other
aspects. Most notable is the severity of its most Cross-site Scripting (XSS) 10
common vulnerability type, repeatedly disclosed
across versions. In fact, Cross-Site Scripting Arbitrary Script Injection 2
(XSS) vulnerabilities are a great security concern
Arbitrary Code Execution 2
across the frontend world. And this is no different
for Angular. This is reflected in the data we
Protection Bypass 1
found here, with ten XSS vulnerabilities in total
appearing across the Angular 1.x versions. Unsafe Object
Deserialization 1

Arbitrary Command
1
Execution

JSONP Callback Attack 1

Clickjacking 1

Content Security Policy

(CSP) Bypass 1

0 2 4 6 8 10

All rights reserved. 2019 © Snyk 16

Time-to-fix, time-to-release

An important factor to weigh for the security Average time to fix and release by year
posture of open source projects is how quickly
maintainers and collaborators are able to respond
Avg time to release Avg time to fix
to security vulnerabilities with timely fixes and
to publish releases for their users. We looked
60 days
at both the Angular and the React core projects
for these metrics, tracking the history of known
vulnerabilities that have already been handled in
each in order to chart this data.
40 days

Starting with Angular v1.x, the following chart

is sorted by the time period in ascending order,
starting from as early as June 2013 for the AngularJS
20 days
first vulnerability and up until June 2018. The
chart shows the number of days it took to fix a
vulnerability from when it was reported publicly to
the project and until the time it took for the team
to release a version that included the fix to which 0 days
2013 2014 2015 2016 2017 2018
downstream users could upgrade. Low time-to-
fix numbers show that the development team
could respond to a security report quickly, and low
time-to-release numbers show that the team could
quickly spin up an official fix for upgrade by users.

All rights reserved. 2019 © Snyk 17

As we can see, the first vulnerability reported React has significantly fewer vulnerabilities, with
for Angular received a fix in the code repository a mere three security vulnerabilities affecting the
within a single day, but it took 74 days for that core project. Two out of the three vulnerabilities
fix to be published as an official release to which were reported and handled internally within the
users could upgrade. React team and so the time-to-fix appears as 0 days,
with only one day to publish an official release. The
With Angular v1.x releases we observed an third vulnerability is a Cross-Site Scripting security
average of 7.47 days to fix a security vulnerability, vulnerability, dating back to React v0.4 and v0.5,
and an average of 20.5 days to publish a release which took a significant amount of time-to-fix
that included a security fix. (176 days), followed by a 27-day delay to release a
security fix.
An exception to the data on the previous page
is one JSONP Callback Attack vulnerability that
took 570 days to remediate with an actual fix,
and 64 days from the fix committed to the
source code repository, and until it was
officially released.

All rights reserved. 2019 © Snyk 18

2
Angular and React module ecosystems:
security risks

In this section, we review the security risk of the indirect independencies for both Angular and
React, and then we also review the direct dependencies, first for Angular and then for React.

The modules reviewed in this part do not represent a complete list of vulnerable React and
Angular modules; some modules may have special naming conventions (such as all modules
prefixed ng-, angular-, or react- for example) that would not appear in the pattern-based
search we conducted.
The security risk of indirect dependencies

More often than not, projects based on React Following are the security vulnerabilities that are introduced in your code right from the get-go when starting a
or Angular are generated with a scaffolding tool project by using the Angular or React boilerplate:
that provides a boilerplate with which to begin
Indirect
Vulnerable Yearly module
developing. With React, the developer go-to Boilerplate Indirect vulnerability vulnerability Fixable?
module downloads
severity
practice is to use the create-react-app npm
package that creates a pre-configured project Angular jasmine-core ReDoS  low 94,559,055 
starting point, such as by implementing the Jest
Angular useragent ReDoS  high 70,181,373 
testing framework, CSS processors and other
already built-in tooling. In Angular, this is made
React lodash Prototype Pollution  high 1,005,518,049 
possible thanks to the @angular/cli npm package.

React mdn-data MPL-2.0 License issue  high 89,291,454 

To compare the dependency health and state
of the security (which reflect the level of overall React mixin-deep Prototype Pollution  high 328,052,052 
security risk) for React and Angular boilerplates, we
React set-value Prototype Pollution  high 629,781,760 
generated a sample project which resulted in rather
good news - both of them include development
It’s worthy to note that Angular relies on 952 dependencies, which contain a total of two vulnerabilities; React
dependencies with vulnerabilities, but neither
relies on 1257 dependencies, containing three vulnerabilities and one potential license compatibility issue.
contain any production dependency security issues.
With regards to licensing, we consider license compliance to be an important factor in overall dependency health, in addition to security
issues, and for this reason include license checks in our scans as well. The results we received for licensing were based on the default
configurations that were defined for our license policies prior to scanning. Based on those results, we can see that the generated React
project has a dependency on the mdn-data package, which in turn makes use of Mozilla’s copyleft license MPL-2.0. If you plan to
distribute your React application with on-prem installations or other similar setups that include the mdn-data dependency, then you
should check licensing requirements to make sure your project complies. Additionally, we advise ensuring your projects are scanned
based on the advice you receive from your organization’s unique policies, which may or may not raise flags for additional indirect
dependencies of React as well.

All rights reserved. 2019 © Snyk 20

Remediating vulnerable paths

A path describes how an open source dependency Due to the prominent usage of lodash throughout Remediating the vulnerability requires pulling new
is introduced to your project. For instance, let’s say the ecosystem, its vulnerable version is ultimately versions of lodash from every single one of the
you have two direct dependencies called Project used by thousands of dependency paths. affected packages in the entire dependency chain.
A and Project B. Both of these projects introduce
dependency, Project C. Project C is now associated
with two different paths, because it is installed by
both Project A and Project B. If Project C includes
vulnerabilities, a developer must consider both of
these paths in order to remediate the vulnerabilities.

With React, the three vulnerabilities spread over

16,293 vulnerable paths. Remediating the vulnerability
via package upgrades becomes a daunting task with so
many packages in the dependency chain that require
an upgrade. In contrast, both Angular’s vulnerabilities
are remediated easily via only two vulnerable paths.

The following image was taken from an August

2019 security scan report for a project generated
with React’s create-react-app npm package. The
report reveals the dependency chain problem to be
addressed for a single security vulnerability.

All rights reserved. 2019 © Snyk 21

Vulnerabilities in the Angular module ecosystem

In the Angular ecosystem, module vulnerabilities

Number of Vulnerability Yearly module
manifest themselves in three areas: Module name Vulnerability type Fix exists?
vulnerabilities severity downloads

àà Angular ecosystem modules Cross-Site Scripting

ngx-bootstrap 1  medium 6,275,854 
(XSS)
àà Malicious versions of modules
Cross-Site Scripting
àà Developer tooling ag-grid-community 1  medium 2,710,764 
(XSS)

Cross-Site Scripting
ag-grid 3  medium 2,203,913 
When we look at the Angular module (XSS)

ecosystem, we can see the following modules

ng-dialog Denial of Service (DoS) 1  medium 580,674 
stand out most due to their download counts
and associated vulnerabilities: Cross-Site Scripting
angular-gettext 1  medium 514,937 
(XSS)

Access Restriction
angular-jwt 1  medium 514,470 
Bypass

Cross-Site Scripting
textangular 2  medium 384,629 
(XSS)

Cross-Site Scripting
angular-froala 1  medium 104,436 
(XSS)

Cross-Site Scripting
angular-redactor 1  medium 64,094 
(XSS)

i18n-node-angular Denial of Service (DoS) 1  high 4229 

All rights reserved. 2019 © Snyk 22

If we line up the vulnerability types based on the Vulnerability type distribution by
number of downloads of the modules that contain module download count
them, we can clearly see that XSS vulnerabilities are
at the head of the chart, as is also indicated in the
OWASP Top 10 web security risks to watch out for: 4%
4%

Cross-site Scripting

Access Restriction Bypass

Denial of Service

92%

All rights reserved. 2019 © Snyk 23

Malicious Angular modules Angular developer tooling
In total, we were able to track down three we’ve seen in angular-bmap. ng-ui-library still gets As part of the module ecosystem findings, we
malicious versions published for the following nearly 400-3000 downloads a month. spotted one module that is used as a general-
angular modules: angular-bmap, ng-ui-library, purpose HTTP server for serving single-page
ngx-pica. Joining the same malicious code that harvests credit application resources for projects built with
card information is a malicious version of ngx-pica, Angular, React, Vue and others.
angular-bmap is perhaps the least interesting as which is an Angular v5 and Angular v7 compatible
can be observed in its dependency health page module to resize images in the browser, featuring The module angular-http-server was found
- it features eight published versions all date about 800 monthly downloads. vulnerable to directory traversal - twice. Both
back to September 2017. Nevertheless, a 0.0.9 vulnerable versions are a year old and there are
version of angular-bmap has been published that Interestingly enough, all of these malicious versions already a half of a dozen newer versions published.
includes malicious code that exfiltrates sensitive were only found recently. They were all disclosed Even though the module maintainer clearly
information related to password and credit cards in June 2019, even though the malicious code was states that it is not recommended to use this tool
from forms and sends them off to the attacker pushed in a month-old release by that time. as a production-ready service, downloads for it
controlled URL of https://js-metrics.com/minjs. have been ramping up this year with a recorded
php?pl=. This malicious 0.0.9 version has been downloads count of 20,670 in May 2019.
yanked off of the npm registry.
Due to the growing adoption of this Angular HTTP
Unlike the Angular bmap module, ng-ui-library server developer tool we should point out that
is still maintained and features over 150 versions there’s a public exploit for this vulnerability.
published, seven of them in 2019 alone. However,
ng-ui-library version 1.0.987 specifically has been
found to contain the same malicious code that

All rights reserved. 2019 © Snyk 24

Vulnerabilities in the React module ecosystem

As with Angular, we found that the React ecosystem React ecosystem modules -
includes several malicious modules published at some distribution of vulnerability types
point. The following represents the distribution of
security vulnerability types and their counts across
all vulnerable modules that we found, highlighting
Cross-Site Scripting
specifically four malicious packages react-datepicker-
plus, react-dates-sc, awesome_react_utility, react- CSV Injection
server-native.
Insecure Randomness
All four malicious modules have the same malicious
Arbitrary Code
code that harvests credit card and other sensitive
Execution
information; this attack compromised modules on the
Zip Slip - Arbitrary File
React ecosystem as well. Write via Archive

Resources Downloaded
This goes further to emphasize that as a maintainer over Insecure Protocol
of an open source project it is critical to enable multi-
Malicious Package
factor authentication such as 2FA support that the npm
package registry supports, to avoid putting your users
0 1 2 3 4 5
at risk of someone else compromising your account and
Number of vulnerabilities found
publishing malicious versions of your package.

If you haven’t done so yet, we urge you to enable 2FA

on your npmjs.org developer account and follow other
npm security best practices.

All rights reserved. 2019 © Snyk 25

Notable vulnerable modules that we tracked in àà If you are working with SVGs a lot, good
React’s ecosystem: chances you are using react-svg which features
1,446,442 downloads in the past 12 months. In
àà A high severity XSS vulnerability in
April 2018 a high severity Cross-Site Scripting
react-marked-markdown which has no
vulnerability was disclosed by security
fix available, but this react component
researcher Ron Perris affecting all versions prior
wrapper around the marked JavaScript
to 2.2.18.
markdown library still gets thousands of
downloads, totaling 65,790 in the past àà A CSV Injection vulnerability in mui-datatables
12 months. disclosed in March 2019. This react library
provides a table data related UI component
àà For the preact users among you, the preact-
based on the material ui framework and
render-to-string library is vulnerable to
features more than 350,000 downloads in the
Cross-Site Scripting in all versions prior to
past 12 months.
3.7.2. This library is growing in usage across
the last 12 months and totaling in 3,228,049
downloads for this time-frame. When we track all the vulnerable React modules we
found, we count eight security vulnerabilities over
àà If you’re doing tooltips in your frontend
the last three years with two in 2017, six in 2018 and
React application you might be one of the
two up until August 2019. This calls for responsible
users of react-tooltip which received just
usage of open source and making sure you find and fix
shy of one million downloads (994,903)
vulnerabilities as quickly as possible.
in July 2019 alone. This library however
is vulnerable to Cross-Site Scripting
attacks for all versions prior to 3.8.1 as was
disclosed in September 2018.

All rights reserved. 2019 © Snyk 26

Spotlight: Next.js security vulnerabilities
Next.js is the popular React framework delivered from ZEIT, Particularly notable includes:
empowering web developers to harness their knowledge of React in
àà The team responds quickly to security disclosures by
order to build SEO-friendly web applications, Server-side rendering
releasing timely security fixes. This translates into a small
applications, Progress Web Applications (PWA) and even Electron-
window during which time there is an actual security risk;
based applications, all based on the Next.js framework.
ZEIT provides users with an upgrade path so they can quickly
mitigate the vulnerability.
Next.js continues to gain developer adoption, with 8,414,925
àà To avoid security regressions the team has written security unit
downloads over the past 12 months. As the project continues to grow it
tests to ensure that security mistakes do not repeat themselves.
becomes increasingly important to take a look at its security status.
àà Release notes clearly communicate security-related information,
We tracked three high Directory Traversal vulnerabilities, and two its impact and any steps users are required to follow in order to
medium severity Cross-Site Scripting vulnerabilities impacting the stay up-to-date with a security fix.
Next.js React framework during the course of 2017 through 2018. àà The project maintains a mailing-list dedicated to security reports,
a responsible disclosure policy and a dedicated email contact for
We should also point out that the ZEIT Security team swiftly addressed reporting issues.
all five security vulnerabilities and provided a fix through an upgrade
ZEIT and their management of the Next.js framework is a great
path for the Next.js framework within a week’s time.
example of good open source security policies; ZEIT takes matters
seriously and demonstrates a true commitment to the overall
Overall, ZEIT employs strong security practices that should be
security of their users with policies and actions that should be
replicated by other open source projects.
adopted by others.
3
Angular and React projects: overall
security posture

In this section, we explore both the Angular and the React project security postures.
This includes secure coding conventions, built-in in secure capabilities, responsible
disclosure policies, and dedicated security documentation for the project.

The following table lays out a few of the security components we found to be essential
for best-practice maintenance of any open source package, and an indication of how
Angular and React manage said components (if at all).
Security policy components

Item Angular React

 React’s website (https://reactjs.org) does not mention any security

Security page  https://angular.io/guide/security guidelines, except for the dangerouslySetInnerHTML function reference
in the DOM Elements section of the API Reference documentation.

Security contact  [email protected]  No security contact

 Backed by the internal security teams at Google and based on

Responsible disclosure
Google security philosophy.  No responsible disclosure policy
policy
Reference: https://www.google.com/about/appsecurity/

Examples of  https://angular.io/generated/live-examples/security/stackblitz.
 No references to any examples of vulnerable projects
vulnerable projects html

 DomSanitizer provides a built-in sanitization  Potentially malicious input sanitization is at the users' discretion to be
Built-in sanitization function for untrusted values. implemented via 3rd-party libraries, such as DOMPurify.
Reference: https://angular.io/api/platform-browser/DomSanitizer#sanitize Reference: https://github.com/cure53/DOMPurify

Content Security  CSP compatibility for Angular v1.x directives.

 Not relevant for React
Policy (CSP) Reference: https://docs.angularjs.org/api/ng/directive/ngCsp

 CSRF built-in support through Angular’s

Cross-Site Request HttpClient service.  Not relevant for React as a view library. This is up to the developers to
Forgery (CSRF) Reference: https://angular.io/guide/http and handle using custom code or community modules.
https://docs.angularjs.org/api/ng/service/$http

All rights reserved. 2019 © Snyk 29

Secure coding

Angular secure React secure coding practices

coding practices React by default encodes almost all data values
Angular v2 and later, have a completely To mitigate Cross-Site Scripting vulnerabilities, when creating DOM elements. To provide users with
different architecture than Angular v1, such as Angular employs by default context-aware output an escape hatch to insert HTML content into the
unidirectional data binding. What’s more, the encoding, or malicious code sanitization. Moreover, DOM, React is equipped with the eloquently-named
v2 and later versions have left automatic data method naming conventions are much better function dangerouslySetInnerHTML(), clearly
interpolation via watchers behind, as well as understood, in terms of their impact, if a developer conveying the dangers of using it.
other techniques that were often the cause for consciously chooses to use them, as opposed to
many of the Angular v1 security vulnerabilities. earlier Angular versions, namely Angular v1.x. Contexts that are unattended by the React security
model and are handled by the users include creating:
Ahead of Time (AoT) compilation mitigates issues Methods such as
àà HTML anchor (link) elements with user-
such as Angular templating expression injection bypassSecurityTrustHtml(value) or
provided input as the source for the href
and allows for build-time security instead bypassSecurityTrustUrl() implicitly convey the
attribute value. This mostly applies to versions
of run-time security. However, dynamically dangers of using them to insert data into the DOM.
prior to the recently released React v16.9 which
interpolating templates on the client-side still Moreso, Angular provides a built-in DomSanitizer to
mitigates javascript:-based URLs in href
leaves the door open for security vulnerabilities explicitly sanitize values.
attribute values and other contexts such as
in the form of Angular code injection. In their
form actions, iFrame sources, and others.
own best practices documentation, Angular
àà React components from user-provided input
clearly emphasize that this dynamic interpolating
is highly unadvisable. With respect to Angular’s
React’s server-side rendering could potentially
documentation, these are highly discouraged as
introduce XSS vulnerabilities if malicious user input
Angular’s best practices clearly point out.
is injected as-is to a JavaScript context without being
properly encoded or sanitized.

All rights reserved. 2019 © Snyk 30

HTTP security

Starting with version 1.2, Angular v1.x release branches have introduced compatibility support for Content
Security Policy (CSP) which is necessary due to the use of eval() and Function() methodology to
interpolate expressions.

Cross-Site Request Forgery (CSRF) enables web applications to trust the origin of a request. In newer
Angular versions, CSRF support mechanism is built-in to the HTTP client with the @angular/common/
http module. In Angular v1.x versions similar capability is supported through the $http provider.

Unlike Angular, React doesn’t include an HTTP client and as such, it is unable to provide CSRF support
out-of-the-box. As React aims to be a minimalistic view library, handling this concern is up to the developer,
using custom code or community-powered modules.

All rights reserved. 2019 © Snyk 31

4
Security vulnerabilities found in other
frontend ecosystem projects

After reviewing Angular and React as major JavaScript frameworks, we’ll take a brief
review of selected JavaScript and CSS frameworks: Vue.js, jQuery and Bootstrap.
Vue.js security

The Vue.js frontend framework attracts no As for Vue’s module ecosystem, we found the
less popularity from web developers than following are worth noting:
its counterparts React or Angular, and was
àà bootstrap-vue has 4,620,136 downloads
downloaded 40,054,897 times in the past 12
recorded for the past 12 months and includes a
months and featured as the second most starred
high severity Cross-Site Scripting vulnerability
project on GitHub with more than 145,000 stars.
that was disclosed in January 2019 and affects
all versions prior to <2.0.0-rc.12.
We tracked four vulnerabilities in total for Vue.js
àà vue-backbone had a malicious version
core project, three medium and one low regular
published, associated with malicious package
expressions denial of service vulnerability,
attempts that we mentioned earlier across
spanning from December 2017 to August 2018
Angular and React ecosystem modules. vue-
with a shared Cross-Site Scripting vulnerability
backbone was downloaded 11,658 in the past
that was found in React’s server-side rendering
12 months.
with react-dom component.

All rights reserved. 2019 © Snyk 33

Bootstrap security

Bootstrap is a component library that leverages All vulnerabilities have security fixes and provide an
CSS and JavaScript to enable developers to build upgrade path for users to remediate the risks.
websites and has a strong historical affiliation
with jQuery through plugins that enhance the We were also able to track several modules in the
frameowkr’s core capabilities. Bootstrap ecosystem that are vulnerable. Most
notable are:
Bootstrap is the third-most starred project
àà bootstrap-markdown with more than
in GitHub with more than 130,000 stars, and
300,000 downloads in the past 12 months
79,185,409 downloads in the past 12 months
despite having an unfixed Cross-Site Scripting
from the npm package registry. Modern web
vulnerability affecting all versions
application frameworks like React have even
àà Vue.js developers using bootstrap-vuejs had
extended Bootstrap by packaging it for React
their usage of this module contributed to
based web development with projects like
4,620,136 downloads in the past 12 months
reactstrap and react-bootstrap which receive
and worth to note that a recently disclosed
about 20 million downloads each in the past
high severity Cross-Site Scripting vulnerability
12 months.
affects all versions prior to bootstrap-vue
2.0.0-rc.12 which only a February 2019 release
As we look at known security issues for the
had addressed.
Bootstrap project, we can track a total of seven
Cross-Site Scripting vulnerabilities, three àà bootstrap-select featured 2,159,450 downloads
of which were disclosed in 2019 for recent in the past 12 months and has a high severity
Bootstrap v3 versions, as well as three security Cross-Site Scripting vulnerability that the Snyk
vulnerabilities disclosed in 2018, one of which research team surfaced thanks to its threat
affects the newer 4.x Bootstrap release. intelligence system.

All rights reserved. 2019 © Snyk 34

jQuery security

jQuery took web development by storm a decade only recently, on 10th of Apr, 2019, then you are using version 2 and 3 lag far behind with roughly 8% of all
ago but since then web development have been vulnerable jQuery versions. jQuery usage. When looking at the known security
revolutionized further with single page application vulnerabilities and map them out to jQuery versions
technologies such as Angular, and React. That said, Since jQuery is usually found in web applications as a we found that four medium severity Cross-Site
according to W3Techs which regularly run surveys legacy component it is important to also understand its Scripting vulnerabilities are affecting jQuery v1
and report on web technology usage jQuery is version usage patterns and their state of security. which is potentially concerning considering the
being used within 73% of websites they scanned in 83.4% market share for anybody not employing
August 2019. W3Techs reports that of all websites using jQuery, software composition analysis to find and fix
it’s 1.x release is dominating with 83.4% of share and vulnerabilities in their open source components.
A Snyk study from 2017 further amplifies this
when it reported that 77% of sites use at least
one vulnerable JavaScript library and pointed out jQuery vulnerability count by version
jQuery was detected in 79% of the top 5,000 URLs
from Alexa. If you’re still not convinced, npm’s 29%
downloads for the jQuery npm module account to
120,641,977 for the last 12 months alone.
jQuery 1.x

In total, we tracked six security vulnerabilities jQuery 2.x

affecting jQuery across all of its releases to date,
54%
four of which are medium severity Cross-Site jQuery 3.x
Scripting vulnerabilities, one is a medium severity
Prototype Pollution vulnerability, and lastly, one is
a low Denial of Service vulnerability. If you’re not
17%
using jQuery 3.4.0 and above which was released

All rights reserved. 2019 © Snyk 35

Many websites and web applications will further jQuery library Vulnerability Yearly module
Vulnerability type Disclosure date Fix exists?
make use of jQuery libraries to extend the name severity downloads

capabilities of jQuery and will turn to community- jquery-airload Malicious Package 2019-08-06  high 322 n/a
powered libraries to do so. jquery.json-
Cross-Site Scripting 2019-07-03  medium 17,898 
viewer
github-jquery-
We found 13 vulnerable jQuery libraries as Malicious Package 2019-06-07  high 232 n/a
widgets
provided in the following table and offer the
jquery-mobile Cross-Site Scripting 2019-05-04  medium 54,991 
following observations:
jquery-file- Arbitrary Code
2018-11-02  low 19,442 
àà Three jQuery libraries are malicious versions upload Execution

of open source community modules. As we jquery.terminal Cross-Site Scripting 2018-08-19  medium 79,982 
can’t account for the downloads of the actual jquery.csssr. Regular Expression Denial
2018-02-13  high 3,069 
vulnerable versions since this isn’t available validation of Service (ReDoS)

from the npm registry, we should call out jquery-colorbox Cross-Site Scripting 2017-11-14  medium 268,513 
jquery.js which is a malicious package and jquery.js Malicious Package 2017-08-02  high 5,444 n/a
accounted for 5,444 downloads in the past
jquery-ui Cross-Site Scripting 2016-07-21  high 8,934,683 
12 months.
Cross-Site Request
àà jQuery libraries jquery-mobile, jquery-file- jquery-ujs 2015-06-24  medium 5,763,710 
Forgery (CSRF)
upload and jquery-colorbox account to jquery-migrate Cross-Site Scripting 2013-04-18  medium 1,831,735 
more than 340,000 downloads in the past
Cross-Site Request
jquery-ui 2012-11-26  medium 8,934,683 
12 months, despite including Arbitrary Code Forgery (CSRF)
Execution and Cross-Site Scripting security jquery-mobile Cross-Site Scripting 2012-08-01  medium 54,991 
vulnerabilities and not having any upgrade
jquery-ui Cross-Site Scripting 2010-09-02  medium 8,934,683 
path to remediate them.
Malicious packages have no fix information.

All rights reserved. 2019 © Snyk 36

 Use open source. Stay secure.

Twitter: @snyksec Report author: Liran Tal (@liran_tal)

Web: https://snyk.io

Thank you to our friends, and community leaders, Chris Heilmann

(@codepo8), Ron Perris (@ronperris), Daniel Rufde (@danielrufde),
Office info
Stephen Fluin (@stephenfluin), Sebastian Markbåge

London Tel Aviv Boston (@sebmarkbage) and Rachel Cheyfitz (@spinningrachel)

who took the time to provide technical reviews of this report.
1 Mark Square 40 Yavne st., first floor WeWork 9th Floor
London EC2A 4EG 501 Boylston St
Boston, MA 02116 Report design: Growth Labs (@GrowthLabsMKTG)