Skip to main content

Study: One-Third Of Websites Use Outdated, Insecure JavaScript Libraries

Websites are only as safe as their operators allow them to be. Researchers find vulnerabilities, and organizations release patches for them all the time. But it's up to site operators to install those patches to make sure their sites don't endanger visitors and, potentially, their personal information. Many don't, as Northeastern University discovered when it found that 37% of sites use outdated JavaScript libraries with at least one known vulnerability.

The Northeastern University researchers scanned 75,000 of Alexa top websites and 75,000 more websites randomly taken from "a snapshot of the .com zone in May 2016." They found that more than one-third of Alexa's top websites use one JavaScript library with a known vulnerability. Another 10% use two or more libraries with known security problems. Roughly 97% of the sites wouldn't be able to fix all their vulnerabilities with a few quick patches.

This means that many website operators who haven't bothered to regularly patch their JavaScript libraries will now have to install whole new libraries to address all their security vulnerabilities. That seems unlikely at best--many of these websites use outdated libraries for a reason, and it's probably not because their owners are infatuated with old tech. It's most likely because the sites have been abandoned or simply aren't made with security in mind.

Not that JavaScript library creators and maintainers have made things easier for website operators. As the researchers said in their paper, titled Thou Shalt Not Depend on Me: Analysing the Use of Outdated JavaScript Libraries on the Web:

Perhaps our most sobering finding is practical evidence that the JavaScript library ecosystem is complex, unorganised, and quite 'ad hoc' with respect to security. There are no reliable vulnerability databases, no security mailing lists maintained by library vendors, few or no details on security issues in release notes, and often, it is difficult to determine which versions of a library are affected by a specific reported vulnerability.

Those aren't small problems. The researchers said that 87.7% of Alexa websites and 46.5% of the randomly selected websites use "at least one well-known JavaScript library" such as jQuery, Handlebars, and Angular, among others. These open source libraries are used by millions of sites that weren't analyzed by Northeastern University; it's hard to imagine that you've never visited a site that uses at least one of them.

Vulnerabilities in these and other JavaScript libraries can cause all sorts of headaches. Website operators might worry about someone exploiting a vulnerability to inject code on their site; you might worry more about someone abusing a security flaw to gather your personal information. The researchers explained:

Attackers can use these capabilities to steal data from a user’s browsing session, initiate transactions on the user’s behalf, or place fake content on a website. Therefore, JavaScript libraries must not introduce any attack vectors into the websites where they are used.

None of that sounds like fun. But the researchers also found that many popular JavaScript libraries don't share any security problems with devs:

During this entire work, we did not encounter a single popular library that had a dedicated mailing list for security announcements (in fact, most libraries we investigated did not have a mailing list for announcements at all). Furthermore, only a few JavaScript library developers provide a dedicated email address where users can submit vulnerability reports. When the release notes of libraries mention at all that a vulnerability has been fixed, they often do not provide any details about the affected code, or which prior versions are vulnerable.

The end result: nigh ubiquitous JavaScript libraries that don't help website operators keep you safe. The websites themselves, their users, and personal information about an untold number of people could all be vulnerable to attack simply because developers didn't know they were using outdated JavaScript libraries or weren't sure if using an old version of the tech would undermine their website's security.

  • Morbus
    There's no such thing as an insecure JavaScript library, is there?
    I'm not an expert, but if it's client-side, you can use whatever library you like, there's no point in security, because the user is always king.
    I could be wrong, of course, but I don't really see an instance where JavaScript security is ever a thing. It's like locking your curtains or covering your money with a drinking glass.
    Reply
  • brucek2
    @Morbus, I had the same thought. Since any user can substitute their own JavaScript any time, if there's any insecurity here it feels like it must be in the web standards or their implementations themselves.
    Reply
  • grant barker
    Thanks for this article. It reminded me to update about 30% of my pages to the latest version on jquery.
    Reply
  • josejones
    This article doesn't mention how to check the JavaScript library for updates and patches.
    Reply
  • michalt
    @morbus A lot of web sites are developed using server side JavaScript. Look up node.js as one of the recently popular development stacks.
    Reply
  • brucek2
    19426249 said:
    @morbus A lot of web sites are developed using server side JavaScript. Look up node.js as one of the recently popular development stacks.
    Fair enough, but this particular study must be talking about client side JavaScript, no? Because they wouldn't have access to know what was running on the server...

    Reply
  • Marissaryan
    Could there be MORE ads on this site? I was going to share this article on my social profiles, but i dont feel comfortable sending my audience to such a spam-filled landing page.
    Reply
  • B_Sterner
    @morbus, only as a quick example.

    A page pulls information from the URL with client-side JavaScript. In the function that handles the path, there is a eval() statement. Now someone posts a link on a website to the new article/post on somesite.com and slips some code in the link.

    - This code in the link is then evaluated, runs a script and sends your cookie information, username, anything it can get, to a remote server. Perhaps on a payment site in forwards your payment info next time you purchase something.

    - Maybe the bad link dynamically changes the download link of a download page. The installer thinks they are downloading something from the current site, but it instead downloads from evilsite.com.

    - Maybe someone has figured a way to upload a script on sub-domain.somesite.com. Now they set document.domain = "somesite.com" and then uses an altered link to incorporate that script. Now that script will run as if from the same domain.
    Reply