Edgewatch identifies whether an internet-facing service is CDN-fronted and/or WAF-protected as part of every scan. By default we use safe, passive techniques (DNS, IP ranges/ASN, HTTP headers, and TLS hints). We do not run heavy exploit attempts against Cloudflare or other CDN/WAF edges because it is technically noisy, usually ineffective, and risks collateral impact to third parties.
Customers on the Professional plan can optionally enable WAF detection & bypass checks to evaluate WAF configurations in a controlled, rate-limited manner.
What “CDN-fronted” and “WAF-protected” mean
- CDN-fronted: Content is delivered through a Content Delivery Network acting as a reverse proxy (e.g., Cloudflare, CloudFront, Fastly, Azure Front Door, Akamai, Edgio).
- WAF-protected: A Web Application Firewall sits in front of the origin, filtering and inspecting requests (e.g., Cloudflare WAF, Imperva, F5, ModSecurity-based).
A target can be both CDN-fronted and WAF-protected (common with integrated CDN+WAF providers).
How Edgewatch detects CDN/WAF
We combine multiple low-risk signals and return a confidence score plus evidence:
- DNS & CNAME patterns – e.g., *.cloudfront.net, *.azurefd.net, etc.
- IP range / ASN matching – first-party CIDR lists and ASN hints for major providers.
- HTTP response headers – provider-specific markers (e.g., cache IDs, proxy Via, known Server values).
- TLS certificate/SAN hints – occasional edge-certificate indicators.
Why Edgewatch avoids exploit attempts against CDN/WAF edges
- Technically noisy & easily detected
CDN/WAF platforms are purpose-built to spot probing and rate-limit or tarpitting scanners. Aggressive payload spraying generates large, obvious signal with little diagnostic value. - Low signal for the origin
Attacking the edge rarely reaches the origin application; results reflect the provider’s shared mitigation, not your app’s true risk posture. - Risk of collateral impact
CDN IPs and PoPs are multi-tenant. Excessive testing can affect unrelated domains behind the same edge, trigger broad rate-limits, or violate provider AUPs/ToS. - Compliance & reputational considerations
“Loud” exploit attempts from public clouds or data-centers can be interpreted as abuse, complicating incident response and legal/compliance posture.
Optional WAF detection & bypass checks
For customers who need to assess WAF coverage and rule efficacy, Edgewatch offers an opt-in module with strict guardrails. This module targets configuration validation, not exploitation. It is designed to avoid denial-of-service conditions and adheres to provider AUPs and your internal testing policies.
What’s included
- WAF fingerprinting (low-impact): identify likely vendor/engine and key behaviors.
- Lightweight evasion checks (configurable): safe variants of header/method/encoding handling to reveal misconfigurations (e.g., inconsistent normalization).
- Controlled execution: rate-limited, concurrency-capped, geo-scoped, and respect for target scopes you define.
- Evidence & guidance: clear pass/fail indicators, sample requests (redacted), and remediation tips.
Enabling the module
- Plan: Professional or higher.
- Scope: define permitted domains/paths and maintenance windows.
- Settings: enable WAF Detection & Bypass Checks in your scan profile (Dashboard → Scanning Profiles).
- API: set waf_tests: “passive” | “light” in the scan request body.
- Audit: review results in the Findings panel with evidence and replayable (sanitized) samples.
Best practices when your service is CDN-fronted
- Origin hardening still matters, assume bypass paths exist (direct IP, mis-scoped DNS, alternate hostnames).
- Restrict origin access, allow-list CDN egress ranges or use private connectivity (e.g., “origin pull” over private links).
- Explicit WAF policies: enable/ tune managed rules, add app-specific virtual patching, and monitor false positives.
- Ensure edge logs are ingested into your SIEM; correlate with origin logs for full coverage.
- Rerun Edgewatch passive checks and, if needed, Professional WAF tests after rule or architecture changes.