Vulnerable JavaScript Library Checker

Identify the front-end libraries and versions a page or manifest uses and match them against published advisories, with the evidence for each identification shown.

Uses an external data source

Your search term is sent to the public authority named on this page so the answer reflects current data.

Data source: OSV.dev advisory database

Page address Reads library versions from the page, then queries the OSV.dev advisory database.

Two steps, and the second one can fail honestly

This tool identifies front-end library versions from the page, then asks OSV.dev whether those exact versions have published advisories.

OSV is used because it is free, needs no API key, and aggregates GitHub Security Advisories together with the npm advisory data. Nothing in this tool is gated behind a paid service or a key you have to configure - the identification half works entirely without it.

If the advisory database cannot be reached, the answer is unknown

This matters more than it sounds. If OSV does not respond, this tool reports unknown and names the versions it could not check. It does not report "no known vulnerabilities".

Treating an unreachable advisory service as a clean bill of health is the single most dangerous thing a tool like this can do, because the failure is invisible and the result looks identical to a genuine pass. The same reasoning applies to a library whose version could not be determined: not checked is not the same as not affected.

What a result does and does not establish

A match means OSV lists that exact version as affected by a published advisory. It does not mean your site is exploitable. Whether a vulnerability is reachable depends on which functions you call and with what input - a prototype-pollution issue in a utility function you never invoke is real in the dependency and irrelevant in your page.

It also rests on the version being right, and the version came from a URL. Confirm the file really is what it claims before you act on a finding, and confirm your page actually uses the affected feature before you treat it as urgent. The tool labels these findings as inferred for that reason.

A clean result is a statement about OSV's records at the moment of the query, not a guarantee. An advisory may exist elsewhere, or not yet be published at all.

Prioritising what it finds

Advisory presence alone is a poor prioritisation signal - most published vulnerabilities are never exploited. Combine it with exploitation data: EPSS Score Lookup gives the probability of exploitation in the wild, CISA KEV Lookup tells you whether it is known to be exploited already, and Vulnerability Prioritization Calculator combines those with exposure and business criticality.

The real fix is a build-time inventory

Checking a page can only see what the page states. It cannot see inside a bundle, and most sites bundle. Generate an SBOM from your build and scan that - it covers the transitive tree, which is where most vulnerable dependencies actually live. This tool is best treated as a check on the CDN-loaded libraries that your build's SBOM will not contain, because they are not installed.

Frequently asked questions

Do I need an API key?

No. OSV.dev is free and requires no key, and the library identification works even without reaching it. There are no paid dependencies anywhere in this tool.

What happens if OSV is down?

You get an "unknown" result naming the versions that could not be checked. The tool will not report a clean result it did not verify.

It found a vulnerable version. Am I exploitable?

Not necessarily. Reachability depends on which parts of the library your code uses and with what input. Treat the finding as a prompt to upgrade and to check whether the affected feature is one you call.

Why did it not find the library I know is on the page?

Because the URL does not state a version - typically a bundled or self-hosted copy. Those are reported as unknown by the dependency inventory rather than silently skipped.

Is this a replacement for dependency scanning in CI?

No. It sees only what a page states. CI scanning against a real lockfile or SBOM covers the transitive tree and should remain your primary control.

References

Related tools

What this tool can and cannot tell you. It reports what the named source held when it was queried. Where that source has no record, the answer is unknown rather than safe - an absent entry is not evidence of absence.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.