security.txt 解析（RFC 9116）

功能

• ⚠️ 第一行就是结论：有效 / 已过期 / 缺 Expires / Expires 格式读不出来，四种情况各有颜色
• 缺 `Expires` 或时刻格式不对时说明为什么这份文件等于没发，而不是只报一句格式错误
• `Expires` 严格要求带时区（`Z` 或 `±HH:MM`）—— 不带时区的时刻是没有定义的，不同时区的人会得出不同的过期时间
• Contact / Policy / Canonical 等字段的值不像 URL 时逐条指出来（并且给出是第几行）
• 字段名不区分大小写；`#` 注释单独列出；同一字段出现多次会全部保留（Contact 本来就允许多条）
• 认不出的字段单独列出 —— 按规范它们必须被忽略，也就是说字段名写错不会报错、只会被静默丢掉
• 认 PGP 明文签名（clearsign）的写法：自动从签名块里取出正文，并还原 `- ` 转义
• 输出是左右对齐的两列报告，可以直接整段复制
• 全部在浏览器本地完成，粘进来的内容不外传

使用方法

1. 拿到文件：浏览器打开 `https://<域名>/.well-known/security.txt`（老站点可能只在根目录放 `security.txt`）
2. 把内容整段复制，粘贴进输入框
3. 先看第一行的结论，再看下面的字段清单
4. 有问题的行会指出具体是第几行，回去改那一行即可

常见问题

这个工具能帮我抓取别人的 security.txt 吗？

不能，本站是纯静态站点、没有后端，所有工具都只在你的浏览器里跑 —— 这也是「数据不离开浏览器」这条原则的代价之一。要拿那份文件，直接让浏览器打开 `https://域名/.well-known/security.txt` 就行（那是纯文本，会直接显示出来），或者用 `curl https://域名/.well-known/security.txt`。有些站点两个位置都放，规范推荐的是 `/.well-known/` 那个。

Expires 过期了会怎样？

按 RFC 9116 的规定，过期的文件应当被当成不存在。这正是它要求写 Expires 的原因：联系方式会变、域名会易主、团队会解散，一份 2019 年写的文件如果永远有效，研究者可能把漏洞报给一个早已不相关的邮箱 —— 那比没有这个文件更糟。所以很多扫描器会直接跳过过期文件，也就是说你以为在对外发布的联系方式其实早就失效了。建议把有效期设成一两年，并在到期前更新。

Contact 里写邮箱还是网址？

都要带协议：`mailto:security@example.com` 或 `https://example.com/report`。只写 `security@example.com` 虽然人能看懂，但按规范那不是一个 URI，而解析器是照着 URI 解析的 —— 很多实现会直接丢掉这一条。可以写多条 Contact（规范允许），常见的顺序是「首选的在前」，比如先放一个表单地址、再放邮箱。另外如果接受加密报告，用 `Encryption:` 给出公钥的地址（不要直接把公钥贴进来，那个字段也要求是 URI）。

为什么字段名写错了它不报错？

因为规范就是这么定的：认不出的字段必须被忽略。这条规定是为了向前兼容 —— 将来 RFC 加了新字段，老解析器不该因为不认识它就拒绝整份文件。代价是字段名打错（比如把 `Acknowledgment` 少写一个 s、把 `Preferred-Language` 少了 s）不会有任何提示，那一条就被静默丢掉了。所以这里把认不出的字段名单独列出来：不判它为错，但让你看见它。

上面那条「PGP 明文签名」是什么意思？

规范建议（不是要求）用 PGP 明文签名把整份文件签一下，格式是 `-----BEGIN PGP SIGNED MESSAGE-----` 包着正文、后面跟签名块。好处是别人能确认这份文件确实是你发的、中途没被改过。这个工具会把正文从签名块里取出来解析，并还原明文签名规范的 `- ` 转义，但不验证签名本身 —— 验签需要一份公钥，而公钥要联网去拿。要验的话用 `gpg --verify`。