security.txt 生成与检查
security.txt 是放在 /.well-known/security.txt 的一个小文本文件，告诉安全研究人员发现问题后怎样联系你。它至少要有一行 Contact 和一个 Expires 到期日。填写表单即可得到文件；也可以粘贴你已有的文件，看看缺了什么、是否过期、有没有拼错。所有处理都在你的浏览器里完成。
你的 security.txt
填写联系方式和到期日后，文件会显示在这里。
放在哪里
- •放在 https://你的域名/.well-known/security.txt。/security.txt 只是兼容旧做法；两处都有时，读者以 /.well-known/ 里的为准。
- •必须通过 HTTPS 访问，并以 Content-Type: text/plain; charset=utf-8 返回。
- •它只对所在的这个域名有效，不覆盖子域名。每个需要的主机各放一份。
- •在到期日前记得续期。过期的文件会被视为过时。
可选：给文件签名
RFC 建议用 OpenPGP 明文签名为文件签名，例如 gpg --clearsign security.txt，并加上 Canonical 字段，让签名同时证明文件的网址。本页不会替你签名，只会在检查时识别已签名的文件。
使用方法
- •生成文件：至少填一个联系方式和一个到期日，其他字段可选。页面会边填边生成文本，可以下载或复制，再上传到你网站的 /.well-known/security.txt。
- •检查文件：粘贴文件内容。页面逐行读取各个字段，并对照 RFC 9116；每条结果都会标明行号和对应的 RFC 章节。
- •错误是违反了 RFC 中必须遵守的规定，例如缺少 Contact 或 Expires、日期已过期、使用了 http: 链接。警告是多半没有按你预期起作用的地方，例如字段名拼错。提示只是供参考的信息。
- •规则依据 RFC 9116，核对日期为 2026-11-01。你输入或粘贴的内容不会离开本页。
它能做什么，不能做什么
- •它生成并检查文件的文本。它不会去读取你网站上线上的文件，所以无法判断你的服务器是否通过 HTTPS、并以正确的 Content-Type 返回它。
- •它不会给文件签名，也不会验证签名。已签名的文件可以识别，文本也会被检查，但签名本身不会被验证。
- •它无法判断你的邮箱、电话或链接是否可用，也无法判断加密密钥是否正确。
- •RFC 允许使用它不认识的字段名；这类字段只会作为提示列出，除非看起来像是已知字段的拼写错误。
- •Expires 会设为所选日期当天结束（UTC）。如需其他时间或时区，请在生成后自行修改这一行。
常见问题
- security.txt 有什么用？
- 发现你网站存在安全问题的人，可以在这里找到该告诉谁、怎么告诉。没有它，他们可能只能猜一个邮箱、公开发帖，或者干脆放弃。这是一项标准（RFC 9116），几分钟就能写好。
- 文件应该放在哪里？
- 通过 HTTPS 放在 https://你的域名/.well-known/security.txt，作为 UTF-8 纯文本返回（Content-Type: text/plain; charset=utf-8）。为兼容旧做法也可以在 /security.txt 放一份，但两处都有时以 /.well-known/ 里的为准。文件只对提供它的这个域名有效。
- 哪些字段是必填的？
- 两个：Contact 和 Expires。Contact 可以出现多次，首选方式写在最前面；Expires 必须恰好出现一次。其余都是可选的：Encryption、Acknowledgments、Preferred-Languages、Canonical、Policy 和 Hiring。
- Expires 应该设在多久以后？
- 不到一年。RFC 这样建议，是为了避免联系信息过时。常见做法是设在大约一年后，并在到期前一个月左右续期。本页默认建议“一年后减一天”。
- 一定要给文件签名吗？
- 不需要。RFC 推荐用 OpenPGP 明文签名，同时用 Canonical 字段列出文件所在的网址。很多网站发布的是未签名的文件，同样有效。
- 可以用 http: 链接或者直接写邮箱吗？
- 这些字段里的网页链接必须以 https:// 开头。邮箱要写成 mailto: 链接，电话要写成 tel: 链接，例如 mailto:security@example.com。你在表单里直接输入邮箱或电话时，页面会替你补上前缀。