A Go CLI and library that classifies 172 WAF products from wafw00f's fingerprint corpus via live HTTP probing or offline saved responses, built for authorized reconnaissance and pipeline-scale testing.
| Tool | Lu1sDV/wafmeow — Go CLI and library for WAF detection from live HTTP and offline captures |
| Category | Web application firewall fingerprinting / reconnaissance |
| Primary Use | Detecting which WAF protects a target during authorized assessments, using --fast, --deep, --baseline or --evidence modes |
| Safe Use | Only against systems you own or are explicitly authorized to test; the README itself warns that active modes send probes, making it suited to scoped engagements, labs and internal pipeline hygiene |
| Telemetry Note | Active modes (--fast, --deep) send deliberately anomalous probe requests that WAF and edge logs will record; --baseline and offline --evidence analysis generate no new traffic |
wafmeow is a Go-based answer to one of the oldest small annoyances in web reconnaissance: identifying which web application firewall sits in front of a target, quickly and in a form that composes with modern tooling. The project is explicitly positioned as a wafw00f alternative, and its most important design decision is that it does not try to reinvent the fingerprint corpus. Instead, it ports the signatures maintained by wafw00f — 172 product identities at the time of the README — into a compiled Go binary, with upstream credit and licence notices preserved in LICENSE.md. The author is refreshingly candid that catalogue size does not prove equivalent detection on every target, since probe behavior and evidence semantics differ from the Python original.
The pitch rests on three pillars: speed, pipeline integration and offline reanalysis. Because it ships as a static Go binary, there is no Python, pip or virtualenv to manage, which matters a lot when you want WAF detection inside a container or CI stage. The optional browser capture feature is the one exception, requiring Chromium, though the README stresses it is not an OS-enforced sandbox. Building from source requires Go 1.26 or newer, and the typical workflow is go build -o wafmeow ./cmd/wafmeow, with prebuilt binaries, a Go module path (github.com/Lu1sDV/wafmeow/v3) and a Homebrew tap (brew install Lu1sDV/tap/wafmeow) documented in the release guide.
Collection is organized around four mutually exclusive live/offline modes. --fast performs a quick active scan combining normal, no-user-agent and combined probes; --deep is the default when no mode is given and sends eight selected request types for broader coverage; --baseline issues a single normal request with no active probes, catching fingerprints already present in ordinary responses; and --evidence FILE classifies previously saved responses without generating any new traffic. Targets arrive via --target (repeatable), --target-file PATH for a file of URLs, or --target-file - for stdin, which is what makes the tool compose naturally with subfinder and ProjectDiscovery's httpx in shell pipelines.
The httpx integration deserves particular attention because it exists in two distinct forms. You can pipe live httpx output straight into wafmeow --target-file - --fast to send fresh probe requests, or you can import an existing httpx JSON export with --evidence - --evidence-format httpx and classify it entirely offline. The importer targets httpx v1.12.0 and is honest about its epistemic limits: exported bodies lack completeness proof, so content-based matching stays unknown while status, header and cookie evidence can still match. That kind of documented uncertainty — what a result does and does not prove — runs through the whole project and is rare in this tool category.
Output handling is clearly built by someone who has operated real pipelines. --jsonl streams results on stdout so they can feed jq, notification tools or a database, while human diagnostics go to stderr, keeping the two channels clean. --output / -O writes an atomic report in .json, .jsonl, .csv or .txt depending on the extension. The --strict flag is the operationally interesting one: it exits with status 2 after publishing incomplete, failed or diagnosed results — not merely because a WAF matched — turning evidence quality into something a CI gate can consume. Configuration, input and output failures exit 1, and cancellation exits 130, giving shell wrappers a well-defined contract.
The benchmark section is unusually rigorous for a GitHub README. It compares wafmeow against wafw00f 2.4.2 across 600 live HTTP/HTTPS targets (500 non-CDN plus 100 known-CDN hosts sampled from the Tranco top 10,000), three runs per configuration, on a Hetzner Helsinki VPS with 4 vCPUs and 7.6 GiB of RAM, completed 31 October 2026. At 100 workers/processes, wafmeow --fast finished in 9.0 seconds versus 1m 52s for wafw00f — a 12.45× speedup — while --deep came in at 21.9s, a 5.12× gain. Named-WAF match counts landed in overlapping ranges (155–158 across tools), and the author explicitly disclaims these counts as an accuracy comparison, since named and generic signals overlap.
Equally notable is the reproducible offline comparison harness: workers replay saved responses with network access isolated by bubblewrap, recording source and binary hashes, compiler and Python package versions, CPU details and a verified result manifest. The shipped synthetic conformance fixture covers only 29 of the 172 products, which the README presents as fixture-conformance checking rather than a coverage claim. This separation between end-to-end CLI timing and isolated saved-response classification is the kind of methodological care that suggests the benchmarks are meant to be scrutinized, not marketed.
The evidence semantics are spelled out in a caveats section that every user should internalize. A fingerprint match is evidence, not proof of WAF enforcement; no match is not proof of absence; and an incomplete result is not a negative. Redirect and connection budgets let operators bound acquisition and apply explicit scope rules across redirects, which is both a performance and a scope-safety feature — important because both --deep and --fast send active probes and should only be run against systems you own or are authorized to test. The README's own example pipelines encode this discipline, gating on ${AUTHORIZED_DOMAIN:?set an authorized domain} so the pipeline fails loudly rather than scanning whatever string happens to be in scope of a variable.
From a defensive perspective, the tool is equally useful run from the inside. Blue teams can use --baseline or offline --evidence analysis to inventory which edge protections are actually observable in their own response traffic, and the strict exit codes make it feasible to continuously verify WAF presence in internal CI. Because reports contain results rather than replayable response captures, they are relatively safe to pass downstream, a nuance the operations guide (docs/operations.md) elaborates under safe report consumption. The optional Chromium capture produces screenshots and sanitized exports, again with the caveat that it is not a network sandbox.
The documentation tree is deep for a young project: usage, migration from wafw00f with flag mappings, browser capture, operations, releases, a Go library API with a v3 module contract, architecture decision records, benchmarks, a security policy with private vulnerability reporting, and a launch checklist. The library angle means the same evidence classifier can be embedded directly into custom Go tooling rather than shelling out, with result JSON pinned to schema 1 and module/report versions treated as separate contracts. One caution flag: the repo metadata reports the license as NOASSERTION even though the README badge says MIT, and the README itself warns that the v1.0.0 downloads predate security hardening in the current source tree — so prefer recent validated releases or build from main. With 67 stars and an active CI workflow, wafmeow is a credible, well-engineered modernization of a recon staple for authorized operators.
Lu1sDV/wafmeow.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.