Protect every connection.
CDN security combines transport protection, traffic policies, origin controls, and correct handling of private responses. Each addresses a different part of the request path. Start by identifying what needs protection, which service enforces each rule, and how you will verify that legitimate visitors can still complete their tasks.
Check HTTPS on both sides of the edge
When a CDN terminates HTTPS, the browser connects to the edge and the edge makes a separate connection to the origin. Configure encrypted origin delivery and certificate validation where supported. Check certificate trust, expiry, and the expected hostname, then assign responsibility for renewal and for investigating connection failures.
Secure delivery also depends on the page's resources. Review image, script, and stylesheet URLs so an HTTPS page does not depend on insecure requests. Plan transport policy changes across relevant subdomains and application paths. A change should have a verified recovery procedure before it reaches production.
Use traffic policies with application context
A web application firewall inspects requests against configured rules. Rate controls can limit requests that match defined conditions. These features can help reduce unwanted traffic, but their coverage and behavior depend on the product, plan, and policy. Review rule matches and legitimate user journeys before broadening enforcement.
For example, an upload endpoint and a login endpoint have different normal traffic patterns. A useful policy reflects that difference. When a legitimate request is blocked, investigate the matching rule and request context. Prefer a narrowly justified correction over a broad exception that removes protection from unrelated traffic.
Keep the origin and private responses in scope
Determine whether requests can reach the origin directly and bypass intended edge checks. The appropriate access restriction depends on the architecture. Preserve authorized operational access, health checks, and a tested recovery route while applying those restrictions. Continue maintaining application authentication, permissions, dependencies, and backups.
Encryption does not make a response safe for shared caching. Account information, private documents, and session-specific pages need explicit cache policies and verification with separate sessions. Our header reference explains the difference between shared public content and sensitive responses.
Finally, document who owns certificates, firewall rules, hosting, and application incidents. Keep enough logs to trace a request across those boundaries without collecting unnecessary sensitive information. Our HTTPS and WAF guide develops this approach into a practical review of configuration and operational responsibilities.