CDN fingerprinting

Identifies the CDN/reverse proxy in front of a resource and flags evidence of multi-tier caching (an edge layer plus a shield/regional layer).

How it works

1. Reuses the live cache state check’s already-captured response (no extra request) to check Server/Via header matches from the CDN registry.
2. Resolves the resource’s CNAME chain and matches it against the registry’s known apex domains when the header match alone isn’t conclusive.
3. Flags multi-tier caching when a CDN’s registered “multi-tier” headers are present (e.g. Fastly’s X-Served-By/X-Cache-Hits, Varnish’s X-Varnish).

Supported CDNs / servers

CDN / server	Server/Via fingerprint	CNAME apex
Cloudflare	cloudflare	cloudflare.net
Fastly	fastly (Server), varnish (Via)	fastly.net, fastlylb.net
Akamai	akamaighost	akamaiedge.net, akamaitechnologies.com, akamai.net
Amazon CloudFront	cloudfront (Via)	cloudfront.net
Varnish	varnish (Via)	—
Vercel	vercel	vercel-dns.com, vercel.app
Netlify	netlify	netlify.app, netlifyglobalcdn.com
Pantheon	pantheon	pantheonsite.io
Google Cloud CDN	google frontend (Server), google (Via)	—
Azure Front Door	—	azurefd.net, azureedge.net
Nginx (proxy_cache)	nginx	—
KeyCDN	keycdn-engine	kxcdn.com
Bunny CDN	bunnycdn	b-cdn.net

The full signature table, including each entry’s cache-status header, lives in cache/cdn/registry.go.

A Server/Via/CNAME that doesn’t match any of the above isn’t a dead end: the live cache state check still falls back to generic header conventions and a timing/Age heuristic (see that page for the fallback chain) — this check just reports no CDN name in that case.

Missing your CDN or server? Open an issue with the Server/Via/cache-status headers and CNAME chain it emits. Adding an entry to the registry is a data change, not a code change, so most requests are a small PR.

Beyond fingerprinting: static extensions, cache-key notes, and quirks

Each Signature in the registry also carries three fields the fingerprinting check itself doesn’t consume, but that other checks and human reviewers do:

• StaticExtensions — file extensions that CDN’s default configuration treats as cacheable at the edge regardless of the origin’s Cache-Control (e.g. .css, .js, .jpg). The cache-deception check merges every registry entry’s list (cdn.AllStaticExtensions) into its path-confusion probe suffixes, so a newly documented default extension is automatically probed.
• PathNormalization — whether that CDN normalizes the request path (dot-segments, encoded separators) before or after applying its cache rules, per Doyhenard’s “Gotta cache ‘em all”: CloudFront and Azure Front Door before; Cloudflare, Google Cloud CDN, and Fastly after. The delimiter & normalization mapper measures the real order live and uses this only as a cross-check.
• KeyNormalization — a free-text note on how/when that CDN normalizes cache-key inputs (query-string ordering/stripping, delimiter handling, case folding) relative to Vary/Cache-Control evaluation. This is documentation for interpreting an unexpected HIT/MISS, not something Detect matches against.
• Quirks — known, disclosed CDN-specific caching behaviors or CVEs relevant to cache-poisoning/deception risk, each with an ID, Description, and Reference URL.

Separate from these static, per-signature fields, the cdn package also exposes a runtime quirk store, cdn.DiscoveredQuirks — a concurrency-safe map of target origin to the delimiter (origin-only and cache-only) and path-normalization behavior — including the measured cache-side normalization order — the delimiter & normalization mapper discovers at scan time. It accumulates across every resource probed under an origin so a later resource (or an embedding tool) can reuse a result instead of re-probing.

Known disclosed issues referenced in the registry

Quirk	Affected	Reference
CPDoS (2019) — cache-poisoned denial of service via an attacker-provoked origin error (oversized header, meta-character, or overridden method) getting cached	Cloudflare, Fastly, Akamai, Amazon CloudFront, Varnish	cpdos-2019 quirk on each entry
Cloudflare’s short default TTL for select error status codes (e.g. 404/410) with no origin Cache-Control	Cloudflare	cf-error-status-default-ttl quirk
Pingora request-smuggling/cache-poisoning CVEs (CVE-2026-2833, CVE-2026-2835, CVE-2026-2836) in standalone Pingora deployments — Cloudflare’s own CDN wasn’t affected since Pingora isn’t used as its ingress proxy	Self-hosted Pingora-based proxies (not the Cloudflare CDN entry)	Cloudflare’s advisory blog post

What’s not implemented (yet)

IP range (ASN/CIDR) matching is deliberately not implemented — it needs a maintained, licensable ASN/CIDR dataset. The result field it would populate (IPRangeLookupAvailable) is defined so a real backend can be dropped in later without reshaping this check.

Findings

Finding	Severity	Meaning
Multi-tier caching detected	info	Evidence of more than one cache tier (edge + shield/regional)