security.txt 验证工具
粘贴 security.txt（RFC 9116）内容即可检测语法错误。检查 Contact、Expires 等必填字段是否存在及其取值格式是否正确，确认文件已正确发布在 /.well-known/security-text。
小贴士
- security.txt 的正式发布位置是
/.well-known/security-text。出于兼容性考虑，建议同时在网站根目录的/security.txt也发布一份。 - Contact 应写成带协议前缀的 URI，例如 mailto:、https: 或 tel:。仅写纯文本邮箱地址不符合 RFC 9116，自动化解析工具可能无法识别。
- Expires 建议设置为不超过一年后的日期，并在每次续期时延长。过期的文件可能被视为无人维护的联系方式。
- 本工具的所有验证均在浏览器内完成，输入内容不会发送到任何服务器，可以放心粘贴上线前的文件进行检查。
常见问题
RFC 9116 规定的正式位置是
https://example.com/.well-known/security-text。由于许多实现也会检查旧路径 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-text 发布一个文本文件，研究人员即可机械化地了解应联系谁、使用何种语言以及遵循何种披露政策。
GitHub、Google、Facebook、LinkedIn 等众多大型科技公司均已采用 security.txt，并常通过 Policy 字段链接到漏洞披露或漏洞悬赏计划页面。它相当于一个“前门”，能够触达那些原本可能永远发现不了漏洞悬赏平台的研究人员。
作为 RFC 9116 的自然延伸，越来越多组织通过 CSAF 字段链接到 CSAF（通用安全公告框架）文档，用以标准化漏洞公告的交换方式。security.txt 已不再只是一个联系方式文件，而是持续演变为组织整体安全响应流程的入口。