Cloudflare Client-Side Security 开放后怎么用：第三方脚本资产盘点、检测边界与上线核验

网页结账没有报错，不等于页面里的第三方 JavaScript 没有风险。Cloudflare 在 2026 年 3 月 30 日的官方公告中宣布，Client-Side Security Advanced（此前称为 Page Shield add-on）可以自助开通，同时把基于域名的威胁情报放进免费的 Client-Side Security bundle。对站点负责人来说，重点不是“装一个扫描器”，而是先盘点页面实际加载了哪些脚本，再把变更、恶意意图和告警复查接到发布流程里。

先分清公告里开放的两层能力

Cloudflare 的公告页给出的变化有两个层次：Client-Side Security Advanced 由原来的 Page Shield add-on 改为可自助开通；免费 Client-Side Security bundle 则提供 domain-based threat intelligence。两者都围绕浏览器端资源，但可用范围不要混写。

把第三方脚本盘点成可复查的资产表

官方文档的 Overview 页面把能力拆成 Resource monitoring、Page attribution、Malicious script detection、Code change detection 和 Alerts。这个顺序很适合落地：先知道资源是什么，再知道它在哪个页面出现，之后才有条件判断脚本是否变更或触发检测。

资产表至少保留四列：脚本 URL 或域名、首次出现页面、最近一次代码变更、当前告警状态。支付页、登录页和个人资料页应单独标记，因为同一个第三方脚本出现在普通内容页和支付流程页，业务影响完全不同。

检测结果为什么不能直接等同于攻击结论

Cloudflare 公告说明，客户端安全会分析脚本的行为意图。其检测链路先用图神经网络观察 JavaScript 抽象语法树的结构；被判定为潜在恶意的脚本，再交给 Cloudflare 网络内的模型做语义复核。这个设计的价值在于降低误报，但它仍然是检测和分流信号，不是替代业务人员调查的最终裁决。

实务上可以把告警分为三档：普通页面的首次出现先补资产信息；关键页面的代码变更要求脚本供应商和发布记录对照；恶意意图告警则先限制影响范围、保留证据，再由安全和业务负责人决定是否阻断。这里别急着把所有第三方脚本一次性删掉，支付 SDK、统计组件和客服组件的处置方式并不相同。

上线前用四个检查点完成闭环

1. 代理范围。确认目标域名和关键页面确实经过 Cloudflare，避免面板里有配置、实际请求却走了旁路。
2. 基线完整。对照资源监控清单检查登录、结账、支付回跳等页面，补齐脚本来源和页面归属。
3. 变更可解释。把代码变更时间与发布单、供应商通知或依赖升级记录对上；对不上时先暂停放量。
4. 告警可处置。明确谁看告警、谁能调整规则、谁负责回滚，并在一次低风险发布中验证通知确实能到达。

这四步的验收结果最好和版本号或发布日期绑定保存。客户端脚本会更新，今天没有告警只说明当前观察窗口内没有命中已配置的检测条件，不能替代下一次发布前的复查。

常见问题

Client-Side Security 能替代网站 WAF 吗？

不能。WAF 主要观察到达站点的请求和攻击特征，客户端安全关注浏览器加载的脚本、资源变化与页面侧风险，两者保护面不同。

只记录脚本域名就够了吗？

不够。还要记录脚本在哪些页面出现、最近是否变更以及对应告警状态，否则无法判断关键页面上的实际影响。

发现第三方脚本变更后应该立即删除吗？

先对照发布记录和供应商说明，确认变更内容与业务用途；若出现在支付或登录页面且无法解释，再按预案限制加载或回滚。

免费 Client-Side Security bundle 和 Advanced 怎么选？

先按官方当前可用性确认免费 bundle 能覆盖的域名情报能力，再根据是否需要代码变更监控、阻断规则和更完整的处置能力评估 Advanced。

把安全能力接到发布节奏里

Cloudflare 这次开放的实际价值，不是让团队多一个孤立面板，而是让第三方脚本从“页面里悄悄加载的依赖”变成能盘点、能对照、能追责的资产。先建立资源和页面归属基线，再把代码变更、恶意脚本检测、告警复查嵌入发布检查单，站点才有机会在脚本影响用户之前发现异常。