Identify the WAF in front of any site

Why does a site need a WAF?

A web application firewall sits between visitors and the origin server, inspecting every HTTP request before it reaches the app — not just the raw traffic a network firewall sees, but the actual URL, headers, and body content. That's what lets it catch things a network-layer firewall never will: SQL injection attempts, cross-site scripting payloads, credential-stuffing bot traffic, and the kind of layer-7 request floods that a plain DDoS filter lets straight through because each individual request looks legitimate on its own.

Beyond blocking attacks outright, a WAF also takes load off the origin — junk requests get filtered at the edge instead of costing the app server compute, database queries, and log noise. For regulated businesses, it's often not optional either: PCI-DSS explicitly requires either a WAF or a formal code-review process for any public-facing web application handling card data.

Knowing which WAF is in front of a site matters beyond curiosity, too — it's the first thing worth checking before a CDN or hosting migration (each vendor's rule sets and false-positive behavior differ), when debugging a legitimate request that's mysteriously getting blocked, or during security due diligence on a vendor or acquisition target. It's also just useful competitive research: seeing what infrastructure choices comparable companies are actually running.

If you're auditing a site's edge setup more broadly, this pairs naturally with the AI Discoverability Checker — one looks at what's blocking traffic, the other at what's actively inviting it in. And if you're curious what can go wrong specifically on Cloudflare's side of that edge layer, the three Cloudflare Workers gotchas post covers a self-fetch bug that hit this exact kind of header-inspection logic.

Frequently asked questions

How does this actually detect the WAF?

One real, ordinary GET request to the URL you enter — the same request any browser would make, no attack payloads. The response's headers, cookies, and server banner are matched against publicly documented vendor signatures (the same kind of header/cookie fingerprints open-source tools like wafw00f use).

Why does confidence matter?

Some signals are vendor-unique (a header like cf-ray only Cloudflare sets) and score high alone. Others are weaker or shared across vendors and only add up in combination. A low score means the evidence is thin, not that the tool is guessing randomly.

Why can't it check tunovix.com itself?

A Cloudflare Worker can't reliably fetch its own public zone, and even if it could, the response wouldn't pass through the same edge layer that adds the WAF headers this tool looks for — so a self-scan would give a misleading answer either way. (tunovix.com does run behind Cloudflare, for the record.)

Is this safe to run against any site?

Yes — it's a single passive GET request, identical in kind to opening the URL in a browser. Nothing intrusive is sent, and nothing about what you check is logged or retained.