Dangerous JavaScript Libraries: How to Audit Your Frontend Dependencies

Your website's backend might be fully patched, your server hardened, and your firewall configured perfectly – but if your frontend loads a JavaScript library with a known XSS vulnerability, none of that matters. Attackers can exploit vulnerable client-side libraries to steal session cookies, redirect users to phishing pages, or inject cryptocurrency miners.

This guide covers how to find, evaluate, and remediate vulnerable JavaScript libraries on your site, whether you built it from scratch or run WordPress with a dozen plugins each bundling their own copy of jQuery.

The Scale of the Problem

A 2023 study by Snyk found that 77% of websites use at least one frontend JavaScript library with a known vulnerability. The most common offenders are not obscure packages – they are the most popular libraries on the web:

• jQuery < 3.5.0 – multiple XSS vulnerabilities including CVE-2020-11022 and CVE-2020-11023, which allow attackers to execute arbitrary JavaScript through crafted HTML passed to jQuery's DOM manipulation methods
• Lodash < 4.17.21 – prototype pollution vulnerability (CVE-2021-23337) that allows property injection on all JavaScript objects
• Angular.js 1.x – end-of-life since December 2021, with multiple known sandbox escapes that bypass template injection protections
• Moment.js – while the library itself has had ReDoS vulnerabilities, the larger issue is that it is in maintenance mode with no active security support
• Bootstrap < 3.4.1 and < 4.3.1 – XSS through tooltip and popover attributes (CVE-2019-8331)

How Attackers Exploit Vulnerable Libraries

A vulnerable JavaScript library does not automatically mean your site is compromised. Exploitation requires a way to trigger the vulnerability. Common attack paths include:

Stored XSS via jQuery DOM Manipulation

If your application passes user-controlled input to jQuery's .html(), .append(), or similar methods, and you are running a version with CVE-2020-11022, an attacker can inject executable JavaScript through crafted HTML that bypasses sanitization:

// Vulnerable pattern: user input passed to .html()
$('#output').html(userProvidedContent);

// Exploit payload that bypasses jQuery < 3.5.0 sanitization
<style><style/><img src=x onerror=alert(document.cookie)>

Prototype Pollution via Lodash

Prototype pollution allows an attacker to inject properties into Object.prototype, affecting every object in the application. In a server-side Node.js context, this can lead to remote code execution. On the client side, it typically enables XSS or logic manipulation:

// Lodash merge with attacker-controlled input
_.merge({}, JSON.parse('{"__proto__": {"isAdmin": true}}'));

// Now every object has isAdmin === true
console.log({}.isAdmin); // true

Step 1: Scan Your Site Automatically

The fastest way to find vulnerable libraries is an automated scan. Our JavaScript Vulnerability Scanner loads your page in a headless browser, detects every JavaScript library and its version, and checks each one against vulnerability databases including Snyk and the npm advisory database.

The scanner catches libraries that are:

• Loaded directly in <script> tags
• Bundled into webpack or other build tool output
• Loaded from third-party CDNs
• Injected dynamically by WordPress plugins or ad scripts

Step 2: Manual Verification

Open your browser's developer tools and check the Console and Sources tabs. Many libraries expose their version globally:

// Check common library versions in the browser console
jQuery.fn.jquery       // jQuery version
_.VERSION               // Lodash version
angular.version.full   // AngularJS version
Vue.version             // Vue.js version
React.version           // React version (if exposed)
Bootstrap.VERSION       // Bootstrap version

For bundled libraries where global variables are not exposed, inspect the source maps or the minified bundle for version strings. Search the bundle for patterns like @version or v4.17.20.

Step 3: Audit Your Build Pipeline

If you manage the source code, audit at the dependency level rather than the runtime level. Run these commands in your project directory:

# npm projects
npm audit

# yarn projects
yarn audit

# Check for outdated packages
npm outdated

The npm audit command checks every direct and transitive dependency against the npm advisory database and reports severity levels. Fix issues with npm audit fix or manually update specific packages.

Step 4: WordPress-Specific Considerations

WordPress sites face a unique challenge: you do not control the JavaScript that plugins bundle. A single plugin might include an ancient copy of jQuery UI, Moment.js, or a vulnerable charting library.

Strategies for WordPress sites:

• Run the JavaScript Vulnerability Scanner against your production site – this catches every library regardless of source
• Check if plugins are loading their own jQuery instead of WordPress's bundled version, which WordPress keeps reasonably current
• Dequeue unnecessary scripts in functions.php using wp_dequeue_script()
• Consider using a Content-Security-Policy header to restrict which scripts can execute – see our security headers guide

For the broader picture of WordPress security, including server-side hardening, see our WordPress Security Hardening Checklist. And if you are evaluating whether to use a security plugin versus manual hardening for these issues, read our comparison of plugins versus manual approaches.

Step 5: Remediation Strategies

Once you have identified vulnerable libraries, choose the appropriate fix:

1. Update the library: the simplest fix. Check the library's changelog to ensure the update does not include breaking changes.
2. Replace the library: for end-of-life libraries like AngularJS 1.x or Moment.js, migration to a supported alternative is the only long-term solution. Moment.js can be replaced with date-fns or the native Intl.DateTimeFormat API.
3. Mitigate with CSP: if you cannot update immediately, a strict Content-Security-Policy header can prevent exploitation of XSS vulnerabilities by blocking inline script execution. Test your current headers with our Secure Headers Test.
4. Remove the library entirely: if the library is not essential, remove it. Fewer dependencies means fewer vulnerabilities.

Establishing Ongoing Monitoring

JavaScript libraries receive new CVEs constantly. Set up ongoing monitoring:

• Run the JavaScript Vulnerability Scanner monthly against production
• Add npm audit to your CI/CD pipeline so builds fail on high-severity vulnerabilities
• Subscribe to security advisories for your critical dependencies
• Review and prune unused dependencies quarterly

Also check your cross-domain policies to ensure third-party scripts from CDNs cannot exfiltrate data through permissive Flash or Silverlight policies that may still be present on your server.