你在CDN上可能忽略的安全漏洞
配置前的检查
说到CDN Web，很多问题都出在细节上。当你登录某个网站后，系统提示“欢迎回来”，随后你访问了一份只有自己才能看到的账单明细。但如果此时另一个用户输入了同样的URL，居然也看到了你的账单——这不是黑客入侵了服务器，而是你的CDN在帮你“共享”数据。这个场景就是Web Cache Deception（Web缓存欺骗）的真实写照。
很多开发者和运维人员对CDN缓存的认知停留在“加速”层面，却忽略了错误的缓存规则会导致敏感信息被公开缓存。本文从零开始，帮你理清缓存欺骗的原理、攻击手法和防御配置，让你能够立刻检查自己的CDN是否存在这类隐患。
相关阅读：此处可内链到“CDN Web常见问题”专题。
关联教程：此处可内链到“CDN Web部署与验证”内容。
进阶阅读：此处可内链到“CDN Web性能优化”指南。
什么是Web Cache Deception？
实际操作要点
Web Cache Deception是一种利用CDN或反向代理缓存机制，诱使其缓存不应该被缓存的响应（通常包含用户隐私数据）的攻击技术。攻击者通过精心构造的URL，比如在正常请求后添加?.css或/nonexistent.css，欺骗CDN认为这是一个静态文件请求，从而缓存服务器返回的敏感页面内容。
整个过程分为三步：
- 攻击者诱导受害者点击一个带有特殊后缀的链接（例如
https://example.com/account?file=profile.css）。 - 受害者浏览器向服务器发送请求，服务器返回真实的账户信息页面（HTML），但CDN根据扩展名或路径规则错误地将该响应识别为可缓存资源，并存储到边缘节点。
- 攻击者随后访问同样的URL，直接从CDN缓存中获取受害者的敏感数据。
根本原因在于：CDN的缓存策略依赖于URL（或部分路径/文件扩展名）来判断是否缓存，而没有与后端响应的实际内容类型（Content-Type）或用户认证状态进行关联。
攻击为什么有效？因为你配置的“缓存规则”太宽松
故障定位思路
很多CDN服务商提供灵活的缓存规则，比如“对所有*.css文件缓存”、“对所有/static/路径缓存”。当攻击者把一个请求伪装成.css结尾时，CDN照单全收。而你的后端应用如果没有校验文件扩展名，仍会返回带有用户信息的HTML，CDN就愉快地缓存了这个“伪静态文件”。
即使你的后端返回了Cache-Control: private或Set-Cookie，如果CDN配置了“忽略源站缓存头”或“强制缓存”，缓存依然会发生。这是许多团队踩过的坑：他们以为源站标记了不缓存，CDN就会乖乖遵守，却不知CDN的强缓存优先级高于源站指令。
想继续深入：此处可内链到“CDN Web优化清单”文章。
CDN Web：真实攻击场景重现（无需实验数据，逻辑推演即可）
先看关键判断
假设你运营一个电商网站，用户登录后可以查看订单历史，URL为/order?id=12345。你希望只有登录用户才能访问，所以没有做静态化。但CDN配置了“对所有请求启用缓存，缓存时间为5分钟”。攻击者构造链接：/order?id=12345&style=order.css，并将其伪装成一张订单截图发送给目标用户。用户点击后，CDN根据URL中出现的.css判定为静态资源，缓存返回的订单页面。攻击者随后访问同一URL，直接看到订单信息。这就是一次成功的Web Cache Deception。
核心防御原则：让缓存知道“什么该存，什么不该存”
避免Web Cache Deception的关键在于：只缓存那些你明确知道是公共、无敏感信息的资源，并且让CDN响应实际响应内容的变化。 以下是一组可落地的安全配置规范：
1. 基于Cookie或认证头拆分缓存键
现代CDN（如Goedge、Cloudflare、Akamai等）支持在缓存键中包含Cookie值或自定义请求头。将Cookie或Authorization头作为缓存键的一部分，让已登录用户和未登录用户的响应被分别缓存。即使攻击者通过欺骗得到缓存，也只能看到同一用户的响应（如果该用户已登录），但无法看到其他用户的数据。需要注意的是，这会导致缓存命中率下降，但安全优先级更高。
2. 对动态路径启用“不缓存”或“验证缓存”
对于明确包含用户ID、会话ID或敏感参数的路径，应配置CDN不缓存，或使用Cache-Control: private, no-store指令。同时设置CDN的“缓存规则”忽略这些路径。例如在CDN控制面板中添加一条规则：当URL路径包含/account/、/order/、/profile/等模式时，强制不缓存。
3. 切勿仅凭文件扩展名做缓存判断
不要配置“全部.css和.js都缓存”这样大范围的规则。虽然静态资源通常不带认证信息，但攻击者可以轻易伪造。更好的做法是结合目录前缀：只缓存/static/css/下的.css文件，而不是全局.css。并且要检查后端是否对/static/路径做了严格的资源验证，拒绝非静态文件的访问。
4. 设置Vary响应头
在源站返回的HTTP头中加入Vary: Cookie或Vary: Accept-Encoding, Cookie，告诉CDN同一个URL的不同Cookie值应视为不同缓存副本。即使CDN坚持缓存，也会根据Cookie值隔离缓存条目。这是HTTP协议原生支持的机制，大部分CDN都遵守。
5. 使用CDN的WAF或访问控制规则
许多CDN提供Web应用防火墙（WAF）功能，可以检测并阻止包含可疑扩展名或路径遍历的请求。配置规则：如果请求URL看起来像静态资源（如.css、.js、.png），但实际返回的Content-Type是text/html，则拒绝缓存或标记为攻击。也可以限制只有特定目录才允许缓存静态文件。
6. 启用“缓存欺骗防护”功能（如果CDN原生支持）
部分CDN服务商直接提供了“Web Cache Deception Protection”开关。开启后，CDN会忽略用户请求中的额外查询参数（如?dummy.css），或者强制要求后端验证内容类型后才缓存。例如Cloudflare的“Cache Deception Armor”功能就是专门针对此漏洞设计的。如果使用自建CDN（如Goedge），可通过边缘脚本或插件实现类似逻辑。
CDN Web：如何验证你的配置是否有效？
先看关键判断
部署完毕后，建议进行以下自查：
- 使用未登录的浏览器访问一个需要登录的页面，加上
?fake.css或/fake.css，检查是否返回登录页面（理想结果）或缓存了该页面。 - 以登录用户身份访问，然后立即用无痕窗口打开同一URL（加上欺骗后缀），观察是否展示了登录用户的敏感信息。如果展示了，说明缓存规则有漏洞。
- 检查CDN节点返回的响应头中是否包含
X-Cache: HIT，如果命中，说明该响应被缓存了。 - 验证源站返回的
Cache-Control和Vary头是否被CDN遵守。可以在CDN的日志中查看缓存行为。
补充参考：此处可内链到“CDN Web故障排查实例”。
回滚与调优思路
配置前的检查
如果你因为过度收紧缓存规则而导致了页面加载变慢或服务器压力增大，不要慌张。安全与性能的平衡是可调整的：
- 对于确实需要缓存且不包含用户信息的页面（如公开展示的文章页），可以通过增加
Vary: Accept-Encoding而不加入Cookie，同时确保这类页面不返回任何用户个人信息。 - 使用“按Cookie拆分缓存键”后，如果缓存命中率过低，可以考虑将缓存时间适当延长（如从1分钟到10分钟），但要配合“当用户信息变化时主动刷新缓存”的机制。
- 最安全的做法是：默认所有动态请求不缓存，仅对明确标记为公开且安全的静态CDN资源（如版本化CSS/JS、图片）启用缓存。
总结：从原理到实践，把缓存欺骗关在门外
配置前的检查
Web Cache Deception不是一个新漏洞，但它每年依然导致大量数据泄露事件。根本原因不是CDN有缺陷，而是配置者没有意识到“缓存”与“动态内容”结合的副作用。作为运维或开发者，你需要建立以下认知：CDN缓存必须是可预期的、受控的，不能仅仅因为URL末尾多了个点就无条件信任。
从今天开始，检查你的CDN缓存规则：是否存在通配符扩展名？是否忽略了Cookie？是否强制覆盖了源站的“private”指令？根据本文提供的规范逐一修复，你的用户数据安全就能多一道坚实的屏障。按这个顺序复查，CDN Web遇到异常时也更容易定位。
延伸阅读