77% of sites use at least one vulnerable JavaScript library

The other week a paper was released that reported that about 37% of sites included at least one JavaScript library with a known vulnerability. When we wrote about the findings, we mentioned that we thought that the reality was almost certainly worse.

It is. Much worse, in fact.

We ran our own test using the top 5,000 URLs from Alexa and discovered that a whopping 76.6% of them include at least one vulnerable library. If you’re curious how we conducted the test, the details are below or feel free to skip to the results.

The test

To run the tests, we grabbed the top 5,000 URLs from Alexa. We ended up with several URLs that errored when we tried to reach them, so we kept going further down the Alexa list until we ended up with 5,000 pages that all successfully loaded.

Each URL was run through WebPageTest. WebPageTest loaded each page in Chrome, and then executed some custom JavaScript to identify the version of a few JavaScript libraries.

For example, to determine the version of jQuery in use, each page would run the following code after page load:

return jQuery && jQuery.fn && jQuery.fn.jquery

We included checks for each of the following libraries in this initial run:

• jQuery

• Handlebars

• Mustache

• React

• Angular

• Ember

• jQuery UI

• YUI

• Dojo

For each detected version, we then checked against the Snyk open-source vulnerability database to see just how many libraries had a known vulnerability.

The not-very-pretty results

As we mentioned above, the state of JavaScript library security was shockingly bad—there’s just no sugar coating it. Of the 5,000 sites, 3,831 of them (76.6%) are including a JavaScript library with at least one known vulnerability in it.

It sounds odd to say given the high percentage already, but just as with the original report, the reality is probably worse. We’ve tested nine JavaScript libraries here. The list of JavaScript frameworks and libraries available to developers would include hundreds upon hundreds of options. The ones we tested are among the most popular, so it’s unlikely the percentage would jump too dramatically, a few additional percentage points would be a near certainty.

And again, this is just checking client-side, third-party JavaScript libraries for known vulnerabilities. Server-side usage is not considered here, nor is custom written JavaScript. And new vulnerabilities are added to our database daily—more exist, even if they’re not publicly known yet.

jQuery

jQuery is, unsurprisingly, the most popular library we tested—its incredible dominance is well documented by now. We were able to detect jQuery in 79% of the top 5,000 URLs.

Despite not being a particularly vulnerable library (there are five known vulnerabilities, each fixed in later versions), jQuery’s popularity means it makes quite a bit of mess all by itself.

As it turns out, even if we only checked for jQuery, we still end up with 75.1% of sites using a version with at least one vulnerability. This is due in large part to just how old most of the jQuery libraries in production are. 17.4% of jQuery versions found in production are older than five years. This lines up pretty well with the initial report: people don’t update very regularly.

Further complicating the matter for jQuery users is that the only versions with no known vulnerabilities are >=3.0.0. For many current users, that’s means that updating is not as simple as adding a minor version upgrade—there are potentially breaking changes involved. Roughly 79% of jQuery libraries detected were version 1.x. Despite the fact that jQuery 3.0.0 final was released nearly a year ago, only 3.6% of sites were using any 3.x versions.

We’ll dig into jQuery in more detail in post next week, as its unparalled popularity makes it especially interesting.

jQuery UI

jQuery UI was next in terms of popularity—found on 19.3% of the URLs tested. Once again, most jQuery UI users are using a vulnerable version despite updates being available. About 91% of jQuery UI libraries found have at least on vulnerability.

Again, much of this is due to people not updating—21.8% of sites that used jQuery UI use a version that is more than 5 years old.

Handlebars

Handlebars was detected on 3.4% of the URLs tested. Of those, 68% were using a vulnerable version of Handlebars.Once again, the slow adoption of new versions is the primary culprit. On the surface, it would appear that Handlebars usage is a little more current. While the most recent version of the library (4.0.6) was not detected, the version released immediately before it (4.0.5) is also the most common one found in production, at 26.7% of Handlebars usage.

However, due to a slowed-down release schedule (they’ve released only two minor versions since November of 2015) that means those sites are still using a version of the library that is nearly two years old. Over all, 40% of Handlebars versions detected were over three years old.

React, Mustache, Angular, YUI and Dojo

React (1.7%), Mustache (1.6%), Angular (1.3%), YUI (.7%) and Dojo (.2%) were detected too infrequently to draw any reliable conclusions about the use of them individually. When you look at their usage combined, vulnerable versions are still very common: 56.3% of the versions of these libraries found in the data have at least one vulnerability.

Our hopeful conclusion

The situation right now is not great, there’s no denying it. While we expected that the original number may be optimistic, we can’t say we were expecting that 77% of sites would be using at least one vulnerable library.

And to be clear, there’s no single item that will fix this problem. Instead, what we need is a combination of improving awareness, better tooling, and a simpler method of maintaining JavaScript dependences on the front-end (package manager adoption is not as widespread as for back-end development)—for a start.

But as we’ve said before, we remain hopeful. Securing third-party JavaScript is a solvable problem—it just requires a little more uphill sledding than originally thought.

Because of the sensitivity of a report like this, we will not be sharing the raw data—that would essentially be handing folks a shortlist of sites and potential attack vectors. However, if you’re a website owner, you’re welcome to contact us to see if your site was in the report and, if so, whether a vulnerability was discovered. If you’re using npm packages, testing your application with Snyk may also help you to uncover potential security holes.