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.