A homepage loading successfully proves only that one route through your website works. DNS records, mail authentication, certificates, response headers, archived pages, and reachable services can tell a different story. A site owner preparing for a release can use the open-source Web-Check project to collect these dispersed signals in one place, then ask the people responsible for each service to verify and fix them. This guide provides a repeatable workflow for domains you own or have explicit permission to assess. It also shows how to record uncertainty instead of turning every colored indicator into a vulnerability report.
The project’s GitHub repository showed about 35.3K stars on October 30, 2026. Star counts change, and the earlier “34.8K” headline is already dated. A “30-second complete exposure map” is not a reliable promise either. Checks depend on the target, network conditions, external data providers, browser rendering, and timeouts. No single OSINT dashboard can prove that every asset has been found or that a configuration warning is exploitable.
Define the boundary before opening a scanner
Web-Check’s README describes on-demand intelligence for a website: it assembles technology, architecture, security configuration, and possible attack paths. That makes it useful for the question, “What can an outsider observe about this named site?” It is insufficient for “Is our inventory complete?” or “Has a breach happened?” Those questions need internal records and other evidence.
Write down the exact asset first. If the target is your example.com, determine whether www.example.com, admin.example.com, and its mail domain have the same owner and scope. DNS answers are snapshots. A CDN, reverse proxy, multiple regions, and split routing can change the result seen from another location. An IP address in a panel is not automatically the origin server. Record the hostname, environment, time, network vantage point, and tool version for each run.
Authorization matters because the project does more than read a web page. Its security documentation says the server performs DNS lookups, TLS handshakes, HTTP requests, common-port checks, traceroute, and some headless-browser checks. Certain results are enriched by third-party services. Port probing and route tracing are active operations. Do not batch-scan third-party sites, partner assets, or the public demo without permission. The steps below concern only systems you own or are expressly authorized to test.
Figure 1. A scope map from domain to DNS, certificates, mail, and web responses. This is an explanatory diagram, not a live scan.
Choose the run mode that matches the job
Figure 2. A crop of the project repository’s interface screenshot shows many checks in one panel. The UI can change; this is not a test of our own site.
For an occasional look at your public domain, the project’s hosted interface is the easiest starting point. Enter a domain you are allowed to assess, wait for the modules, and open the raw values behind any warning. Save the observation time and source before filing a ticket. Hosted throughput, third-party quotas, and maintenance are outside your control; they do not form a guaranteed service level.
For a team that needs repeatable reviews, the official Docker instructions provide a starting point:
docker run --rm -p 127.0.0.1:3000:3000 lissy93/web-check
docker run --rm -p 127.0.0.1:3000:3000 lissy93/web-check
The local address binding here is a defensive adaptation of the README’s simpler -p 3000:3000 example. It keeps this trial instance off a public interface. Open http://localhost:3000 and test only approved targets. A team deployment still needs network boundaries, authentication at a reverse proxy or VPN, resource limits, image maintenance, and an explicit decision about data sent to external services. The project has no built-in accounts; its security policy warns that a publicly reachable instance can be asked to make requests on behalf of anyone who can reach it.
The source-build route currently uses git clone, yarn install, yarn build, and yarn start. Check the repository’s current prerequisite versions when you deploy, rather than copying an old Node version from another article. Some checks need Chromium, traceroute, or other runtime components. If a check is unavailable, report it as “not completed,” not “passed.” Pin a container tag or commit in your team’s review notes so a later scan can be compared under a known rule set.
Read the first pass as an ownership map
Start with the named domain and inspect A/AAAA, CNAME, MX, NS, TXT, and certificate subject alternative names. A CDN can make edge addresses, vendor names, and several certificates appear in one result. Translate each finding into a small ownership record: domain, observed value, environment, responsible team, and next verification. Do not jump from “unknown subdomain” to “compromise.”
| Observed clue | Verify with | Evidence for closure |
|---|---|---|
| Unfamiliar subdomain | DNS owner and product team | Inventory entry, DNS history, current service owner |
| MX points to an old provider | Mail administrator | Current receipt path and change record |
| Certificate contains an old name | Certificate owner | Issuance inventory and current service status |
| Response reveals a service label | Gateway or app owner | Live header and precise version exposure |
A forgotten test subdomain may still route to a third-party platform; it may also be a legitimate marketing integration. The domain name alone does not decide. Check the DNS console, CDN route, cloud resource tags, and tickets. What matters is producing an inventory with a named owner and a decision to retain, change, or remove the entry. A count of “findings” without ownership is a poor outcome metric.
Figure 3. External values become actionable only after comparison with the internal asset inventory.
Separate mail, TLS, and web-header work
Mail authentication is often collapsed into one red icon. MX describes inbound delivery. SPF, DKIM, and DMARC address sender identity and recipient policy. Cloudflare’s security-record documentation explains the roles: SPF lists authorized senders, DKIM signs mail to verify domain and content, and DMARC directs receivers when authentication fails while providing reports. If a tool reports missing DMARC, inventory every legitimate sender and inspect alignment before moving to a restrictive policy. A rushed change can block ordinary transactional mail.
Certificates and TLS have a different owner and validation path. Compare the observed certificate with the one in your CDN, gateway, or certificate manager. Record expiry, chain, affected hostnames, renewal automation, and who can roll back the change. If TLS terminates at a CDN, document both client-to-edge and edge-to-origin boundaries. A failed handshake from one scanning location may be caused by network routing, rate limits, or anti-bot controls. Confirm with an independent route before declaring a production incident.
Security headers require application context. The OWASP Secure Headers Project explains the purpose and configuration of response headers, including HSTS and CSP. Check redirect paths, subdomain HTTPS coverage, third-party scripts, and legacy clients before changing policy. In particular, do not enable an HSTS option that covers all subdomains when some subdomains do not support HTTPS. A visible Server or X-Powered-By header can leak implementation details, but by itself it is not proof of an exploitable flaw. Confirm whether a precise version is exposed, then ask the service owner to assess patch level and information minimization.
Figure 4. Mail authentication, TLS, and HTTP headers have different owners and acceptance criteria.
Treat archives and ports as leads, not incidents
Historic snapshots, robots.txt, sitemap.xml, public repository references, and technology fingerprints can reveal forgotten paths. They do not prove that an archived page is still live or that its old content is currently accessible. Record the archive date, test the present path within your permitted scope, and ask the owner. If sensitive data is actually exposed, use your normal access-control, cache-removal, and incident-response procedures. An old screenshot alone is insufficient.
An open port is also a vantage-point observation. It does not establish that a service is reachable from every network, lacks authentication, or runs a particular database version. Check the load balancer, firewall, cloud security group, and service listener. Then decide whether to restrict source addresses, stop listening, or keep the service for a documented business purpose. An unexpected administrative port reachable from the public internet deserves quicker review than a cosmetic header omission, but severity still depends on data sensitivity, access control, and reproducibility.
Web-Check’s security policy gives two additional boundaries. Scanned domain names or IPs may be sent to external enrichment services. Request URLs may also appear in proxy or platform logs. For a prelaunch domain or confidential project, decide whether that transfer is acceptable before scanning. A private instance does not automatically mean private data flow. Configuration such as API_ENABLED_CHECKS and API_DISABLED_CHECKS can narrow checks, and API_BLOCKED_HOSTS can reject entered targets. The maintainers warn that host blocking alone does not fully account for DNS changes and redirects; use network firewall controls when a hard boundary is needed.
Figure 5. Reachability, sensitivity, and evidence quality inform review order; the colors do not certify a vulnerability.
A 45-minute review a team can repeat
Set up a small record before starting: target, environment, asset owner, authorized scope, runtime location, tool version, and start time. Do not budget just “30 seconds.” Most review time is spent understanding and validating the observations, not waiting for the page.
Minutes 0–10: define scope. Select one production web domain and its sending domain. Identify who owns DNS, certificates, the gateway, and application code. Decide whether port and traceroute checks are permitted. If they are not, disable them on your controlled instance. Use the hosted interface only for approved, non-sensitive public targets.
Minutes 10–20: capture a baseline. Save the panel results, time, and failed checks. If the product does not provide persistence that meets your audit needs, record the required fields in your ticket system. The project says scan results are not stored by its own service; seeing a result once in a browser is not evidence retention. Mark an unavailable check “not completed.”
Minutes 20–35: verify three high-value classes. Review unknown public-facing assets and ports; certificates and mail identity; then headers and historic pages. Every finding needs an independent check, such as the DNS console or dig, the certificate manager, the mail admin panel, curl -I, or gateway logs. Compare the external value with the internal configuration.
Minutes 35–45: assign action. Move a finding into a remediation queue only when it has an owner, a reproducible observation, and a plausible effect. Give each ticket an action, rollback condition, and retest method. Put weak evidence into “needs verification,” and third-party failures into “check failed.” Neither counts as closed. Re-run from the same vantage point and with the same rules after a release.
Copyable ticket template:
Target / environment:
Authorization and disabled checks:
Tool version / location / time:
Observed item and raw value:
Internal-system verification:
Impact and confidence:
Owner / change / rollback:
Retest date and result:
Target / environment:
Authorization and disabled checks:
Tool version / location / time:
Observed item and raw value:
Internal-system verification:
Impact and confidence:
Owner / change / rollback:
Retest date and result:
Figure 6. Scope, baseline, independent verification, and ownership. Actual duration varies with site complexity.
Do not create a new exposure with the scanner
A team may install a scanner on a server with access to internal networks and then expose port 3000 to everyone. That creates a new access path. The maintainer security policy notes the absence of built-in accounts and the ability to make requests and active probes. Put a shared instance behind authenticated access, restrict its network reach, and decide which checks to run. Never load-test the project’s public instance.
Before deploying, answer four questions: who can reach this instance, which networks can it reach, which checks must run, and whose external API quota will be consumed? Current options include API_ENABLE_RATE_LIMIT, API_ENABLED_CHECKS, API_DISABLED_CHECKS, and API_BLOCKED_HOSTS, but an application-layer blocklist cannot replace a firewall. The security policy also notes that screenshot-related checks may launch Chromium without a sandbox; keep images current and treat the scanned page as untrusted content. The project only supports the latest release for security fixes.
For an operating cadence, consider a weekly baseline and event-driven checks after DNS, certificate, mail-provider, or CDN changes. A high-frequency full scan can add load, trigger anti-abuse systems, and exhaust external API quotas. Inventory, vulnerability scanning, configuration auditing, and human penetration testing each have a separate job. Web-Check is most valuable before those steps, when it collects candidate clues in one view.
For Apito teams: include your API entry points in the asset boundary
With an API access layer such as Apito, separate your own public domain, the provider’s official domain, upstream model-service domains, and private callback URLs. Web-Check examines the named target; it cannot audit the entire request path. A shared service IP or a certificate name does not automatically become an asset you own.
Place your public API domain, callback domain, status page, and mail-notification domain on separate lines in your release inventory. Check DNS, certificate expiry, and a named owner for each. Never put an API key into the scan target, a URL query string, a screenshot, or a ticket attachment. The scan tells you what to verify next; key permissions, request logs, and billing need review in their respective management consoles.
A release-ready acceptance list
- The domain is owned or explicitly authorized, and active probes are within scope.
- Each run records time, version, network vantage point, and failed modules.
- Unknown domains, IPs, and ports have named owners; colored icons are not the final diagnosis.
- SPF, DKIM, and DMARC changes account for legitimate senders.
- TLS and security headers were retested on the actual delivery path, with a rollback plan.
- Archived content and current exposure remain separate records.
- A self-hosted Web-Check instance has access controls, network limits, update plans, and API-quota ownership.
- Remediation is followed by an equivalent retest and a named reviewer.
Sources and verification boundary
This guide uses the Web-Check repository, its security policy, the OWASP Secure Headers Project, and Cloudflare’s mail-security documentation. Stars, dependencies, available checks, and third-party integrations change. Before executing the process, check the current repository revision and your own environment. The diagrams here are explanations, not measurements of a real site.
FAQ
Does a domain scan find every vulnerability?
No. Web-Check assembles public signals and some active results. It can miss assets, and a configuration state alone does not prove exploitation. Verify findings with the owner, then use suitable configuration audits, vulnerability tests, or manual review.
Why does a module spin or return nothing?
The target’s controls, your network position, an external API quota, a missing runtime dependency, or a timeout may be responsible. Record the check as failed, inspect logs and prerequisites, and verify another way. Empty is not safe.
Should we use the hosted demo or Docker?
The hosted interface suits an occasional approved public-domain review. Repeated team reviews or sensitive targets favor a controlled deployment, provided you also manage authentication, network reach, third-party transfers, patching, and resource limits. Self-hosting is not automatically safer.
Is missing DMARC or HSTS always a serious vulnerability?
No. It is a configuration state requiring context. Inventory legitimate mail senders before tightening DMARC, and understand HTTPS coverage before expanding HSTS to subdomains. Actual impact depends on your delivery path and business use.
May we scan someone else’s company site?
Only with the asset owner’s permission and a clear scope for active checks. Public reachability is not consent for port probing, bulk requests, or load testing. Do not use the public demo to investigate unauthorized targets.
