电商网站可能看起来一切正常：页面能打开、支付能完成、监控没有报错，恶意 JavaScript 却在浏览器里悄悄劫持点击、篡改分析数据，甚至将交易收入导向攻击者。传统扫描器擅长检查静态文件和已知特征，但面对只在特定用户、特定时间或特定交互后执行的脚本，单次扫描很容易扑空。
Cloudflare Client-Side Security 所代表的思路，是把观察点放到客户端脚本的实际行为上，再通过机器学习模型从大量信号中找出值得分析人员调查的异常。这并不意味着机器学习可以自动证明某段代码有罪，而是用它缩小排查范围，让隐藏在正常第三方脚本和动态加载链路中的攻击更容易浮出水面。
为什么页面扫描显示“健康”，攻击仍在发生
现代店面的前端依赖分析、广告、客服、支付、标签管理器和个性化推荐等大量第三方代码。浏览器最终执行的内容，往往不等于构建仓库里能够看到的内容。
攻击者可以利用这种差异隐藏行为：
- 按条件触发：只针对特定地区、设备、来源页面或小比例访问者执行。
- 延迟执行：等待用户点击结账、填写表单或停留一段时间后再启动。
- 动态加载：初始脚本看起来无害，运行后才从其他域名拉取下一阶段代码。
- 混入供应链：被入侵的第三方服务仍使用合法域名和正常文件名。
- 快速变形：不断改变变量名、编码方式和加载路径，绕过基于固定特征的检测。
- 保持页面可用：不破坏结账流程，只复制数据、改写链接或污染归因信息，因此可用性监控不会报警。
这也是客户端攻击难以依靠定时扫描解决的原因：扫描器看到的是一个时间点的页面快照，攻击发生在真实浏览器的运行过程里。
机器学习的价值是排序，而不是替代判断
面对数十甚至数百个第一方和第三方脚本，安全团队真正缺少的通常不是更多原始日志，而是有效的调查顺序。根据来源摘要，Cloudflare 使用机器学习模型暴露规避性较强的客户端攻击，并把结果交给分析人员调查。
一个合理的分析流程通常会关注以下变化：
- 页面是否开始加载以前没有出现过的脚本或域名。
- 某个已知脚本的行为是否突然偏离历史模式。
- 结账页、登录页等敏感页面是否出现新的外部通信。
- 异常是否只影响部分会话，或仅在特定交互后出现。
- 脚本变更是否能与一次经过审批的发布对应起来。
模型适合发现偏差并对事件排序，分析人员则需要结合发布记录、供应商变更和业务上下文确认风险。一个新域名可能是恶意载荷，也可能是刚上线的支付组件；如果没有资产清单和变更记录，两者很难快速区分。
可以这样实践：先收集 CSP 报告
即使尚未部署完整的客户端安全平台，也可以先用 Content Security Policy 的 Report-Only 模式建立可见性。下面是一个最小 Flask 接收器，可接收浏览器发送的 CSP 报告。
运行前需要安装 Python 3，并把生产环境中的报告地址、日志存储和访问控制替换成自己的配置。
mkdir csp-observer && cd csp-observer
python3 -m venv .venv
. .venv/bin/activate
pip install flask
cat > app.py <<'PY'
from datetime import datetime, timezone
from flask import Flask, jsonify, request
import json
app = Flask(__name__)
@app.post("/csp-report")
def receive_report():
payload = request.get_json(silent=True)
if payload is None:
return jsonify({"error": "invalid JSON"}), 400
event = {
"received_at": datetime.now(timezone.utc).isoformat(),
"report": payload,
}
print(json.dumps(event, ensure_ascii=False), flush=True)
return "", 204
@app.get("/healthz")
def health():
return jsonify({"status": "ok"})
if __name__ == "__main__":
app.run(host="127.0.0.1", port=8080)
PY
python app.py
另开一个终端验证接收器：
curl -i http://127.0.0.1:8080/csp-report \
-H 'Content-Type: application/csp-report' \
--data '{"csp-report":{"document-uri":"https://shop.example/checkout","violated-directive":"script-src-elem","blocked-uri":"https://unexpected.example/payload.js"}}'
生产站点可以在 HTTP 响应中先加入只报告、不拦截的策略：
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' https://trusted-payments.example; report-uri https://security.example/csp-report
需要修改的内容包括：
- 将
trusted-payments.example换成经过核准的脚本来源。 - 将
security.example换成自己的 HTTPS 报告接收端点。 - 根据图片、字体、接口和内嵌脚本的实际使用情况补充指令。
- 先使用
Report-Only观察误报，再逐步切换到强制策略。
不同浏览器支持的报告格式可能不同，生产接收器还应加入请求大小限制、速率限制、鉴权或来源校验，并避免把报告中可能出现的完整 URL 查询参数直接写入长期日志。
CSP 报告并不能替代 Cloudflare Client-Side Security：它主要揭示策略违规，而更完整的客户端安全监测还需要识别动态脚本、行为变化和低频异常。不过，这个最小方案能帮助团队建立域名基线，并验证告警是否可以进入现有的 SIEM 或事件响应流程。
从告警到调查：建立可执行的处置链
检测到陌生脚本后，不要立即把整个域名永久加入黑名单。更稳妥的调查顺序是：
- 确认影响页面：判断异常是否出现在首页、登录页、购物车或结账页。
- 核对变更记录：检查标签管理器、CDN、第三方供应商和前端发布记录。
- 保存证据：记录脚本 URL、响应内容、加载链路、时间和受影响会话范围。
- 进行隔离：在确认风险后，通过 CSP、边缘规则、标签管理器或应用配置停止加载。
- 检查后续影响：审查支付、分析归因和跳转目标是否已被修改，并评估数据暴露范围。
- 修复信任关系：轮换相关凭据，收紧供应商权限，将新的可信基线纳入持续监测。
需要注意，删除一个脚本并不等于完成事件响应。攻击入口可能位于被盗的标签管理器账号、第三方供应链、构建系统或站点管理后台。如果只处理浏览器里看到的最终载荷，攻击者可能很快换一个地址重新投放。
上线前的检查清单
将客户端安全能力接入店面时，可以按以下顺序推进：
- 盘点结账、登录和账户页面上的所有脚本及责任人。
- 为新增第三方代码建立审批和到期复核机制。
- 先观察正常行为基线，再为异常域名和脚本变化设置优先级。
- 将机器学习产生的异常分数视为调查线索，而不是最终定性。
- 把告警关联到发布记录、供应商清单和页面敏感级别。
- 演练脚本隔离流程，确保安全团队能快速止损而不破坏交易。
- 同时保留 CSP、子资源完整性、最小权限和账号保护等防御层。
客户端安全的关键不是再做一次静态扫描，而是持续回答一个更贴近风险的问题：真实顾客的浏览器此刻究竟在执行什么。Cloudflare 的机器学习模型可以帮助分析人员从噪声中发现规避性攻击，但最终效果仍取决于清晰的脚本资产清单、可靠的变更流程和能够迅速采取行动的响应机制。