WAF/CDN Detection

WAF/CDN Detection looks at the HTTP response headers from each of your web hosts and checks for signatures from known WAF/CDN providers. A WAF (web application firewall) sits in front of your origin servers, filtering attack traffic, rate-limiting abusive clients, and absorbing volumetric DDoS. A CDN (content delivery network) caches your content closer to users for performance and almost always brings WAF features along with it. RedScore treats either as a protection layer for scoring purposes.

How the check works

The check reads the same web probe artifact used by other Web and Infrastructure checks. For each successful probe, it scans response headers (Server, Via, Set-Cookie, plus provider-specific headers like CF-Ray and X-Amz-Cf-Id) for signatures matching:

• Cloudflare (CF-Ray header, or "cloudflare" in any header)
• AWS CloudFront (X-Amz-Cf-Id header, or "cloudfront" anywhere)
• Akamai ("akamai" in any header)
• Fastly ("fastly" in any header)
• Sucuri ("sucuri" in any header)
• Imperva / Incapsula ("imperva", or incap_ses / visid_incap cookies)
• Varnish ("varnish" in any header). Note: Varnish alone is a cache, not a WAF.

Coverage = (hosts with detected provider) / (total reachable hosts). The verdict is based on coverage.

How the verdict maps to evidence

• Pass (15/15): coverage at or near 100%. Every reachable host returned headers identifying a known provider.
• Warn (~10/15): partial coverage. Some hosts are behind WAF/CDN, others are not. The host_detection_rows array shows which hosts are bare.
• Fail (0/15): no host returned a recognized WAF/CDN signature.

Detection limitations to know about: the check only recognizes the providers in the list above. If you use Netlify, Vercel, Azure Front Door, Google Frontend, StackPath, Edgio, or a self-hosted WAF (ModSecurity, BunkerWeb, NAXSI), the check returns no detection even though you do have a protection layer. Expanding the detection list is on the roadmap.

Fail: no WAF/CDN detected

Putting your origin behind a WAF/CDN takes one of two paths.

Managed CDN with built-in WAF (recommended for most teams)

Move DNS through a managed provider that does both:

• Cloudflare: change your nameservers to Cloudflare's, then turn on the orange-cloud proxy on each web record. Free tier includes baseline WAF.
• AWS CloudFront + AWS WAF: create a CloudFront distribution in front of your origin (ALB, S3, EC2), CNAME your domain at the *.cloudfront.net hostname, and attach an AWS WAF web ACL.
• Fastly: create a service, point it at your origin, then CNAME your domain at the Fastly hostname. WAF is a separate add-on.
• Akamai, Sucuri, Imperva: enterprise providers with similar setup patterns.
• GCP Cloud Armor + Cloud Load Balancer, or Azure Front Door: cloud-native equivalents tightly integrated with their respective platforms.

Self-managed WAF in front of origin

If you operate your own infrastructure, deploy a WAF directly in front of the origin servers:

• ModSecurity (now Coraza) with the OWASP CRS ruleset, in front of nginx or Apache.
• BunkerWeb (an nginx-based WAF distribution).
• NAXSI for nginx.
• Hardware WAF appliances (F5, Imperva on-prem) for very large deployments.

These configurations may not be detected today since the check looks at HTTP-header signatures rather than actual WAF behavior. The protection is real even if the verdict reads fail.

Warn: partial coverage

Some hosts protected, others bare. Walk the host_detection_rows array; rows where detected is false are unprotected. Common reasons:

• Cloudflare in DNS-only mode (grey cloud) for some records. Toggle the orange cloud on every web-facing record you want protected.
• API or admin subdomains intentionally bypassed because of websocket support, long-poll quirks, or legacy clients. Decide whether the bypass is still needed; modern WAFs handle websockets fine.
• Forgotten subdomain pointing directly at an origin IP. Move it behind the WAF/CDN or remove it.
• Origin reachable on a different hostname (origin-mybucket.s3.amazonaws.com) that resolves but lacks the front-door headers. If the origin hostname is meant to be reachable, put a separate WAF in front of it; if not, restrict origin firewall rules to only accept traffic from your CDN (see Origin IP Exposure).

Verify the fix

• Run curl -sI https://yourdomain | head -20. Look for CF-Ray, X-Amz-Cf-Id, X-Cache, Server: cloudflare, or similar identifying headers.
• Repeat for each web-facing subdomain.
• If you are using a provider not on the detection list (Netlify, Vercel, Azure Front Door, etc.), the check will still report no WAF until the detection list is expanded. Until then, treat the verdict as advisory; the actual protection is in place.
• Re-run the RedScore lookup.

Common pitfalls

• Cloudflare in DNS-only mode counts as no WAF. Cloudflare only protects records that have the orange-cloud proxy enabled. Grey cloud means you are using Cloudflare for DNS only; no WAF, no caching, no DDoS absorption.
• WAF behind a load balancer that strips identifying headers. If your edge LB removes provider headers before the response reaches the public internet, this check has nothing to match. Configure the LB to pass identifying headers through.
• Confusing the bypass-host (origin) with the front-door host. Your CDN-facing CNAME passes; your direct-origin hostname does not. Origin IP Exposure (the next check) covers this; close it off there.
• Adding WAF without tuning. Default WAF rulesets often produce false positives on legitimate traffic (admin UIs, file uploads, API patterns). Plan a tuning window and review WAF logs in the first week.
• Provider on the false-negative list. If your real provider is Netlify, Vercel, Azure Front Door, Google Frontend, StackPath, Edgio, or self-hosted, the check returns no detection. The protection is real even if the score reads fail.
• Varnish without an upstream WAF. Varnish alone is a cache; if it is the only thing the check matches, you may pass with no actual web-application firewall.