当攻击者把恶意脚本注入网页时，CDN边缘节点并不总是第一道防线，但合理配置缓存与过滤机制可以显著降低XSS攻击的破坏面。本文基于Cloudflare官方文档，给出判断路径：先确认哪些资源适合缓存，再决定在边缘层实施何种过滤，最后用DDoS防护兜底。整个过程不需要改源站代码，但需要理解边缘节点的行为边界。
先判断：哪些请求需要边缘层过滤
CDN边缘节点默认只缓存静态资源（图片、CSS、JS等），动态页面通常回源。因此，XSS防护的过滤机制应聚焦于两类场景：一是缓存命中时直接返回的内容，若缓存内容被污染（如存储型XSS），边缘节点会持续分发恶意数据；二是边缘计算（如Cloudflare Workers）拦截的请求，可在到达源站前清洗参数。判断路径：如果你的站点大量使用缓存，优先检查缓存键和缓存规则；如果依赖动态交互，则用Workers做请求级过滤。
缓存机制：控制哪些内容可被边缘节点存储
Cloudflare缓存官方文档指出，缓存将频繁访问的内容（图片、视频、网页）存储在地理分布的数据中心，靠近用户，减少源站负载。默认缓存行为覆盖特定文件扩展名，但HTML页面默认不缓存（除非配置Cache Rules）。实操中，你应通过Cache Rules指定哪些URL需要缓存、缓存时长，并利用Purge功能强制刷新。关键点：不要缓存包含用户输入或个性化内容的页面，否则攻击者构造的恶意页面可能被缓存并分发给其他用户。配置建议：对静态资源设置长缓存，对动态页面设置短缓存或绕过缓存。
过滤机制：在边缘节点清洗请求与响应
边缘节点的过滤通常依赖Cloudflare Workers。Workers是部署在Cloudflare全球网络上的服务端平台，可用几行代码实现请求拦截、响应改写。例如，你可以编写Worker检查查询参数中的<script>标签并返回403，或对响应内容进行输出编码。但注意：Workers无法替代源站防护，因为边缘节点只处理经过它的流量，且过滤规则需自行维护。常见误区是期望Workers能自动检测所有XSS变体，实际上它只能匹配已知模式，建议结合WAF托管规则使用。
DDoS防护：兜底层，防止攻击绕过过滤
Cloudflare DDoS防护文档说明，其自动系统可检测并缓解L3/4和L7层攻击。虽然DDoS防护主要针对可用性，但某些XSS攻击会伴随流量洪峰（如反射型XSS配合大规模请求），DDoS防护能缓解这类压力。配置时，使用托管规则集并调整敏感度。注意：DDoS防护不检测XSS载荷，它只是保证边缘节点在攻击下仍能响应，为过滤规则争取时间。
实操步骤：从零配置边缘节点XSS防护
- 评估缓存策略：在Cloudflare Dashboard的Caching > Configuration中，查看默认缓存行为，使用Cache Rules为敏感URL设置“Bypass cache”。
- 编写过滤Worker：在Workers中创建新脚本，监听fetch事件，解析URL和请求体，若检测到危险字符（如
<script>）则返回自定义错误页。部署后绑定到需要防护的域名。 - 启用DDoS保护：在Security > DDoS中确保“HTTP DDoS attack protection”已开启，保留默认规则，或按需调整阈值。
- 测试与监控：使用curl模拟恶意请求，确认Worker返回预期响应；查看Analytics中的缓存命中率和安全事件。
常见误区与失败条件
- 误区一：缓存所有HTML：这会导致动态页面被缓存，用户A的会话数据可能泄露给用户B。失败条件：登录后页面缓存命中，返回他人数据。
- 误区二：依赖单一过滤规则：XSS绕过技术繁多，正则过滤易被编码变体绕过。失败条件：攻击者使用
<script>编码，规则未识别。 - 误区三：忽略缓存清除：当源站修复漏洞后，若未清除CDN缓存，旧版本仍会被分发。失败条件：修复后用户仍看到恶意内容。
- 误区四：混淆DDoS防护与XSS检测：DDoS防护不检查载荷，XSS仍需应用层过滤。失败条件：攻击者发起低流量XSS请求，DDoS无反应。
适用条件与不确定性
以上机制基于Cloudflare公开文档，但实际效果受站点架构影响。若你的CDN供应商不支持边缘计算，则无法实现自定义过滤，只能依赖WAF或源站防护。缓存策略需根据业务测试调整，缓存时间过长可能影响更新，过短则降低性能。建议先在测试环境验证，再逐步上线。
参考资料
延伸阅读