Outdated JavaScript libraries: the vulnerability nobody looks at

A site can have an up-to-date server, a valid certificate and all the right security headers, and still be vulnerable because of a file that has been loaded for years without anyone thinking about it: an old version of jQuery, an abandoned carousel plugin, a charting library copied from a tutorial.

These files don't break anything, so they stay. And that's exactly the problem.

Why it's a real risk#

Vulnerabilities in popular libraries are public. When one is discovered, it's recorded in databases such as the CVE list, along with the affected versions. An attacker then only needs to spot the version your site loads, often visible in the file name or its header, to know exactly which attack to try.

The most common vulnerabilities in these libraries are XSS flaws: they allow code to run in your visitors' browsers, for example to steal a session or alter a payment form.

Take inventory#

First step: know what your site actually loads. In the browser's developer tools, Network tab, filter on "JS" and reload the page. For each file, note the library and its version.

If your project uses npm, the following command lists dependencies with known vulnerabilities:

npm audit

And this one, the packages that have a newer version available:

npm outdated

Update without breaking everything#

Fear of regressions is the main reason updates get postponed. A few habits reduce it a lot:

• update often, in small steps: going from one minor version to the next is rarely painful, catching up on five years of delay almost always is;
• read the release notes before a major update, which flag breaking changes;
• test the critical journeys after each update: contact form, cart, payment, login;
• automate the monitoring with a tool like Dependabot or Renovate, which opens an update request as soon as a new version is released.

Files loaded from a CDN#

Loading a library from a public CDN is convenient, but you're trusting a third-party server. If it were compromised, the file served to your visitors could be modified. The integrity attribute protects against this scenario: the browser checks the file's fingerprint and refuses to run it if it doesn't match.

<script
  src="https://cdn.jsdelivr.net/npm/example@2.4.1/dist/example.min.js"
  integrity="sha384-…fingerprint provided by the CDN…"
  crossorigin="anonymous"></script>

Always pin a precise version in the URL. A URL pointing to "the latest version" can change content overnight, and the fingerprint would no longer match.

Remove what you no longer use#

The safest update is removal. A slider taken off the home page two years ago whose script is still loaded, an animation library used for a single effect: every file less is one less attack surface, and a faster page.

Codanalyst detects the JavaScript libraries loaded by your pages, identifies their version and flags those with known vulnerabilities. Check your site in a minute.