Cloudflare 宣布推出 Application Profiles，这是一种旨在将正向安全理念从 API 扩展到 Web 应用的机制。该服务不再仅仅将请求与已知攻击特征进行比较，而是学习成功请求的结构，然后验证后续请求是否符合这一模式。
该功能基于 Schema Profiles，后者会定期分析流量，以确定路径、查询参数、请求头、Cookie 中存在的变量，以及 JSON 或 form-encoded 格式请求正文的结构。它还会学习数据类型和约束，例如整数、字符串、布尔值、数组、UUID 标识符和枚举值，以及数字范围、字符串长度和字符类别。
实际会发生什么变化？
针对某个操作的配置文件生成后，Cloudflare 会在实时流量上启用持续验证层。如果某个路径预期接收 UUID，或者 product_id 的值必须是在学习所得范围内的整数，那么当收到畸形值、字符串值或超出范围的值时，系统可以将该请求记录为不匹配。这并不要求请求匹配 SQL 注入、跨站脚本或远程代码执行等已知攻击特征。
不匹配信号不会自动触发操作。结果会被添加到请求数据中，团队可以在 Security Analytics 中进行审查，然后创建 Security Rules 用于监控或阻止。Cloudflare 还提供名为 Profile Analysis 的选项卡，用于展示趋势、匹配和不匹配的请求、违规位置及其原因。规则还可以应用于整个应用，或应用于特定路径、操作和字段。
学习过程需要人工审查
该学习流程按区域每周运行一次，使用最新的成功流量。要学习字段，过去七天内至少需要 1,000 个返回 2xx 状态码的请求；要学习值的边界，则需要 10,000 个请求。不过，成功请求可能包含机器人和扫描工具，因此 Cloudflare 建议先以监控模式启动，并在强制执行之前审查配置文件。
不匹配并不一定意味着存在攻击；它也可能源于应用的新版本、新客户端，或一个有效但不常见的请求。配置文件每周更新，添加新出现的字段并删除不再出现的字段；同时还可以将其导出为 OpenAPI v3 文件，并通过 Schema Validation 固定某个版本。
可用性与限制
使用 API Security 的客户可以访问该功能；与此同时，Cloudflare 已为受邀且未使用 API Security 的 Enterprise 客户启动封闭测试计划。加入测试计划并不意味着未来一定会在某个特定套餐中提供该功能。
- 该功能支持路径、查询参数、请求头、Cookie，以及 JSON 和 form-encoded 请求正文。
- 目前不支持 multipart、GraphQL 或 XML 格式。
- 它可以验证数字和文本类型、UUID、数组，以及最多包含三个值的枚举。
- 它不会强制要求重复参数名称具有唯一性，也不会学习必需参数；请求仅仅包含新参数时，也不会因此阻止该请求。
为什么这一发展很重要？
Cloudflare 表示，生成式人工智能模型的普及使攻击载荷更容易被生成、修改和自动化测试，从而提升了定义可接受内容的控制措施的价值，而不是追踪每一种已知攻击形式。这里的实际价值并不是取代托管式 WAF 规则，而是增加一层限制，缩小能够到达应用处理程序的输入范围。
公司正在利用部署在 Workers AI 上的模型，增加上下文和优先级分析，以将字段名称与其潜在功能关联起来，并提出保护措施建议。不过，这些能力仍处于开发计划或测试阶段，而且配置文件的准确性取决于用于学习的流量质量和规模；因此，逐步部署以及在阻止之前进行审查，仍是两个基本条件。