Skip to content
Noroxi

JavaScript library vulnerability scannerJavaScript library vulnerability scanner

Reads the scripts your site sends to the browser, identifies libraries such as jQuery, Bootstrap, AngularJS, React, Vue, Lodash and Moment.js with their versions, and matches CVEs from the same advisory data npm audit uses (GitHub Advisory Database / OSV). For every library it tells you the safe version on the same branch, whether a vulnerability is in KEV, whether the branch is end of life, and who loads the copy (WordPress core, a plugin, a theme, a CDN). No code access or ownership needed.

Sample results:

The domain you enter is really scanned: only public information is read (HTTP headers, the page and the scripts it loads, TLS handshake, DNS, certificate logs). The result is saved (the same domain isn’t rescanned within 10 minutes); 3 scans per day without an account, 10 per hour with a free account.

What does this test do?

A JavaScript library vulnerability scanner reads the script files your site sends to the browser, identifies libraries such as jQuery, Bootstrap, AngularJS, React, Vue and Lodash with their versions, and matches CVEs from the GitHub Advisory Database that npm audit uses. For each library it shows the safe version on the same branch, KEV status, end-of-life status and who loads the copy.

Sends one GET request to the home page (at most 3 redirects), then reads the script files the page loads: the site's own files and library CDNs, up to 30 files; chunks imported by module bundles are followed too. Analytics and ad scripts are not downloaded. If a bundle points to a webpack license file, that file is read as well; if the site's own scripts reference a source map, only the first few bytes of the map are read (is it public?). Nothing is stored, no forms are filled in, no pages are crawled. The version is read from inside the file (license banner, version string, file hash) or from its URL; a library whose version can't be read is never counted as "no vulnerabilities".

What it checks and how to fix it

Every item the test looks at, why it matters and what to do if it is missing. The result screen shows the same steps for the gaps on your own site only.

Library with an actively exploited vulnerability

Why it matters: A vulnerability in CISA's KEV list, or one with a ready-made attack tool (Metasploit, Nuclei), is one attackers use today. For example CVE-2020-11023 in jQuery before 3.5.0 was added to KEV on 23 January 2025.

How to fix it: Upgrade the library to the safe version shown in the report. If a WordPress plugin or theme ships the copy, update that component; if it comes from a CDN, change the version in the URL and refresh the integrity value.

Upgrade with npmbash
npm install jquery@3.7.1 --save-exactnpm audit --omit=dev

Critical or high severity vulnerability

Why it matters: Critical and high severity records are mostly code execution in the page through user input (XSS), prototype pollution or template injection; they can be exploited on any page that uses the affected function.

How to fix it: Upgrade to the safe version on the same branch; if the branch has no fix, the report suggests a major upgrade. Read the library's release notes for breaking changes first.

Medium or low severity vulnerability

Why it matters: Medium severity records usually need a specific function to be called with specific input; on their own they are not urgent, but they are a real risk if your pages use that function.

How to fix it: Upgrade to the safe version in your next maintenance window. If the flaw is in one function (for example jQuery's htmlPrefilter), you can confirm in your code that you don't use it.

End-of-life version

Why it matters: A branch whose support has ended (AngularJS, jQuery 1.x/2.x, Bootstrap 3/4, Vue 2) gets no fix for new vulnerabilities. Even with no vulnerability today, tomorrow's will stay open.

How to fix it: Plan a move to a supported branch. For libraries whose whole product has ended, such as AngularJS, the move can be a rewrite; until then restrict script sources with CSP.

Script from a compromised source

Why it matters: The polyfill.io domain changed hands in 2024 and the new owner added code that sent visitors to scam sites; the same operator's bootcdn, bootcss and staticfile domains are on the list too. A script loaded from these addresses runs someone else's code on your site.

How to fix it: Remove the script now. If you need a polyfill, use the Cloudflare or Fastly mirror, or add the polyfill you need to your own bundle.

CDN URL not pinned to a version

Why it matters: A version-less or @latest URL on jsDelivr/unpkg changes content by itself when the package owner publishes a new version. In 2024 the versions published from lottie-player's compromised account reached sites this way.

How to fix it: Write the exact version in the URL and add integrity.

Pinned version + integrityhtml
<!-- Kaçının: https://cdn.jsdelivr.net/npm/paket@latest/dist/paket.min.js --><script src="https://cdn.jsdelivr.net/npm/jquery@3.7.1/dist/jquery.min.js"        integrity="sha384-1H217gwSVyLSIfaLxHbE7dRb3v4mYCKbpQvzx0cegeju1MVsGrX5xXxAvs/HgeFs"        crossorigin="anonymous"></script>

Integrity (SRI) on CDN scripts

Why it matters: Without an integrity attribute, a file changed on the CDN or in transit runs in the browser unchecked. With integrity, the browser refuses a file whose hash doesn't match.

How to fix it: Add integrity and crossorigin="anonymous" to versioned CDN URLs; take the value from the CDN's page or with "openssl dgst -sha384 -binary file.js | openssl base64 -A".

Publicly readable source map

Why it matters: A .map file in production gives the readable source and file paths of your bundled code, which makes it easier for an attacker to study your app's internals, hidden endpoints and forgotten keys.

How to fix it: Don't ship source maps (webpack "devtool: false" or "hidden-source-map", Vite "build.sourcemap: false" or "hidden") and upload them only to your error tracking service.

Scripts read

Why it matters: For information: how many scripts were found, how many were read and how many libraries were identified. Files that were not read (analytics/ads, or above the limit) show up in this count.

How to fix it: For apps whose versions can't be read, match package-lock.json on the SBOM page; dependencies that aren't visible from outside are checked too.

Frequently asked questions

How is this different from npm audit?
npm audit reads package-lock.json, needs the code and also counts dev packages that never reach the site. This scan needs only the domain and sees the copies that actually load in production; two versions of the same library shipped by a theme and a plugin are separate rows. It can't see server-side dependencies; if you have the code, match your package-lock on the SBOM page.
Does it find versions in bundled (webpack, Vite) sites?
Usually: minifiers keep license banners and the library's own version string (React's version field, Bootstrap's VERSION), and the webpack license file and module chunks are read too. If the bundler stripped the version entirely, the result says "not visible", never "no vulnerabilities".
Why did Lighthouse remove its vulnerable libraries audit?
Lighthouse 10 removed it because its Snyk snapshot went stale between releases, versions guessed without package.json were unreliable and low-severity or Node-only findings made it noisy. This scanner matches against advisory data refreshed hourly, labels how each version was read and ranks findings by KEV, weaponization and severity.
Why is the safe version sometimes a new major version?
The safe version is the smallest version, taken from the records' own fix versions, that closes every known vulnerability at once. End-of-life branches such as jQuery 1.x or Bootstrap 3 get no fixes, so the suggestion is the next major version.
Is it free? Do I need an account?
Yes, it is free and needs no account: without one you get 3 scans a day (shared by all free tools and the scorecard). A free account raises this to 10 scans an hour and keeps your results and history.
Is it safe to run on my site?
The light scan only reads public information (DNS, the TLS handshake, the HTTP response, certificate logs); it fills in no forms, guesses no passwords and exploits nothing. Each tool lists exactly what it reads under "Sources and method".

Other tests

More free security tools