security.txt生成器

按 RFC 9116 规范生成 /.well-known/security.txt 安全漏洞披露联系文件,表单填写Contact/Expires等字段,自动校验必填项和日期格式,一键生成符合规范的纯文本内容。

免费在线工具
Loading…

使用说明

填写 Contact(必填,至少一个联系方式,支持 mailto:/https:/tel: 等形式,可点击“+ 添加联系方式”填写多个,按优先级从高到低排列)和 Expires(必填,ISO 8601 格式的过期时间,如 2027-12-31T23:59:59.000Z)。

可选填写:Encryption(PGP公钥链接)、Acknowledgments(致谢页面)、Preferred-Languages(逗号分隔的语言代码,如“zh, en”)、Canonical(本文件的规范地址)、Policy(安全政策页面)、Hiring(安全团队招聘页面)。

点击“生成 security.txt”,工具会先校验Contact是否至少填写一项、Expires是否为合法的ISO 8601格式,校验通过后按RFC 9116规定的字段顺序和格式(如 Contact: mailto:security@example.com)生成纯文本内容。生成的内容需要部署到网站根目录的 /.well-known/security.txt 路径下(纯文本文件,不需要HTML包裹)。

功能介绍

security.txt 是 RFC 9116 定义的一种标准化文件格式,用于告诉安全研究人员如何负责任地向网站报告安全漏洞,替代过去各家网站联系方式五花八门、难以查找的局面。文件应部署在网站的 /.well-known/security.txt(推荐)或网站根目录 /security.txt 路径。

按RFC 9116规范,Contact 字段是必填的,且可以出现多次(声明多个联系渠道,按顺序代表优先级);Expires 字段也是必填的,且只能出现一次,值为ISO 8601格式的日期时间,用于表明这份文件的有效期(RFC建议不要设置得太远,通常不超过一年,过期后应视为文件已失效,提醒维护者及时更新)。其余字段(Encryption/Acknowledgments/Preferred-Languages/Canonical/Policy/Hiring)均为可选。

本工具在生成前会校验这两个必填字段是否存在、Expires是否符合ISO 8601格式,避免生成不合规的文件。所有内容都在浏览器本地拼装,不会上传或存储你填写的任何信息。

使用场景

为网站建立标准化的安全漏洞报告渠道
按RFC 9116规范快速生成security.txt内容,部署后安全研究人员可以按标准方式找到你的漏洞报告联系方式,提升协同披露效率。
安全合规/审计要求的落地
部分安全成熟度评估或合规检查会要求网站具备标准化的漏洞披露渠道,用本工具快速生成满足RFC 9116格式要求的文件。
定期更新已过期的security.txt文件
当现有security.txt的Expires日期临近或已过期时,用本工具重新填写最新的联系方式和有效期,生成更新后的内容重新部署。
学习RFC 9116规范的字段要求
通过表单里每个字段的说明和必填标记,直观了解security.txt支持哪些字段、哪些是必填、格式要求是什么。

常见问题

生成的文件应该放在网站的什么位置?
按RFC 9116推荐,应部署在网站的 /.well-known/security.txt 路径下(如 https://example.com/.well-known/security.txt),这是安全研究人员和自动化工具优先查找的标准位置。部分实现也会同时在网站根目录 /security.txt 放一份作为兼容。
Expires字段的日期需要设置多久之后?
RFC 9116没有强制规定具体时长,但建议不要设置得太远(通常建议不超过一年),过期后应被视为文件失效,提醒维护者定期回来确认/更新文件内容仍然准确,避免因为长期不维护导致联系方式失效却一直显示为“有效”。
为什么Contact要填多个,应该怎么排序?
允许填写多个Contact是为了提供多种联系渠道的备选(比如邮箱和在线报告表单),建议按你希望被联系的优先顺序从上到下排列,安全研究人员通常会优先尝试排在前面的联系方式。
校验不通过怎么办?
本工具生成前会检查Contact是否至少填写了一项非空内容、Expires是否是合法的ISO 8601格式(如2027-12-31T23:59:59.000Z或带时区偏移的写法),如果校验失败会在生成结果上方列出具体错误原因,按提示修正对应字段后重新点击生成即可。