identYwaf fingerprints web application firewalls from the outside

Identification by response, not by header

identYwaf is an identification tool that recognises the type of web protection in place, that is a WAF, based on blind inference. The mechanism is that a set of predefined offensive but non destructive payloads are sent and the responses they provoke are inspected, and those payloads are used only to trigger the web protection system in the way it would trigger on a real attack.

The word blind is doing specific work in that description. There is no signature to match against in the response headers, no vendor banner to read. Instead, the tool fires a request that contains something like an SQL expression in a parameter, sees whether the protection product intercepts it, and then matches the shape of that interception against known signatures.

The example given in the README is a query string with an AND and a comparison, of the kind that a WAF would flag and block. The point of sending it is not to exploit anything, it is to make the WAF speak so that it can be recognised.

The signature database covers 95 protection products, and the README names a representative sample: aeSecure, Airlock, CleanTalk, CrawlProtect, Imunify360, MalCare, ModSecurity, Palo Alto, SiteGuard, UrlScan, Wallarm, WatchGuard and Wordfence.

The tool is MIT licensed, has no third party dependencies, and is tested with Python 2.7 and Python 3.10 and later.

A single script and a JSON database

The repository is small in a way that is unusual for a security tool. At the root there is identYwaf.py, the data.json signature database, a LICENSE, a README, a screenshots directory and a tests directory, plus a .github directory for the workflow.

The installation is correspondingly simple. You can download the latest zipball from GitHub, or clone the repository, and the README recommends the clone:

git clone --depth 1 https://github.com/stamparm/identYwaf.git

There is no pip install, no requirements file and no virtualenv, because the tool has no third party dependencies at all. That is a meaningful property for a tool you might run from a jump host or a container, since nothing needs to be fetched and nothing can be fetched at run time.

The database and the code are separated cleanly, which means the knowledge is data rather than logic. That separation is also the project's main maintenance burden, because the fingerprints in data.json were collected against a specific set of payloads, and changing one invalidates the rest.

The screenshots directory holds manually gathered images of characteristic responses for different protection systems, collected as a future reference, and the README links to a talk on blind WAF identification given at Sh3llCON 2019 in Santander, Spain.

The command line and its knobs

The tool is run with a host or URL and a set of options, and the usage output is the reference:

Usage: python identYwaf.py [options] <host|url>

Options:
  --version           Show program's version number and exit
  -h, --help          Show this help message and exit
  --delay=DELAY       Delay (sec) between tests (default: 0)
  --timeout=TIMEOUT   Response timeout (sec) (default: 10)
  --proxy=PROXY       HTTP proxy address (e.g. "http://127.0.0.1:8080")
  --proxy-file=PRO..  Load (rotating) HTTP(s) proxy list from a file
  --random-agent      Use random HTTP User-Agent header value
  --code=CODE         Expected HTTP code in rejected responses
  --string=STRING     Expected string in rejected responses
  --post              Use POST body for sending payloads
  --validate          Validate data.json and exit

Several of these options exist for reasons a first time user would not guess. The --code and --string options set the expected HTTP code or expected string in rejected responses, which is how you handle a target whose WAF blocks with a different status code than the database expects.

The --random-agent option varies the User-Agent header, and the --proxy and --proxy-file options exist so that a scan can be spread across a rotating proxy list. Both are the kind of feature that tells you the tool was built for people running assessments that need to look like ordinary traffic.

The --post option switches the payloads from a query string to a request body, since some protection products only inspect one or the other. And --delay sets a pause between tests, which is the throttle you use when you do not want to trip the target's own thresholds.

TLS validation is off, and the tool says why

The assessment behavior section is short and the reasoning is sound. TLS certificate validation is intentionally disabled, because assessment targets commonly use expired, self signed, or otherwise invalid certificates.

That is the right call for the use case. A WAF is frequently deployed in front of an internal or staging environment, and the certificate behind it is frequently not something you would trust anyway. Refusing to talk to the target because of an expired certificate would mean the tool reports nothing for exactly the deployments where a WAF is most interesting.

There is a second behaviour worth knowing. If an HTTPS heuristic response does not change, identYwaf retries that heuristic over HTTP and reports the retry, so you can see that a result came from the plain HTTP path rather than silently attributing it to the HTTPS one.

The README closes the section with a line that should be read twice: use the tool only against targets you are authorized to assess. The payloads are deliberately attack shaped, and sending them at a host you do not own is both a legal problem and a practical one, since a WAF that decides you are an attacker will start blocking you.

The database is a signed format, and editing it has a cost

The database maintenance section explains something that is easy to miss and expensive to learn the hard way.

Payload order and content are part of the blind signature format, so data.json records a schema version, a signature version, and a SHA-256 hash of the complete payload list. It also explicitly records the known signature shared by CDNetworks and Janusec, so that an exact match reports both candidates instead of silently choosing one. That last detail is the difference between a tool that tells you what it knows and one that quietly lies.

The consequence of the ordering constraint is stated plainly. Changing a payload invalidates the fingerprints that were collected with the old payload set. The validator reports the new payload hash, but the affected WAF fingerprints must also be collected again before the change is committed.

So the database is a coupled artefact. A maintainer who edits one payload has to re-fingerprint every product that the old payload set distinguished, and the tool makes that visible through the hash rather than leaving it to be discovered by a user whose results quietly changed.

After every edit the database is validated with:

python identYwaf.py --validate

The test suite simulates a WAF on loopback

The development section describes a dependency free test suite:

python -B -m unittest discover -s tests -p 'test_*.py'

The -B flag keeps Python from writing bytecode files, which keeps the working tree clean, and the discovery pattern is the standard unittest one.

The description of what the tests do is what makes them interesting. They validate the database and exercise complete GET and POST scans against a loopback-only simulated WAF, so the whole path, from firing the payloads through the signature comparison to the report, is tested without touching the network. That is a sensible design for a tool whose unit of value is a table of fingerprints.

GitHub Actions runs them on Python 2.7 and on Python 3.10 through 3.14, which is why the README describes the project as tested with Python 2.7 and Python 3.10 plus. Keeping the Python 2 branch alive is an unusual commitment for a 2019 project and it means the script is written to run unchanged on both major language generations.

The repository has no GitHub releases, and the last push was on 2026-09-10.

Editorial conclusion

identYwaf suits a security engineer who needs to know which WAF sits in front of a target before testing anything else, since the whole signature database is committed to the repository and the tool is a single script with no install step. It is the wrong tool if you need to detect a WAF that does not react to the known payloads, and it is not a vulnerability scanner. Before running it, check that you are authorised to assess the target, run python identYwaf.py --validate to confirm the database is intact, and expect the tool to send a handful of attack shaped requests to the host.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. stamparm/identYwaf on GitHub