Fastify 安全策略深度解读：威胁模型、漏洞界定与负责任的披露流程

Fastify 的 SECURITY.md 不仅是一份漏洞上报指南，更完整定义了框架的安全边界：哪些输入被视为不可信、哪些问题属于框架漏洞、哪些问题属于应用层责任，以及从报告、分诊到公开披露的时间线承诺。本文以该文档为主体，结合 lib/ 目录下的核心源码与测试用例，逐条解读其威胁模型与处理流程，帮助你在提出安全报告前准确判断问题归属，也帮助框架用户理解 Fastify 内置防护的实际实现位置。

一、适用范围与版本前提

该文档明确声明其覆盖范围是 “Fastify 项目及其官方插件（official plugins）” 的漏洞管理。需要注意以下适用前提：

• 当前仓库 main 分支对应 Fastify v6 的发布线，package.json 中版本号为 6.0.0-alpha.2；README 同时提示 5.x 分支对应 v5 维护线。文中所述策略适用于以 main 分支为基准的开发与安全协作。
• 策略中所有“框架漏洞”与“非漏洞”的界定，都建立在第二节所述威胁模型的假设之上；脱离这些前提的结论不适用。

二、威胁模型：可信与不可信的边界

Fastify 的威胁模型（Threat Model）在 Node.js 官方安全策略的基础上进行了扩展，其核心是把系统中的一切都划分为两个阵营：

可信（Trusted）：

• 应用代码——插件（plugins）、处理器（handlers）、钩子（hooks）、模式（schemas）；
• 配置（configuration）；
• 运行环境（runtime environment）。

不可信（Untrusted）：

• 一切网络输入——HTTP 请求头、请求体（body）、查询字符串（query strings）、URL 参数。

这条边界直接决定了后文“漏洞”与“非漏洞”的划分逻辑：凡是由可信一侧引入的问题（开发者写错了 schema、配错了选项、写了有缺陷的正则），都不构成对框架本身的漏洞报告对象；只有当不可信一侧的输入能够突破框架自身的解析、校验或防护机制时，才落入 Fastify 安全团队的处置范围。

此外，文档设定了一个明确的运行时假设：Fastify 假定 Node.js 以 insecureHTTPParser: false（安全默认值）运行。任何开启了 insecureHTTPParser: true 的部署都位于 Fastify 威胁模型之外，依赖该开关的报告一律不予受理。这意味着框架层面的安全承诺只对 Node.js 安全默认配置下的部署成立。

三、什么算作 Fastify 的漏洞

文档列举了三类被认定为框架漏洞的情形：

1. 绕过校验或安全控制的解析缺陷（Parsing flaws that bypass validation or security controls）——即网络输入在框架的解析管线中“逃过”了本应生效的防护；
2. 通过畸形输入对 Fastify 核心发起的拒绝服务（DoS through malformed input to Fastify's core）——注意限定词是“Fastify 的核心”，而不是业务 handler；
3. 绕过内置保护机制（Bypasses of built-in protections），文档点名了两项内置保护：原型链污染防护（prototype poisoning）与 schema 校验。

这两项内置保护在源码中都有对应实现，可以印证威胁模型的落地方式：

• 原型链污染防护：lib/content-type-parser.js 中的 ContentTypeParser 构造器使用 secure-json-parse 提供的安全解析函数作为默认 JSON 解析器，并将自定义解析器存放在 Map 中，源码注释明确写道 “using a map instead of a plain object to avoid prototype hijack attacks”。默认行为下，收到含 __proto__ 的 JSON 请求体会返回 400 错误；测试 test/proto-poisoning.test.js 验证了这一默认路径（请求体 '{ "__proto__": { "a": 42 } }' 触发 result.status === 400，handler 不会被调用）。框架同时提供 onProtoPoisoning: 'remove'（剔除污染键后继续处理）与 onProtoPoisoning: 'ignore'（保留污染键）两种策略，分别由同文件测试中的 “proto-poisoning remove” 与 “proto-poisoning ignore” 用例覆盖。相关背景可参阅仓库内的 Prototype Poisoning 指南。
• Schema 校验：lib/validation.js 负责在路由上下文中编译 headers、params、querystring、body 与 response 的校验/序列化器（如 compileSchemasForValidation 与 compileSchemasForSerialization）。绕过这条管线的输入处理缺陷即属于上表第 1、3 类漏洞。

四、什么不算漏洞：完整边界清单

这一节是文档中信息密度最高的部分。它逐条列出了 不 被视为 Fastify 漏洞的情形，其共同逻辑都源自第二节的可信边界。逐条对照如下：

非漏洞类别	说明	源码/文档佐证
应用代码漏洞	用户自写的 route handler、hooks、plugins 中的 XSS、SQL 注入等缺陷	应用代码属于“可信”，框架不为其兜底
恶意应用代码	由蓄意作恶的插件或 handler 引发的问题	同上，可信一侧的主动行为不在范围内
校验 schema 问题	开发者提供过弱或不正确的 schema	schema 属于可信；schema 的编译与执行见 lib/validation.js
用户正则的 ReDoS	路由或校验中用户提供的正则表达式导致的正则拒绝服务	正则来自应用代码，属可信域
缺失的安全特性	缺少限流（rate limiting）、认证、授权等	这些是应用层职责，不是框架核心能力
配置错误	由开发者错误配置导致的安全问题	配置属于可信；例如显式开启导致错误细节外泄的选项
内容类型解析器与 schema 不匹配	用正则注册的自定义 content-type parser（如 /^application\/.*json$/）匹配到了路由 schema.body.content 中没有对应键的请求，导致该请求跳过校验。文档明确这属于配置责任：应用必须确保 parser 接受的每种 content type 都有对应的校验 schema 条目	解析器匹配逻辑见 lib/content-type-parser.js；相关文档为 Content-Type Parser 参考 与 Validation and Serialization 参考
开启 insecureHTTPParser: true 的部署	任何依赖该非安全开关的报告均超出范围	对应第二节运行假设
第三方依赖	应用所用 npm 包（非 Fastify 核心依赖）的漏洞	核心依赖与业务依赖的责任边界不同
handler 中的资源耗尽	用户 handler 中昂贵操作引发的 DoS	与“对框架核心的 DoS”相对照
设计上的信息泄露	通过配置选项显式开启的错误细节或堆栈信息暴露	显式配置即视为开发者知情选择

特别值得展开的是“内容类型解析器与 schema 不匹配”这一条：这是正则型 content-type parser 使用中的一个真实陷阱。Fastify 的 body 校验以 content type 为键从 schema.body.content 中查找 schema，若某个被正则 parser 接收的 content type 在映射表中不存在对应条目，该请求将不做 body 校验即进入 handler。文档将其定性为“configuration concern, not a framework vulnerability”，即框架不会自动拒绝这种不一致，责任在应用侧。这也提示使用者：注册正则型 parser 时，应保证 schema.body.content 的键集合能够覆盖 parser 实际接收的所有 media type。

五、如何报告漏洞

上报渠道与规则如下，报告前必须逐条确认：

• 唯一渠道：通过 GitHub 的 Security Advisories 页面（GitHub Security 页面新建漏洞报告）提交。文档同时强调，Fastify 项目不支持任何在此流程之外的报告方式。
• 不要自行要求分配 CVE：CVE 的分配由 Fastify 安全团队在处理流程中完成。Fastify 隶属于 OpenJS Foundation CNA，CVE 会作为负责任的披露流程的一部分被分配。
• HackerOne 计划已关闭：文档以备注形式明确 “Fastify's HackerOne program is closed”，不要再向该渠道提交。

报告时的严格规则

文档列出了三条“务必遵守”的规则，理由是保护整个生态系统不被不当报告冲击：

1. 避免创建“信息性（informative）”报告。只有在确信应当被标记为真实漏洞时才创建新报告。因为第三方厂商和个人（文中举例 snyk、npm audit 一类安全工具生态）都在跟踪 GitHub 上新报告的漏洞，并会将其标记给它们的客户——误报会产生真实的生态噪音。
2. 报告与分诊不得由同一人完成。无论是你为自己发现的漏洞报告，还是代为报告，始终应有第二名安全团队成员进行分诊。拿不准时，应邀请更多 Fastify Collaborators 帮助判定报告的有效性；无论如何，报告都必须走下面描述的、邀请维护者评审并确认漏洞的相同流程。
3. 不得通过向 Fastify 组织下任何仓库提交 pull request 来演示 CI/CD 漏洞。文档警告这样做会被 GitHub 作为未经请求的利用尝试（unsolicited exploit）处理并导致内容举报。正确做法是：新建一个与你想要报告的仓库配置相同的仓库，并向你自己的仓库提交 PR 作为概念验证（PoC），再通过正式安全渠道引用它。

六、漏洞报告的处理流程与时间线

报告提交后，文档承诺了四个阶段及其时限：

1. 分诊（Triage）— 4 个工作日

分诊阶段的安全团队会更新报告的 issue 字段，其中 Asset（受影响模块）需要设置或创建，Severity 字段当前保持 TBD/留空。

2. 修复跟进（Correction follow-up）— 90 天

• 漏洞确认后，由一名安全团队成员自愿认领跟进；
• 该成员会协助报告者联系受影响包的维护者，并可邀请维护者以参与者身份加入该 issue；
• 与包维护者共同确定漏洞的公开日期，理想情况下公开不应早于补丁发布；
• 报告中“受漏洞影响版本”的上限应按规则填写：
  • 若发布时还没有修复版本，设为 *；
  • 否则设为最后一个受影响的版本，例如修复在 1.2.4 中，则写 <=1.2.3。

3. 公开（Publication）— 90 天

自分诊之日起 90 天内，漏洞必须公开。严重级别使用 CVSS v.3 评估。若包维护者正在积极开发补丁，经安全团队与报告者双方批准后，可以追加额外延迟。

4. 二级联系（Secondary Contact）

如果在 6 个工作日内未收到报告的确认，或找不到项目的私有安全联系人，可以联系 OpenJS Foundation CNA（邮件 [e-mail]）寻求帮助。CNA 的作用包括：确保报告得到妥善确认、协助协调披露时间线、在必要时分配 CVE。文档将其定位为“支持机制（support mechanism）”，用于保障 OpenJS 基金会所有项目的安全报告都被恰当处理——它是兜底通道，不是替代正式报告流程的渠道。

关键时间线汇总：

阶段	时限	关键动作
分诊	4 个工作日	首次答复：接受 / 拒绝 / 需要更多信息
修复跟进	90 天	确认漏洞、联系维护者、约定公开日期与版本上限
公开	分诊后 90 天内	对外发布，CVSS v.3 定级；可经批准延期
二级联系	6 个工作日无响应时	联系 OpenJS CNA 兜底

七、Fastify 安全团队与保密义务

文档指出，核心团队（core team）负责安全项目、该策略与流程的管理。团队成员有明确的保密义务：因身处团队而获得的特权信息必须对团队之外完全保密，包括：

• 不得向团队外任何人披露尚未公开的问题——包括问题本身的存在；
• 不得透露即将发布的时间预期；
• 不得在团队工作之外讨论任何问题的修补情况。

文档同时列出了安全团队成员：Matteo Collina、Tomas Della Vedova、Vincent Le Goff、KaKa Ng、James Sumners。

八、OpenSSF CII Best Practices 达标情况

文档末尾披露了项目在 OpenSSF（原 CII）Best Practices 上的三档达标情况，这为评估项目工程与安全治理成熟度提供了可核验的自述依据：

• Passing（通过）：满足 100% 的 passing 标准；
• Silver（银牌）：满足 87%，差距在于：没有 DCO 或 CLA 贡献流程；目前没有文档化项目的“架构（高层设计）”；
• Gold（金牌）：满足 70%，差距包括：尚未拿到 silver 徽章（继承上述差距）；部分源文件缺少版权或许可证声明（文中说明正在推动将这一“陈旧做法”从硬性要求改为建议）；围绕密码学（cryptography）还有若干待澄清的问题。

从 README 中挂载的 CII Best Practices 徽章可以看到，项目对外展示的正是 passing 级别。

九、从框架实现角度看策略的可信度

安全策略的可信度最终取决于框架是否真的实现了它所声称的边界。结合仓库源码可以观察到几处与策略直接呼应的实现：

• “不可信输入”的入口处做了加固：默认的 JSON body 解析没有裸用 JSON.parse，而是采用 secure-json-parse（见 lib/content-type-parser.js 顶部引入），以应对解析阶段的原型链污染与类型强转问题；自定义解析器表用 Map 而非普通对象存储，源码注释直接点明这是为了避免原型劫持攻击。
• “设计上的信息泄露”有对应的默认值：默认错误序列化器由构建脚本生成（lib/error-serializer.js 顶部注释标明 autogenerated），只输出 statusCode、code、error、message 字段——这与策略中“显式通过配置开启错误细节外泄属于设计行为、不算漏洞”的表述一致：框架默认不泄露内部细节，暴露与否取决于开发者配置。
• 校验管线是漏洞判定的参照系：lib/validation.js 中针对 response schema 状态码格式的正则校验（scChecker）以及 headers schema 的编译逻辑，展示了“绕过校验管线的解析缺陷”具体会发生在哪一层——这正是分诊时判断报告是否属于框架漏洞的代码依据。

需要强调的是，以上源码结论均来自当前仓库 main 分支（v6 开发线）的实际文件；若你使用的是 5.x 维护线，相关实现细节可能不同，应以对应分支的源码为准。

十、给安全报告者与框架用户的两点实践建议

如果你是安全研究人员：提交前先对照第四节的非漏洞清单做自我过滤——ReDoS、应用代码缺陷、配置错误、第三方依赖问题都不应占用框架的漏洞通道；确定属于框架问题后，走 GitHub Security Advisories 正式渠道，PoC 放在自己的仓库里，而不是向 Fastify 仓库提 PR。

如果你是 Fastify 使用者：把第三、四节当作一份“责任清单”来读——为正则型 content-type parser 配齐 schema.body.content 条目（参考 Content-Type Parser 文档 与 Validation and Serialization 文档），谨慎使用 onProtoPoisoning 策略切换（参考 test/proto-poisoning.test.js 中三种策略的行为差异），并记住限流、认证、授权始终是你的应用层职责，而不是框架的默认承诺。