ToolkitReconnaissance

Practical documentation · Authorized use only

WhatWeb

WhatWeb fingerprints web technologies from observable responses. Use it to build or validate an authorized application inventory, then confirm significant technology claims with deployment owners because fingerprints can be stale or ambiguous.

WebFingerprintingScannerRuby

Start safely and get useful results

Best for

  • • Technology inventory
  • • Exposure triage

Not for

  • • Vulnerability confirmation by fingerprint alone
  • • Unapproved Internet profiling

Before you run anything

  • • Document the authorized target, time window, success criteria, data-handling rules, and a named stop contact before you begin.
  • • Confirm the installed version with the tool’s version or help command, then compare its documented behavior with the linked upstream project before relying on any option.

Practical workflows

Beginner

Fingerprint a local application

Scenario: Confirm whether a local test service exposes expected headers and frameworks.

whatweb http://localhost:8080

Collect baseline fingerprints from the local application endpoint.

Expected use: Expect candidate technologies, versions when disclosed, and headers; treat every result as a hypothesis.

Intermediate

Produce a reviewable report

Scenario: Compare approved staging endpoints after a release.

whatweb --log-json=whatweb.json https://staging.example.invalid

Save structured output so claims can be reviewed and correlated with the target list.

Expected use: Use JSON as evidence of observed response features, not as a vulnerability report.

Interpret results like an analyst

  • • A version string may be hidden, proxied, or misleading; do not infer patch status from a banner alone.
  • • Combine fingerprints with owner-confirmed SBOM or deployment evidence before opening remediation work.

Common mistakes and operating tips

Avoid

  • • Treating passive fingerprints as confirmed component versions.
  • • Sending aggressive plugins to a shared production endpoint without an approved test plan.

Operational discipline

  • • Treat command output as evidence, not a conclusion: retain the command, version, scope, timestamp, and a redacted result in the engagement record.
  • • Start with the smallest safe scope, validate expected behavior in a lab or pilot, then expand only when the authorization and monitoring plan support it.

Verify against the current upstream

Tool behavior and release syntax can change. Treat this guide as practical operating context, then verify version-specific details against the upstream project before an assessment.

Open authoritative upstream documentation