they are less commonly used on the
homepages of websites.
While the majority of libraries used
in Alexa are hosted on the same domain as the website, most inclusions
are loaded from external domains in
.COM. In the case of jQuery, 59% of
all inclusions in Alexa websites are
internal, and 39% are external. The remainder are inline inclusions where
the source code of the library is not
loaded from a file but directly wrapped
in <script> // library code here
</script> tags. Only 30% of the websites in the .COM crawl host jQuery internally, whereas 68% rely on external
hosting. This highlights a difference
in how larger and smaller websites include libraries.
In both crawls, JavaScript CDNs are
among the most popular domains from
which libraries are loaded. In Alexa,
almost 18% of library files are loaded
from ajax.googleapis.com, Google’s JavaScript CDN (13% in .COM), followed
by jQuery’s branded CDN code.jquery.
com (4% in Alexa, 3% in .COM). The
less popular sites in the .COM crawl,
however, also frequently load libraries
from domains related to domain parking and hosting providers.
When looking at why libraries are
included, it turns out that around
3% of jQuery inclusions in Alexa and
almost 26% in .COM are caused by
advertisement, tracking, or social
media widget code. For SWFObject,
more than 42% of inclusions in Alexa
come from ads. In other words, the
blame for including a now-unsup-ported library does not go directly to
those websites but to the ad networks
they are using. Advertisement, tracking, or social media widget code is
typically provided by an external service and loaded as is by the website
developer—who may not be aware
that the included code will load additional libraries and who has no say in
which versions of these libraries will
be loaded. Overall, libraries loaded
by ads can be found on 7% of sites in
Alexa, and on 16% of sites in .COM.
… And How They
Include Vulnerabilities
We compiled metadata about vulner-
able versions of the 11 libraries shown
in Figure 1. Among the Alexa sites, 38%
use at least one of these 11 libraries in
a version known to be vulnerable, and
10% use two or more different known
vulnerable versions. In .COM, the vul-
nerability rates are slightly lower—37%
of sites have at least one known vulner-
able library, and 4% two or more—but
the sites in .COM also have a lower rate
of library use in general. As a result,
those .COM sites that do use a library
have a higher probability of vulnerabil-
ity than those in Alexa.
Looking at individual libraries
shows that known vulnerable versions
can make up a majority of all uses of
those libraries in the wild. jQuery, for
example, has around 37% known vul-
nerable inclusions in Alexa, and 55% in
. COM. Angular has 39%–40% vulnerable
inclusions in both crawls, and Handle-
bars has 87%–88%. This does not mean,
however, that Handlebars is “more
vulnerable” than jQuery; it means only
that Web developers use known vulner-
able versions more often in the case of
Handlebars than for jQuery. The em-
phasis here is on known vulnerable, as
each library may contain vulnerabilities
that are not known. In that sense, these
results are a lower bound on the use of
vulnerable libraries.
So far, we have examined whether
sites are potentially vulnerable—that
is, whether they include one or more
known vulnerable libraries—and how
that adds up on a per-library level. Now
let’s return to our analysis of how li-
braries are included by sites. Figure 5
shows two prominent factors that are
connected to a higher fraction of vul-
nerable inclusions:
˲ Inline inclusions of jQuery have
a clearly higher fraction of vulnerable
versions than internally or externally
hosted copies.
˲ Library inclusions by ad, widget, or
tracker code appear to be more vulner-
able than unrelated inclusions. While
the difference is relatively small for
jQuery in Alexa, the vulnerability rate
of jQuery associated with ad, widget, or
tracker code in .COM—89%—is almost
double the rate of unrelated inclusions.
This may be a result of less reputable ad
networks or widgets being used on the
smaller sites in .COM as opposed to the
larger sites in Alexa.
At this point, a word about the limi-
tations of our study is in order. We do
not check whether a known vulnerabil-
ity in a library can be exploited when
An important
aspect of our
research was
finding out who
is to blame for
the inclusion of
vulnerable libraries.