developers need to be aware of which
libraries they are using. It is too easy to
forget about a library when it is manu-
ally copied into the codebase. Instead,
we recommend explicitly declaring a
project’s dependencies in a central lo-
er ( https://bower.io/) was one of the
first dependency management tools.
Yarn ( https://yarnpkg.com/) is a more
recent entry to the scene, backed by
the repository of NPM (Node Package
which contains not only server-side
Node.js packages, but also client-side
cies make it easy to automatically in-
clude the library code of the declared
version into the project. Additionally,
tools such as Retire.js (https://retirejs.
github.io/retire.js/), AuditJS (https://
Snyk ( https://snyk.io/) can scan the de-
clared dependencies for known vulner-
able versions. Ideally, Web developers
should make such tools part of their
build process, so that attempts to in-
clude a known vulnerable library cause
a build to fail. For projects where such
a proactive approach is not an option,
Retire.js also has a browser extension
that can detect vulnerable libraries in
Library development. The development practices adopted by library
maintainers have a big influence on
how difficult it will be for library users
to keep their dependencies up to date.
To that end, we conducted an informal
survey of the 12 most frequently used
libraries (Figure 4).
Before developers can update the
libraries they are using, they must be
made aware that there is a need to update. None of these 12 libraries, however, seems to maintain a mailing list
or other dedicated channel for security
announcements. Some libraries have
Twitter accounts, but these contain a
lot of additional “noise” unrelated to
new releases or security issues. None of
the libraries appears to systematically
allocate CVE (Common Vulnerabilities
and Exposures) numbers or register
security issues in popular vulnerability
databases. Only Angular prominently
highlights patched vulnerabilities in
the release notes of new library versions; the other libraries often mention
unspecific “security fixes” along with
a long list of other changes, if they are
mentioned at all.
In addition to the difficulty of finding out about vulnerabilities, it is very
rare to find information about the
range of versions affected by a vulnerability. Given this general lack of
readily available information, security-conscious users of a library do not have
much of a choice other than to update
every time a new version is released.
Updating is often “painful,” however,
for a number of reasons ranging from
the short release cycles common in
Web library development to breaking
API changes and the need for testing
after each library update.
To end this survey on a positive note,
we highlight the security practices followed by Ember ( https://emberjs.com).
Its maintainers commit to patching
long-term support releases so that library
users do not need to deal with frequent
breaking API changes. Ember maintains
a security announcement mailing list,
registers CVE numbers, mentions secu-
rity issues in release notes, lists the range
of versions affected by a vulnerability,
and provides a dedicated email address
to report security issues. These practices
ease the burden of dealing with vulner-
abilities. Let’s hope that other library
maintainers will follow suit.
Third-party components. The previous paragraphs assumed that website
developers directly include libraries,
which makes it their responsibility to
keep them up to date. The results of the
Web crawls, however, show that this assumption often does not hold in practice. In fact, many website developers
load external scripts such as advertisements, tracker code, or social media
widgets. These third-party components
sometimes include libraries on their
own. This study has shown that such behavior may cause duplicate inclusions
of a library, and that these indirect inclusions come with a higher rate of vulnerability. Under some circumstances,
sandboxing the third-party code in an iframe may be an option to limit the damage. In general, however, website developers must rely on the maintainers of
these components to update their code.
and many of them are known to be vulnerable. Understanding the scope of
the problem, and the many unexpected ways that libraries are included, are
only the first steps toward improving
the situation. The goal here is that the
information included in this article
will help inform better tooling, development practices, and educational efforts for the community.
Dismantling the Barriers to Entry
Tobias Lauinger is a Ph. D. student at Northeastern
University with an interest in Internet-scale
measurements of everything security and beyond.
Abdelberi Chaabane is a security researcher at Nokia
Bell Labs whose work focuses on empirical large-scale
studies to measure and understand online threats.
Christo B. Wilson is an associate professor at
Northeastern University whose work focuses on security
and privacy on the Web, and algorithmic transparency.
Copyright held by owners/authors.
Publication rights licensed to ACM. $15.00.
Figure 4. Top 12 libraries by frequency in
jQuery 84% 61%
jQuery-UI 24% 8%
Modernizr 21% 9%
Bootstrap 13% 5%
jQuery-Migrate 11% 11%
Underscore 6% 2%
SWFObject 4% 2%
Moment 4% 1%
RequireJS 3% 2%
jQuery-Form 3% 3%
Backbone 3% 2%
Angular 2% 2%
Figure 5. Vulnerable fraction of JQuery
All Inclusions 37% 55%
Internal 38% 42%
External 35% 63%
Inline 55% 90%
Ad/Widget/Tracker 38% 89%
No Ad/ Widget/ Tracker 37% 46%