cdncheck: identifying CDN and WAF infrastructure before scanning

cdncheck · MIT

cdncheck tells you whether an IP belongs to a CDN, a WAF or a cloud provider. That sounds minor. It is the difference between scanning your client’s infrastructure and scanning Cloudflare’s.

Install

go install -v github.com/projectdiscovery/cdncheck/cmd/cdncheck@latest

Core commands

# classify a list of IPs
cdncheck -i ips.txt

# only what is behind a CDN
cdncheck -i ips.txt -resp -mcdn

# exclude CDN ranges before an active scan
cdncheck -i ips.txt -exclude > direct-ips.txt

# JSON
cdncheck -i ips.txt -json -o cdn.jsonl

Output

{"input":"104.16.0.1","cdn":true,"cdn_name":"cloudflare","waf":false,"cloud":false}

Where it sits in Tandera

cdncheck runs in the discovery phase of three flows, including recon_cloud_enum. It sits deliberately early — before any active scanning is scheduled — because its output changes what the later phases are allowed to touch.

An IP classified as CDN-owned is not the client’s asset. Tandera uses that classification when applying a flow’s risk ceiling, so that recon_web_full’s active scanning does not point nmap or masscan at a shared provider range.

Using it in a pentest

This is a legal control, not an optimisation. Port-scanning a Cloudflare or AWS range is scanning a third party who did not authorise you. Run cdncheck before any active phase and exclude what it flags.

A CDN in front means your findings may not be the origin’s. Headers, TLS configuration and error pages you observe may belong to the edge. Note it in the report rather than attributing edge behaviour to the client’s server.

A WAF classification changes your methodology, and the client should know. If testing happened through a WAF, say so — otherwise the report implies a level of coverage the engagement did not have.