How Do We Score CDN Security? Measured Checks and Vendor Claims Must Stay Separate

Why Security Is Harder to Quantify

Latency gives you a concrete millisecond value, but "security" is a combined capability. If you force everything into one vague score, you risk misleading the user. Our approach is to split security into separate classes and present them independently.

Measured Checks (Automated Scanning)

These items can be gathered objectively through automated inspection of edge behavior:

• TLS configuration: whether TLS 1.3 is supported, whether weak cipher suites exist, and whether the certificate chain is complete
• Security headers: whether HSTS, CSP and X-Content-Type-Options are served by default
• Protocol support: HTTP/3 and OCSP Stapling

These checks make up the trusted and reproducible part of the security score.

Declared Capabilities (Documented, Not Scored)

Capabilities such as WAF or DDoS protection tiers cannot be actively validated through probing. Trying to "test" them directly turns into attack traffic, which is neither compliant nor ethical. So we document vendor claims from public material and label them clearly as vendor-declared, not independently verified.

Honesty Is the Foundation of Credibility

Separating "what we measured" from "what the vendor claims" tells the user how strong the evidence is behind each conclusion. That is much more valuable than showing a neat-looking total score that hides uncertainty.