waf-detector is a Rust CLI that fingerprints WAFs and CDNs across twelve providers and grades enforcement posture for engineers validating defenses on systems they own or are authorized to test.

Most WAF fingerprinters stop at naming the vendor. ammarion/waf-detector, a Rust CLI sitting at 117 stars under an Apache-2.0/MIT dual license, goes considerably further: it identifies the protection layer, then interrogates it with structured probe suites to answer the question that actually matters in an authorized assessment — is the firewall enforcing anything, or is it sitting in monitor-only mode? The README frames this as a full lifecycle: detect, smoke test, enforce, behave, grade, and report, all from one binary built with cargo build --release.

Detection itself is passive-first. waf-detect scan identifies the fronting layer via headers, response body fingerprints, DNS, TLS characteristics, and timing — a sensible multi-signal approach, since any single channel is trivially spoofed by an origin pretending to be a CDN. Twelve providers are supported: CloudFlare, AWS, Akamai, Fastly, Vercel, Azure, F5, Imperva, ModSecurity, Sucuri, Radware, and FortiWeb. That list covers essentially everything you will encounter on public-facing infrastructure in an engagement, and waf-detect providers enumerates it for scripting. Batch mode via waf-detect scan @urls.txt --ndjson makes it practical for inventory-wide sweeps during scoping.

The interesting architecture decision is the tool's own authorization boundary. Active testing modes — --smoke-test, va, --va2, and --effectiveness — refuse to run against targets that have not been registered through waf-detect --scope init example.com. Scope entries can be added, removed, and cleared with --scope add-target, --scope remove-target, and --scope clear. This is more than a disclaimer; it is a client-side guardrail baked into the workflow, which is a pattern more offensive tooling should adopt. It also signals the intended audience: blue-team engineers and pentesters who want an audit trail of what was in scope, not opportunistic scanners.

The smoke test sends categorized attack payloads and classifies each response into four buckets: BLOCKED (typically a 403), CHALLENGE (a JS challenge or CAPTCHA from bot protection), ALLOWED (the probe reached origin), and ERROR (non-blocking failures like 404, 500, or timeout). The category coverage is broad — SQL injection in basic and advanced forms, XSS, command injection, path traversal, SSTI, SSRF, Log4Shell, file upload, scanner detection, GraphQL injection, HTTP request smuggling, prototype pollution, WebSocket injection, and enumeration. An --aggressive flag expands the payload set, and -o results.json exports findings. The value here is diagnostic: a low block rate tells the WAF owner their ruleset is permissive, not that someone should exploit it.

The enforcement test (waf-detect va ) layers confidence scoring on top of the block/challenge/allow measurements, and its tuning knobs read like they were written by someone who has had a probe run melt a fragile origin. --va-tier 1|2|3 selects a safety tier, --va-budget N caps total requests at a default of 120, --va-timeout defaults to 15 seconds per request, --va-delay MS paces requests 750ms apart, and --va-variants N controls mutation count per payload template. The --va-replay and --va-replay-csv options export the exact request plan, which is exactly what you want attached to a report so a third party can verify findings independently.

Behavioral analysis under --va2 is the most conceptually interesting mode. Instead of counting blocks, it sends paired probes — one benign, one malicious — across five HTTP channels: path, query, header, body, and method, then measures whether the WAF distinguishes them. The five signals it evaluates are encoding defense (does the WAF normalize encoded paths before matching?), session tracking (does it escalate on repeat abuse?), bot challenge behavior, rate limiting, and attack recognition. Channels showing 0% attack detection get flagged as unprotected, which is a genuinely actionable finding — a WAF that inspects only query strings leaves the request body as a wide-open channel. A dry run without --va2-run shows the plan without executing, --va2-phases selects among baseline, protocol-variance, state-escalation, behavioral-pressure, and challenge-interaction phases, and --va2-seed (default 1337) makes runs reproducible.

The posture report ties everything into a letter grade from A to F plus a risk score from 0 to 100, combining detection confidence, enforcement results, and behavioral analysis. The grade semantics are worth reading closely: --posture-va1 distinguishes "WAF present but not enforcing" — a log-only deployment — from "no WAF at all", which is a distinction passive fingerprinting can never make and one that routinely surprises organizations convinced their CloudFlare subscription means protection. Interpretation guidance is included: block rates above 90% suggest a well-configured WAF, below 50% suggests detection-only mode, and common findings like identical responses across all probes may simply indicate static content.

Reporting closes the loop. waf-detect hardening --output file.json runs a full scan, and waf-detect report file.json --output file.html renders the JSON artifact into a static, self-contained HTML page — no web server, no reruns — suitable for attaching to tickets or dropping into chat. The tool also emits --json, --ndjson, --compact, and --yaml for pipeline integration, plus --benchmark corpus.json for evaluating the detector itself against a known corpus and waf-detect doctor for environment diagnostics.

A few operational notes for anyone deploying this in a lab or engagement. The default budgets — 120 requests for va, 60 for va2 — are conservative enough to avoid most rate-limit bans, but budget math matters on fragile targets, and the --va-delay pacing should be raised rather than lowered when testing production systems you own. The origin-probe subcommand with --json hints at origin-discovery capability behind the CDN, which in authorized contexts is useful for validating that origin IPs are not directly reachable, bypassing the WAF entirely. That is arguably the most common real-world WAF failure mode, and having it in the same tool as the efficacy tests is coherent design.

There is also an unusual nod to automation: an AGENTS.md file and agent-skills/waf-assess/WORKFLOW.md plus agent-skills/validate-build/WORKFLOW.md provide skill mapping for AI coding agents running full assessments and pre-merge build validation. Whether you consider that gimmicky or forward-looking, it reflects a project designed to be composable inside CI and automated pipelines rather than only driven by hand — consistent with the cargo test --lib, cargo clippy -- -D warnings, cargo fmt development hygiene documented in DEVELOPMENT.md.

From a defensive standpoint, this tool is most valuable run against your own stack before someone else's scanner finds the gaps. An unprotected channel finding from va2, a detection-only WAF surfaced by --posture-va1, or a missing rate-limiting signal gives you a concrete, prioritized remediation list. And because every probe the tool fires is deliberately noisy and categorized, your SIEM and WAF analytics will show the activity clearly — which is exactly how it should be when the tester and the defender are, in a well-run program, the same team.

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.