wafw00f: identifying WAFs before and during testing

wafw00f · BSD-3-Clause

wafw00f sends a series of probes to a web application and matches the responses against fingerprints for around 150 web application firewalls. It tells you whether a WAF is in front of the target and, usually, which one.

Install

pipx install wafw00f
# or
pip install wafw00f

Core commands

# single target
wafw00f https://example.com

# a list
wafw00f -i hosts.txt

# every match, not just the first
wafw00f -a https://example.com

# JSON output
wafw00f -i hosts.txt -o waf.json -f json

# list the fingerprints it knows
wafw00f -l

Output

[{"url":"https://example.com","detected":true,"firewall":"Cloudflare","manufacturer":"Cloudflare Inc."}]

Where it sits in Tandera

wafw00f runs in the analyze phase of recon_web_lite and recon_web_full. Its result is context for everything else: a WAF sitting in front of the application changes how the active-scan results should be read.

It complements cdncheck, which answers the same question from the network side. cdncheck classifies the IP; wafw00f classifies the behaviour. They disagree often enough to be worth running both.

Using it in a pentest

A WAF changes what your report can claim. If nuclei found nothing, that may mean the application is sound or it may mean the WAF blocked the probes. Those are different conclusions and the client deserves the honest one. State in the methodology that testing was performed through a WAF, and which.

Ask about allow-listing before you start. Many engagements are supposed to test the application, not the WAF. If that is the intent, the client needs to allow-list your source addresses — and that request has to happen before the testing window, not during it.

“No WAF detected” is weak evidence. Fingerprints go stale and some products are deliberately quiet. Absence of detection is not evidence of absence; do not write it as such.