很多CDN事故没有复杂漏洞：源站IP仍可直接访问，测试域名忘记下线，缓存规则把Set-Cookie页面公开保存，或一个离职账号继续持有全局API权限。攻击者最喜欢的，往往不是最深的漏洞，而是长期没人检查的默认项。
配置错误之所以成为安全黑洞，是因为系统表面仍在工作。页面能打开、证书也有效，只有在攻击、权限滥用或数据泄露时才暴露问题。治理这类风险，需要把配置当代码管理，而不是控制台里的临时操作。
错误一：源站与备用入口仍然暴露
只要攻击者找到源站IP、旧域名或未受保护端口，就可以绕过CDN的DDoS、WAF和Bot策略。历史DNS、邮件头、证书记录、错误页面和第三方监控都可能泄露线索。
源站应限制为可信回源地址，使用回源证书或签名，并关闭不必要端口。备用线路也必须应用等价安全策略，不能成为长期开放的“紧急后门”。
错误二：缓存规则过于宽松
按文件后缀缓存所有响应、忽略Authorization、未处理Set-Cookie、把错误页长时间缓存，都可能造成隐私泄露或故障扩大。缓存键遗漏语言、设备或关键请求头，还会让用户看到错误版本。
建议从明确允许列表开始，只缓存确定公开且可共享的内容。动态接口默认不缓存，再逐个评估。规则变更前使用代表性账号和路径做命中验证。
错误三：TLS与证书管理停留在最低可用
仍支持过时协议和弱密码套件，会增加降级与兼容风险。证书自动续期没有告警、回源忽略证书校验、多个环境共享私钥，也会让加密链路失去可信基础。
客户端到边缘、边缘到源站都要验证TLS。证书与私钥按环境分离，续期失败提前告警，旧协议是否保留应基于真实客户端数据而非猜测。
错误四：防盗链和访问控制只看Referer
Referer可以缺失或伪造，单靠它无法保护高价值下载和视频。配置过严又会误伤隐私浏览器、App和正常分享。对于付费内容，应使用短时Token、路径与用户绑定、有效期和签名校验。
访问控制还要考虑IPv6、代理链和真实IP来源。直接信任外部X-Forwarded-For，会让基于IP的限速和白名单失效。
错误五：控制台权限与变更无人审计
共享管理员账号、永久API密钥、没有MFA和大范围权限，是配置接管的常见前提。安全规则、DNS、证书和源站修改应属于高风险动作，需要审批、通知和回滚。
把配置导出到版本库，使用自动化检查比较预期与实际状态。每次上线生成变更记录，定期回收闲置账号与令牌。这样才能发现“谁在什么时候改了什么”。
用配置基线发现“悄悄变化”
每晚自动导出域名、源站、缓存、证书、WAF和账号配置，与批准的基线比较。新增公网源站、关闭回源校验、扩大令牌权限、延长缓存时间等变化，即使尚未引发故障，也应进入审查。对紧急变更设置到期时间，避免临时放行永久存在。
基线不能只保存在同一个CDN控制台里。独立版本库或配置平台应保留历史和审批记录，并限制写入权限。发生账号接管时，团队才能知道攻击者改了哪些内容，并用可信版本快速恢复。
落地检查清单
- 验证源站与备用域名不可绕过CDN
- 动态与含身份响应默认不做公共缓存
- 客户端和回源链路均验证现代TLS
- 高价值资源使用短时签名而非仅靠Referer
- 控制台启用MFA、最小权限与变更审计
- 定期做配置漂移检查
结语
CDN配置安全没有炫目的技术，但它决定所有高级防护是否真正生效。把默认拒绝、最小权限、配置版本和持续验证变成日常流程，能消除大量低成本却高影响的攻击机会。
