A website dossier in one page
Web-Check gathers the questions people normally answer with a dozen separate sites. Give it a domain and it can show resolved addresses, DNS records, certificate chains, cookies, response headers, robots rules, redirects, open ports, traceroute results, DNSSEC, mail security, trackers, associated hosts, technology fingerprints, performance, server location, and more. Results appear as dashboard cards with plain explanations of why each signal matters.
That breadth is ideal for orientation. A new site owner can notice a missing security header, expiring certificate, exposed service, weak mail policy, unexpected redirect, or third-party tracker without learning each command first. An analyst can collect leads before moving to authoritative DNS tools, certificate logs, network scanners, or application testing. The interface makes infrastructure visible without pretending that every reader is a security specialist.
The limits deserve equal weight. Some findings come from public databases or third-party APIs and can be old, incomplete, rate-limited, or associated with a shared IP rather than the exact application. An open port does not prove a vulnerability. A missing header does not describe all compensating controls. Technology fingerprints can be wrong. Web-Check is an inventory and teaching surface, not an audit attestation.
Basic self-hosting is pleasantly simple
The fastest path is docker run -p 3000:3000 lissy93/web-check. Images are published on Docker Hub and GitHub Container Registry, and the README also offers one-click Netlify, Vercel, and Render deployments. Source installation requires Node.js 22.12 or later, Yarn, and Git. Chromium, traceroute, and DNS packages enable particular checks; jobs that lack required packages are skipped.
No API keys are required for the basic product. Optional keys can enrich PageSpeed, Shodan, WHOIS, SecurityTrails, Cloudmersive, Tranco, URLScan, BuiltWith, and torrent-related results. That modularity is sensible, but each provider introduces separate quotas, retention rules, availability, and possible charges. Several REACT_APP_ values are client-side and therefore visible in browser traffic, a risk the README explicitly notes. Scope those credentials narrowly.
Operators can enable API rate limiting, restrict CORS origins, shorten timeouts, disable expensive checks, allow only selected checks, list blocked hosts, and turn off the GUI. These controls are useful for cost containment. They do not by themselves make the application safe for anonymous internet access.
The scanner currently needs protection from its users
Open pull request 315 documents a server-side request forgery path in the shared middleware. A caller supplies the url query parameter, and the middleware passes its normalized value to handlers that can use HTTP fetches, headless Chromium, raw networking, and DNS. The current checked-in middleware does not centrally reject loopback, link-local, private, reserved, or cloud metadata targets.
That means an unauthenticated user of a reachable instance may be able to make the server probe addresses that are visible from the server but not from the public internet. In a cloud network, this can include metadata endpoints. In an office or home network, it can include internal services. DNS rebinding and redirects also need consideration, because validating only the initial hostname is insufficient if the resolved address or destination changes.
There are multiple open fixes. Pull request 288 proposes strict URL parsing, HTTP and HTTPS-only protocols, credential rejection, and private or reserved address checks. Pull request 315 centralizes a similar guard across all 35 handlers and proposes an explicit private-target override. Pull request 274 is another SSRF fix. Their existence shows contributors understand the issue, but an open patch is not protection in the version users run.
The README's API_BLOCKED_HOSTS setting is useful for known exclusions, yet a blacklist cannot enumerate every local IPv4 and IPv6 range, alternate notation, DNS answer, redirect, and metadata address safely. Until a central, tested guard lands, bind Web-Check to localhost or a trusted private network and enforce egress policy outside the application. Do not add powerful cloud credentials to the same runtime.
Release 2.2.0 improved accuracy
Version 2.2.0 was published July 28, 2026. It added an advisory panel, subdomain lookup, configurable disabled checks, improved WAF detection, and a vulnerability panel. Several changes corrected how results are presented: OCSP stapling became informational rather than pass or fail, IPv6 records stopped being visually truncated, and other UI accuracy work landed. That focus matters for a dashboard whose main job is interpretation.
The vulnerability panel still needs careful language. It can show CVEs associated through Shodan, but association is not proof that an application is exploitable. An open follow-up enriches CVEs with CISA's known-exploited catalog, EPSS probabilities, exposed-service context, and patch priority. Those additions would make the panel more actionable, but they remain proposed work rather than shipped behavior.
Issue 301 also shows how error presentation can fail users: a DNS-server job allegedly reported an unclear ENODATA message after an extremely long displayed duration, without explaining the attempted query. A tool that aggregates dozens of network jobs needs explicit states for unavailable, skipped, timed out, and genuinely failed checks.
Project health is good, with one urgent caveat
The last push was August 11, 2026, two weeks after the latest release. There were 31 open issues and pull requests, including recent work on breach history, CVE context, and SSRF defenses. With 34,480 stars, several new contributors in the last release, published containers, hosted demos, and a Codeberg mirror, Web-Check has strong reach and visible maintenance.
Documentation is extensive and unusually educational. Its feature list admits it needs updating, and the giant single README is harder to navigate than dedicated operator and API guides would be. A proposed security policy also remained open, so private reporting instructions should be confirmed before sending a vulnerability.
Web-Check earns a recommendation for private, authorized reconnaissance. It is fast to try, easy to read, permissively licensed, and broad enough to expose worthwhile questions. Its public deployment story must wait for the SSRF boundary to be fixed, released, and tested. Keep it local, treat every result as a lead, and use specialist tools for decisions that carry security or compliance consequences.