Synopsis
This chapter describes how to keep security controls equivalent when more than one CDN serves the same properties. It covers ownership of policy, alignment of web application firewall rules, parity in bot defenses, consistent rate limiting, origin authentication, secrets handling, configuration drift control, verification, logging normalisation, and incident procedures. The aim is a uniform security posture that does not depend on which provider handled a request.
Scope and objectives
Security parity means that requests receive the same protection and the same outcomes independent of provider. Rules must be functionally equivalent, telemetry must be comparable, and emergency controls must have the same effect at all edges. Differences in vendor features are handled by choosing portable constructs first and by documenting exceptions that cannot be avoided.
Control inventory and ownership
A single source of truth for security policy reduces drift. The inventory should enumerate WAF rule groups, allow and deny lists, bot and automation controls, rate limits, TLS and client authentication requirements, and origin access rules. Ownership resides with a team that can assess risk, approve changes, and run drills. Vendor specific toggles are tracked as implementation details under the same policy items so that semantic intent remains clear.
WAF rules alignment
Rule sets must block the same classes of attack and allow the same application behavior at all providers. Managed WAF packs differ in naming and severity; alignment uses categories and explicit allow rules that normalise behavior. False positive handling is consistent by describing exceptions at the URL or parameter level, not by vendor identifiers. Where one provider lacks an equivalent managed rule, custom rules approximate intent with clear documentation of any residual risk. Versioning of rule sets allows rollback and reproducible audits.
Bot management parity
Automation controls must distinguish between legitimate automation, partner integrations, and abuse. Signal sources differ by vendor, so the contract is defined in terms of observable behaviors such as request rates, header quality, JavaScript or device challenges, and token presence. Challenge types and failure actions are harmonised so that legitimate sessions do not break when routing changes provider. Any device fingerprinting or client classification that uses personal data requires a documented legal basis and regional controls.
Rate limiting and abuse mitigation
Limits protect application resources and backends from burst and abuse. Parity requires the same keys, windows, and actions. Keys are defined in terms of client identity or request attributes that exist across providers, such as IP with optional header based augmentation where trusted. Windows and thresholds are set so that limits do not flap when traffic moves between providers. Actions for over limit events match across vendors, including response codes and cooldown behavior. Limits that depend on dynamic customer tiers are computed in a control plane and pushed to both providers.
Origin authentication and allowlists
Traffic from CDNs to origin must present strong identity. Mutual TLS authenticates callers and avoids reliance on source IP alone. Where IP controls are required, provider egress ranges are tracked and updated through an automated process. Header based tokens allow fine grained authorisation and can carry claims about the route, but must be scoped and rotated. The same authentication and authorisation checks apply regardless of the provider that forwarded the request.
Secrets and key management
Keys, certificates, and tokens are generated, stored, rotated, and revoked under the same procedures for all providers. Access is least privilege and audit trails are preserved. Where a provider stores keys in hardware backed modules, the inventory reflects storage location and export policy. Rotation windows and notBefore or notAfter dates are coordinated so that overlapping validity prevents outages during rollout.
Configuration drift and change control
Drift occurs when semantically identical policies are not implemented identically. Preventive controls include policy templating, code review, and automated translation to each vendor format. Detective controls include periodic diffs of live configuration and conformance checks that compare effective behavior against intent. Changes are batched and applied in a defined order, with verification at each step. Emergency changes follow a documented fast path that still records the diff and triggers post change validation.
Testing and verification
Security behavior is verified with synthetic requests that exercise positive and negative paths. Tests run against each provider and include rule hits, challenge outcomes, allow rules for expected traffic, and rate limit boundaries. Application integration tests confirm that legitimate flows continue to operate. Real user telemetry and error budgets capture regressions that occur only under production traffic. Verification is a gate in deployment and also a recurring job that detects unintended changes.
Logging and normalisation
Logs must carry comparable fields across providers. Request ids, rule identifiers, action taken, upstream selection, and origin outcome are mandatory for investigations. A normalisation layer maps vendor fields to a common schema so that dashboards and alerts operate on the same dimensions. Retention policies reflect legal and operational requirements, with regional controls where data residency applies. Sensitive fields are redacted at ingestion where feasible.
Incident operations
During a security incident the ability to disable a route, raise block severity, or pin traffic to a provider must exist and must be predictable. Runbooks list switches and their expected effects. Provider contacts and escalation paths are recorded. After the event, differences in rule performance are analysed and permanent parity improvements are scheduled. Emergency overrides that deviate between providers are removed or adjusted so behavior remains aligned.
Compliance and audit
Controls and procedures must be auditable. The policy source of truth, change records, test evidence, and incident timelines constitute the audit package. Regional rules such as data protection requirements are implemented with the same routing constraints and logging filters at each provider. Vendor features that process personal data are documented with purpose and legal basis.
Related chapters
For transport security and certificate lifecycle see /multicdn/tls-certificates/. For origin path controls see /multicdn/origin-architecture/. For routing effects that interact with policy see /multicdn/traffic-steering/.
Further reading
OWASP guidance on WAF evaluation and false positive handling provides vendor neutral criteria. RFC 8446 defines TLS 1.3 and supports mutual authentication patterns. Provider references for bot mitigation and rate limiting should be reviewed for parity gaps and limits.