CDN Security Scoring: TLS, Security Headers, and Vendor Claims

A security score must start with its boundaries

Latency fits naturally into milliseconds. Security includes protocol configuration, certificates, response headers, access controls, mitigation capacity, operations, and application code. Compressing all of that into an unexplained number creates false certainty.

CdnChart separates CDN security information into two classes: measurable controls that can be observed repeatedly through public edge behavior, and vendor-declared capabilities that cannot be independently verified through safe probing. The first class can contribute to a reviewable score. The second must remain separate and carry its source and verification status.

Measured controls and what they tell us

The platform performs non-invasive checks against edge endpoints, including:

• support for TLS 1.3;
• presence of weak cipher suites;
• certificate-chain validity;
• default HSTS;
• CSP;
• X-Content-Type-Options;
• HTTP/3 support;
• OCSP Stapling.

These checks answer what the public endpoint showed during the observation. They do not prove that every product, plan, region, or customer configuration of a provider has the same behavior. Results must therefore be tied to a target endpoint, observation time, and response facts.

TLS and certificate chains

TLS 1.3 support can reduce handshake round trips and enable modern cipher negotiation, but it is not a complete security verdict. A robust check also looks for weak suites, expired certificates, incomplete chains, missing intermediates, and inconsistent behavior across protocol entry points.

Certificate inspection must distinguish an explicit validation failure from an observation that did not collect enough information. The former is a measured failure; the latter is unknown. Treating unknown as pass or fail turns a data-quality gap into a security claim.

Security response headers

HSTS tells browsers to prefer HTTPS. CSP restricts script, resource, and connection sources. X-Content-Type-Options reduces MIME sniffing risk. Their presence is useful, but actual protection also depends on values, path coverage, and application cooperation.

CdnChart records whether the header exists and what value was observed before applying an explainable rule. An HSTS header on one homepage response is not evidence that every path and subdomain has been hardened.

HTTP/3 and OCSP Stapling

HTTP/3 support indicates that the endpoint can use QUIC-based transport. It may affect connection establishment and weak-network behavior, but it is not the sole determinant of security. OCSP Stapling concerns how certificate-revocation status is delivered and should be read with the handshake and certificate-chain result.

These fields work well as measurable controls, not as proxies for a provider’s entire security capability. The security card keeps pass, fail, and unknown states visible.

Why WAF and DDoS are not actively attacked or scored

Validating WAF rules, DDoS mitigation capacity, or bot-management behavior would require attack traffic, threshold triggering, or customer-specific controls. That is not appropriate for a public benchmark and can violate safety and compliance boundaries.

CdnChart documents WAF, DDoS, anti-bot, and related capabilities from public vendor material and labels them “vendor-declared, not independently verified.” The claims are useful product context, but they must not be mixed with measured TLS or header results in an unexplained total.

Keeping the score reviewable

Security scoring uses versioned checks and weights. Each result retains the target, HTTP status, scan time, observed facts, success state, and error message. Aggregation records which controls contributed and which were excluded because they were unknown or below the data-quality threshold.

An explanation should include:

• scan time and target scope;
• the measured controls and their states;
• the difference between pass, fail, and unknown;
• the scoring-rule version and freshness;
• the source and verification label for vendor claims.

When a provider has not reached the quality gate for a meaningful score, the page should show data collection rather than compare an immature result with a fully observed provider.

Using the score for provider selection

Open a provider page and inspect its security scorecard to see measured and declared items separately. Use the CDN comparison to view security alongside latency, availability, and throughput. Then return to the methodology to verify scan boundaries and freshness.

Security scoring is useful for initial screening, provider reviews, and regression checks after configuration changes. It does not replace penetration testing, code review, WAF policy review, DDoS planning, or contractual SLA analysis.

Responsible measurement

The platform performs low-risk configuration checks against public endpoints. It does not send attack payloads, stress mitigation capacity, bypass access controls, or turn a benchmark into an intrusion against customer traffic. Every conclusion should point back to a handshake fact, response fact, or named public source.

Summary

A credible CDN security score does not add vendor marketing claims into one number. It separates what was measured from what a provider says it can do. CdnChart provides reviewable checks for TLS, certificate chains, headers, HTTP/3, and OCSP, while preserving the verification boundary around WAF and DDoS claims. A professional score is accountable to its evidence first.