security.txt 验证工具

粘贴 security.txt(RFC 9116)内容即可检测语法错误。检查 Contact、Expires 等必填字段是否存在及其取值格式是否正确,确认文件已正确发布在 /.well-known/security.txt。

验证 security.txt 的格式

security.txt 是站点用来告知发现漏洞的人该往何处联系的文本文件,其格式由 RFC 9116 所定。把内容贴进来,本工具便会检验语法,确认 `Contact`、`Expires` 之类必填字段是否齐备,取值的形式是否得当。

**此处最易被漏看的,是 `Expires` 的处置。** 它不仅是必填字段,**而且一旦过了所写的时刻,该文件便被视作不再有效。** 发布之后便撒手不管,几年后它虽在却已失灵,故须连同更新的打算一并经营。**它的位置也是定死的,应置于 `/.well-known/security.txt`。** 若为文件署名,便以 `Canonical` 字段言明权威的网址,好让读者确信文件不曾被篡改。

使用方法

  1. 贴入 security.txt 的内容 把整份文件照原样放进去。
  2. 先试一试样例 正常的例子与含有错误的例子都已备好。
  3. 阅读所提出的各点 **缺失的必填字段与格式有误的取值,都会被报出。**
  4. 核对 `Expires` 所写的时刻 **确认它并未落在过去,并预先定下何时更新。**

用好本工具的小技巧

  • security.txt 的正式发布位置是 /.well-known/security.txt。出于兼容性考虑,建议同时在网站根目录的 /security.txt 也发布一份。
  • Contact 应写成带协议前缀的 URI,例如 mailto:、https: 或 tel:。仅写纯文本邮箱地址不符合 RFC 9116,自动化解析工具可能无法识别。
  • Expires 建议设置为不超过一年后的日期,并在每次续期时延长。过期的文件可能被视为无人维护的联系方式。
  • 本工具的所有验证均在浏览器内完成,输入内容不会发送到任何服务器,可以放心粘贴上线前的文件进行检查。

这些场景会用到

明示安全联络的窗口

发现者不必四处寻觅地址,报告便更容易送达。

检视已发布的内容

**格式有误的文件在外观上毫无异样,非经验证便无从察觉。**

防范失效

可定期查看 `Expires` 是否已然过期。

统一组织内的标准

同时运营数个站点时,可确认它们是否都遵循同一格式。

security.txt 的术语

Contact
**必填字段**,给出联络的途径:电子邮件地址、电话号码,或报告表单的网址。
Expires
**必填字段**,过了所写的时刻,该文件便被视作不再有效。
Encryption
指向一把公钥,报告可借它加密。
Policy
一个页面的网址,其上载明漏洞披露的方针。
Canonical
本文件本应安放的权威网址。**署名正是照着它来核验的。**
Preferred-Languages
言明可以接收报告的语言,以逗号罗列,如 `en, ja`。

常见问题

RFC 9116 规定的正式位置是 https://example.com/.well-known/security.txt。由于许多实现也会检查旧路径 https://example.com/security.txt,建议为兼容性同时发布在两处。

文件不会因此自动失效,但安全研究人员和自动化工具会将其视为陈旧、无人维护的信息,从而降低可信度。建议至少每年延长一次日期。

不是。security.txt 是一个说明应联系谁、如何联系的文件,并不规定是否提供奖金或金额多少。你可以通过 Policy 或 Hiring 字段链接到悬赏计划页面。

可以写,但 RFC 9116 将 Contact 定义为 URI,因此必须带有协议前缀,例如 mailto:[email protected]。没有协议前缀时,自动化解析工具可能无法正确识别。

并非强制要求,但 RFC 9116 将 OpenPGP 签名列为推荐做法。签名后,研究人员可以验证文件内容是否被第三方篡改。
工具君

闲话 ― security.txt 的诞生背景 ― 仅靠漏洞悬赏计划无法解决的“第一联系窗口”问题

security.txt 由安全研究员 Ed Overflow 与 Kagan Baytas 于 2017 年提出。当时,发现漏洞的研究人员常常找不到明确的报告渠道,只能通过通用客服表单或社交媒体私信联系企业,报告经常辗转多时才能送达正确的人,甚至被直接忽视。

该提案被提交至 IETF(互联网工程任务组),经过多年讨论与修订,最终在 2022 年正式成为 RFC 9116 标准。其机制非常简单:网站运营者只需在 /.well-known/security.txt 发布一个文本文件,研究人员即可机械化地了解应联系谁、使用何种语言以及遵循何种披露政策。

GitHub、Google、Facebook、LinkedIn 等众多大型科技公司均已采用 security.txt,并常通过 Policy 字段链接到漏洞披露或漏洞悬赏计划页面。它相当于一个“前门”,能够触达那些原本可能永远发现不了漏洞悬赏平台的研究人员。

作为 RFC 9116 的自然延伸,越来越多组织通过 CSAF 字段链接到 CSAF(通用安全公告框架)文档,用以标准化漏洞公告的交换方式。security.txt 已不再只是一个联系方式文件,而是持续演变为组织整体安全响应流程的入口。