PAGES
← all tools
◆ SAST / SCA / Code Security

is-website-vulnerable

v1.14.0 open-source

is-website-vulnerable finds publicly known security vulnerabilities in a website's frontend JavaScript libraries via CLI, Docker, or GitHub Action.

source ↗ rss ↗ What is a cyber toolchain?

Summary

is-website-vulnerable is an open-source command-line tool that scans a website's frontend JavaScript libraries for publicly known security vulnerabilities, and it is free to use. You run it as a one-off scan via npx against a target URL, or through Docker, with JSON output available for feeding results into other tooling; exit codes distinguish clean scans from errors and from detected vulnerabilities, which suits wiring it into a build pipeline. It is aimed at application developers and appsec teams who want a quick check of third-party JS exposure without setting up a full dependency-scanning stack. Its vulnerability data comes from Snyk, whose logo appears in the README as a supporter of the project. Development has been steady since a 2019 first commit, with 26 contributors and a release cut just two weeks ago.

is-website-vulnerable finds publicly known security vulnerabilities in a website's frontend JavaScript libraries via CLI, Docker, or GitHub Action.

How is-website-vulnerable helps

Which frontend JavaScript libraries on this site have publicly known vulnerabilities?

crawls the target URL, identifies the JS libraries it loads, and checks them against Snyk's vulnerability data, listing any matches by exit code and log detail

Is a given site safe to ship or deploy right now?

returns a distinct exit code when vulnerabilities are found versus when the scan errors out, so a pipeline can fail the build automatically on real findings

How do I get vulnerability findings into another tool or dashboard?

can emit results as JSON instead of console text, so the output can be parsed or forwarded rather than read by hand

Which of our sites are quietly carrying known-vulnerable frontend code without running a full dependency-scanning setup?

runs as a one-off check against just a URL, with no project source or dependency manifest required, so it can be pointed at any live site to get a same-day answer

Should this fail our continuous integration run?

the exit code distinguishes clean scans, tool errors, and detected vulnerabilities, so wiring the check into a pipeline needs no extra parsing of output text

all 3 features, with the evidence for each →

Languages

Not documented

Features

3 capabilities

Built from is-website-vulnerable's releases, docs, README and our own runs. “Seen” marks the month we first spotted a release the vendor didn't date. Group names and tags are our labels.

Compare with peers →

What is-website-vulnerable offers you

  • JSON data export2
  • CI/CD pipeline integration1
  • Command-line interface1
  • Scripting language support1
All capabilities 3 capabilities
JavaScript vulnerability scanning shipped suggested Scans websites for vulnerabilities within their JavaScript code and dependencies. 6 releases · 5 other sources · first seen Oct 2019

Suggested capability: Static application security testing. This is our guess, not confirmed.

Also counts toward: JSON data export, Scripting language support

release

  • Adds cookie flag to enable scanning of websites that require authentication via cookies or tokens v1.13.0 · Jan 2020 · source · release history
  • --json output now includes a libs field containing the list of libraries and their versions used by the tool v1.8.0 · Oct 2019 · source · release history
  • Adds --js-lib flag to output detected JS library info v1.6.0 · Oct 2019 · source · release history
  • Adds the --debug flag to enable debugging output v1.1.0 · Oct 2019 · source · release history
  • Supports running lighthouse audits on Node.js versions less than 10 v1.2.0 · Oct 2019 · source · release history
  • scan subcommand scans a website for JavaScript vulnerabilities v1.0.0 · Oct 2019 · source · release history

example

  • Scan a website that requires login by passing session cookies. is-website-vulnerable https://example.com --cookie 'session=abc123' v1.13.0 · Jan 2020 · source
  • Inspect the specific JavaScript libraries a target website is using. is-website-vulnerable --js-lib https://example.com v1.6.0 · Oct 2019 · source
  • Run a vulnerability scan against a target website. is-website-vulnerable scan https://example.com v1.0.0 · Oct 2019 · source
  • Scan site via Docker with JSON output docker run --rm lirantal/is-website-vulnerable:latest https://www.google.com --json
  • Scan a website for JS vulnerabilities npx is-website-vulnerable https://example.com [--json] [--js-lib] [--mobile|--desktop] [--chromePath] [--cookie] [--token]
Frontend vulnerability scanning shipped suggested Identifies publicly known security vulnerabilities in a website's frontend JavaScript libraries. 3 releases · 5 other sources · first seen Oct 2019

Suggested capability: Vulnerability database matching. This is our guess, not confirmed.

Also counts toward: Command-line interface, JSON data export

release

  • Adds --progress CLI flag to enable a progress loader during scans v1.5.0 · Oct 2019 · source · release history
  • Adds --json CLI flag to print results as JSON instead of default text format v1.4.0 · Oct 2019 · source · release history
  • cli now automatically converts a bare host argument (e.g., example.com) into a valid URL (http://example.com) before scanning v1.3.0 · Oct 2019 · source · release history

docs

  • Finds publicly known security vulnerabilities in a website's frontend JavaScript libraries.

example

  • Inspect which scanner engines are active in your report for compliance or debugging. is-website-vulnerable https://example.com --json | jq '.libs' v1.8.0 · Oct 2019 · source
  • Monitor scan progress on the terminal for long-running website checks is-website-vulnerable <url> --progress v1.5.0 · Oct 2019 · source
  • Scan a site without manually typing the protocol prefix. is-website-vulnerable example.com v1.3.0 · Oct 2019 · source
  • Inspect verbose logs while scanning a site for vulnerabilities. is-website-vulnerable --debug https://example.com v1.1.0 · Oct 2019 · source
CI/CD integration via GitHub Actions shipped suggested Allows running the cyber tooling as a native GitHub Action within workflows. 1 release · first seen Feb 2020

Suggested capability: Web vulnerability scanning. This is our guess, not confirmed.

Also counts toward: CI/CD pipeline integration

release

  • Adds support to run is-website-vulnerable as a GitHub Action v1.14.0 · Feb 2020 · source · release history

Lines in monospace are the tool's own words: help text parsed from its source, or an endpoint from its API document. Under release, a line is our summary of a dated release. Under docs, it is quoted from the tool's own documentation or website. Each links back to the source it came from.

Score card

  1. Shipping velocity releases a month, last 12 months
  2. Documentation quality release-notes rubric, 0–100
  3. Breaking-change discipline how rarely a release breaks users, and notice given
  4. Maintenance risk quiet time against its own cadence, maintainers
  5. Innovation & surface new capabilities, API and MCP surface
  6. Community health
  7. Contributor trend distinct committers, this year against last
  8. Maintainer concentration bus factor now against a year ago
  9. Issue backlog trend issues closed per issue opened, 12 months
  10. Responsiveness median time to a maintainer’s first reply

Nine scores for is-website-vulnerable, each built from the releases, notes and API history this site tracks — and, on Researcher and Business, where it stands among every measured tool in its category and how that has moved.

Score cards are part of every paid plan.

See plans →

Each score is 0–100 on a published rubric, derived from data this site already shows. A dimension we cannot measure says so — it is never scored 0 and never enters a rank.

How this is scored
  • Shipping velocity — releases a month over the last 12 months, on a log scale where 16 a month scores 100. Needs 3 releases in the window.
  • Documentation quality — the release-notes rubric published on the analytics page, unchanged.
  • Breaking-change discipline — the share of releases carrying a breaking change (none scores 100, half or more scores 0). Only projects that label breaking changes are measured: a clean record cannot be told from an unlabelled one.
  • Maintenance risk — quiet time measured against the tool's own release cadence (quiet longer than 90 days and three typical gaps scores 0), plus the number of active maintainers and whether contributors are growing, where known. Higher is lower risk.
  • Innovation & surface — new capabilities in the feature ledger this year, API and MCP operations added, and the share of commits that are features: the mean of whichever we hold.
  • Community health (open-source tools only) — each is a direction, not a size: contributors this year against last, the bus factor now against a year ago, and issues closed per issue opened, where steady scores 50, doubled 100 and halved 0; plus the median time to a maintainer's first reply (an hour scores about 100, a month or more 0). A commercial card has no repository and carries none of the four.
  • Documented delivery (commercial tools) — when a vendor's documented new capabilities have slowed against its own baseline, that counts against the overall standing as heavily as two low dimensions. Steady delivery, or too little history to judge, leaves the standing alone; it is never a sixth score.
  • Open-source tools are scored on repository signals; commercial tools on their published changelog. Ranks compare tools within one category and one profile and need at least five measured peers; the overall standing needs three ranked dimensions. Best-in-breed or consolidator is a shape, not a quality, and is never scored.

Release-note detail over time

See how much detail is-website-vulnerable puts in its release notes, quarter by quarter, and compare it with tracked tools in the same category. This history uses up to ten retained, reviewed notes per tool; sparse or blank older quarters may reflect that limit.

Checking release-note history…

Explore the full chart →

Releases

11 entries

  1. February 20201
  3. January 20201
  5. October 20199

    11 entries

    1. v1.14.0 Feb 3, 2020 · release notes

      Adds GitHub Action support for is-website-vulnerable

      └──▷ GET THIS VERSION 
      $ git clone --branch v1.14.0 https://github.com/lirantal/is-website-vulnerable.git
# already have the repo? check out this version:
$ git checkout v1.14.0
    2. v1.13.0 Jan 31, 2020 · release notes

      Adds cookie and token support for scanning authenticated websites

      └──▷ GET THIS VERSION 
      $ git clone --branch v1.13.0 https://github.com/lirantal/is-website-vulnerable.git
# already have the repo? check out this version:
$ git checkout v1.13.0
      └──▷ USE IT
      Scan a website that requires login by passing session cookies.
      shell 
      is-website-vulnerable https://example.com --cookie 'session=abc123'
      • Adds cookie flag to enable scanning of websites that require authentication via cookies or tokens

      1 detail in Everything

    3. v1.9.0 Oct 28, 2019 · release notes

      Adds --device flag to run audits on emulated mobile devices via Lighthouse

      └──▷ GET THIS VERSION 
      $ git clone --branch v1.9.0 https://github.com/lirantal/is-website-vulnerable.git
# already have the repo? check out this version:
$ git checkout v1.9.0
      • Adds support for device emulation during website vulnerability audits using Google Lighthouse.

      1 detail in Everything

    4. v1.8.0 Oct 28, 2019 · release notes

      is-website-vulnerable v1.8.0 adds library metadata to JSON output

      └──▷ GET THIS VERSION 
      $ git clone --branch v1.8.0 https://github.com/lirantal/is-website-vulnerable.git
# already have the repo? check out this version:
$ git checkout v1.8.0
      └──▷ USE IT
      Inspect which scanner engines are active in your report for compliance or debugging.
      shell 
      is-website-vulnerable https://example.com --json | jq '.libs'
      • --json output now includes a libs field containing the list of libraries and their versions used by the tool

      1 detail in Everything

    5. v1.6.0 Oct 19, 2019 · release notes

      Adds --js-lib flag to print detected JavaScript library information.

      └──▷ GET THIS VERSION 
      $ git clone --branch v1.6.0 https://github.com/lirantal/is-website-vulnerable.git
# already have the repo? check out this version:
$ git checkout v1.6.0
      └──▷ USE IT
      Inspect the specific JavaScript libraries a target website is using.
      shell 
      is-website-vulnerable --js-lib https://example.com
    6. v1.5.0 Oct 9, 2019 · release notes

      is-website-vulnerable v1.5.0 adds a progress loader for long scans

      └──▷ GET THIS VERSION 
      $ git clone --branch v1.5.0 https://github.com/lirantal/is-website-vulnerable.git
# already have the repo? check out this version:
$ git checkout v1.5.0
      └──▷ TRY IT
      Monitor scan progress on the terminal for long-running website checks
      $ is-website-vulnerable <url> --progress
    7. v1.4.0 Oct 9, 2019 · release notes

      is-website-vulnerable v1.4.0 adds --json flag for machine-readable output

      └──▷ GET THIS VERSION 
      $ git clone --branch v1.4.0 https://github.com/lirantal/is-website-vulnerable.git
# already have the repo? check out this version:
$ git checkout v1.4.0
      └──▷ TRY IT
      Capture vulnerability scan results in a structured format for downstream processing or logging.
      $ is-website-vulnerable https://example.com --json
      • Adds --json CLI flag to print results as JSON instead of default text format

      1 detail in Everything

    8. v1.3.0 Oct 8, 2019 · release notes

      v1.3.0 adds automatic host-to-URL conversion for the input argument

      └──▷ GET THIS VERSION 
      $ git clone --branch v1.3.0 https://github.com/lirantal/is-website-vulnerable.git
# already have the repo? check out this version:
$ git checkout v1.3.0
      └──▷ TRY IT
      Scan a site without manually typing the protocol prefix.
      $ is-website-vulnerable example.com
      • cli now automatically converts a bare host argument (e.g., example.com) into a valid URL (http://example.com) before scanning

      1 detail in Everything

    9. v1.2.0 Oct 7, 2019 · release notes

      is-website-vulnerable v1.2.0 adds support for running Lighthouse on Node versions below 10.

      └──▷ GET THIS VERSION 
      $ git clone --branch v1.2.0 https://github.com/lirantal/is-website-vulnerable.git
# already have the repo? check out this version:
$ git checkout v1.2.0
      • Supports running lighthouse audits on Node.js versions less than 10

      1 detail in Everything

    10. v1.1.0 Oct 7, 2019 · release notes

      Adds CLI --debug flag for verbose output during website vulnerability scanning

      └──▷ GET THIS VERSION 
      $ git clone --branch v1.1.0 https://github.com/lirantal/is-website-vulnerable.git
# already have the repo? check out this version:
$ git checkout v1.1.0
      └──▷ USE IT
      Inspect verbose logs while scanning a site for vulnerabilities.
      shell 
      is-website-vulnerable --debug https://example.com
    11. v1.0.0 Oct 6, 2019 · release notes

      is-website-vulnerable v1.0.0 introduces the initial scan command for detecting JavaScript vulnerabilities in websites.

      └──▷ GET THIS VERSION 
      $ git clone --branch v1.0.0 https://github.com/lirantal/is-website-vulnerable.git
# already have the repo? check out this version:
$ git checkout v1.0.0
      └──▷ USE IT
      Run a vulnerability scan against a target website.
      shell 
      is-website-vulnerable scan https://example.com
      • scan subcommand scans a website for JavaScript vulnerabilities

      1 detail in Everything

    Project health

    Issue, contributor and maintainer activity in lirantal/is-website-vulnerable, 2023-12 – 2026-11, as of 2026-11-03. Twelve-month figures first; the trend lines run the whole window.

    1. Contributors 2 ±0 vs prior 12 months
    2. Maintainers 1 +0 joined · −0 left, last 12 months
    3. Bus factor 1 committers behind half the commits
    4. Community-filed 100% of issues opened, last 12 months
    5. Median time to close < 1 day first maintainer reply 1.1 hours
    6. Open backlog 0 of 45 issues ever filed
    1. Issues opened / month 0 · 0 communitymaintainers
    2. Open backlog 0
    3. Contributors / month 0
    4. Commits / month 0
    5. Stars 2,044
    Issue themes, last 12 months
    • other 100%

    Counts from the project's public repository and git history; no individuals are identified. Maintainers are the committers covering 80% of the last year's commits. how we measure this

    Libraries its release ships

    What its latest release locks, checked against known advisories.

    None of its release's images build from a lockfile we can read.

    Add the badge to your README

    Maintain this project? The badge links readers straight to this page, so they can follow every release here.

    Tracked by Cyber Toolchain Choose a badge style and copy the code →
    compare.md

      Free the public facts, no sign-in Any paid plan all other sections Researcher & Business pricing history and category rank

      my-toolchain — 0 tools

        Betas, release candidates and previews. Turn it off to see final releases only. It also applies to changes you ask for over MCP when you're signed in.
        browse all tools → score card for your toolchain →
        cyber-toolchain / feedback

        Send us feedback