WAF / CDN Detector Guide
Use this guide to interpret edge fingerprints and understand which provider sits in front of your origin.
Overview
Many sites are protected by CDNs or WAFs that add distinctive response headers such as cf-ray, x-amz-cf-id, or x-sucuri-id. Identifying them helps during incident response and hardening reviews.
Why fingerprinting matters
- Scope scans correctly: Some findings apply to the edge, not the origin application.
- Tune protection: Knowing the provider helps you locate the right rule set or dashboard.
- Reduce disclosure: Server banners and edge headers can reveal more infrastructure detail than necessary.
Common fingerprints
| Provider | Typical signals | Category |
|---|---|---|
| Cloudflare | cf-ray, server: cloudflare | CDN / WAF |
| Amazon CloudFront | x-amz-cf-id, via: cloudfront | CDN |
| Fastly | x-served-by, x-cache | CDN |
| Sucuri | x-sucuri-id | WAF |
Review workflow
Confirm edge ownership
Run the detector against the public site URL, note the provider match, then verify the account and rule set in that provider dashboard.Recommended Remediation Flow
- Confirm provider ownership Make sure the detected CDN or WAF is managed by your team.
- Review rule coverage Check WAF managed rules, bot protection, and caching settings.
- Reduce banner disclosure Remove unnecessary Server header detail where the provider allows it.
Troubleshooting Common Issues
No provider detected
The site may be self-hosted or use a less common edge.
- Check DNS CNAME targets manually.
- Review reverse proxy configuration.
- Repeat the test from multiple regions if needed.
Validation Checklist
Post-fix validation
- Edge provider matches expected infrastructure.
- WAF or CDN rules are actively managed.
- Unnecessary server disclosure is minimized.
FAQ
Is a CDN the same as a WAF?
Not always.
- CDNs primarily cache and accelerate content.
- WAFs inspect and block malicious requests.
- Many providers combine both capabilities.