self-hosting必备：你的公开服务提供security.txt吗？

什么是 security.txt

在 Reddit 的 self-hosting 社区，一个看似小众却值得每个公开服务托管者思考的话题被抛出：对于那些对外公开可访问的服务，你是否提供了 security.txt 文件？

security.txt 是一个提议中的互联网标准（RFC 9116），旨在为网站和在线服务提供一个统一的渠道，让安全研究人员能够快速找到该组织的安全联系方式。它的核心理念很简单：当一位善意的白帽子发现你的服务存在漏洞时，他应该有一个明确、标准化的地方去查看该如何负责任地披露这一问题。

它是如何工作的

security.txt 本质上是一个纯文本文件，按照约定应放置在网站的 /.well-known/security.txt 路径下（早期也允许放在根目录）。当安全研究人员想联系你时，他们会优先检查这个位置。

文件采用简单的键值对格式，常见字段包括：

• Contact：必填项，可以是邮箱、电话或联系页面 URL，用于漏洞上报
• Expires：文件的有效期，提醒维护者定期更新
• Encryption：提供加密公钥链接，便于安全传输敏感信息
• Acknowledgments：致谢页面，列出曾报告漏洞的研究者
• Policy：安全政策或漏洞披露政策的链接
• Preferred-Languages：偏好的沟通语言

一个最简示例可能只有一行 Contact: mailto:security@example.com 加上一个 Expires 字段，配置成本极低。

security.txt 文件通常还建议使用 OpenPGP 对整个文件进行数字签名，以防止攻击者篡改文件内容、将安全联系方式替换为恶意地址。签名后的文件会在末尾附带 PGP 签名块，研究者可以用维护者公开的公钥来验证文件的真实性。/.well-known/ 这一路径约定来自 RFC 8615，是互联网标准中用于存放「众所周知的元数据」的专属目录，除 security.txt 外，ACME 证书验证、Apple App Site Association 等文件也遵循同样的约定放置于此，因此大多数安全工具在扫描时会优先检索该路径。

为什么 self-hosting 用户也该关心

很多人认为 security.txt 是大型企业才需要的东西，但对于个人 self-hosting 玩家而言，它同样有价值。当你把 Nextcloud、Jellyfin、个人博客或各类面板暴露在公网时，你已经成为了潜在的攻击目标，同时也可能被善意研究者扫描到。

没有明确的联系渠道，意味着当有人发现你的服务配置存在风险时，往往无从告知，或者干脆放弃告知。提供 security.txt 相当于留下一扇「负责任披露」的门，把可能的恶意利用转化为友好提醒的机会。

从维护成本看，添加这样一个静态文件几乎是零负担——它不需要额外的服务、不消耗计算资源，只是 Web 服务器多返回一个文本响应。

「负责任披露」（Responsible Disclosure）是安全社区中约定俗成的行为规范，也称为「协调披露」（Coordinated Disclosure）。其核心逻辑是：研究者在发现漏洞后，优先私下通知受影响方并给予一定修复窗口期（通常为 90 天），之后才选择公开发布。这一模式对漏洞挖掘方和服务运营方都有利——研究者获得认可或奖励，运营方则有机会在漏洞被恶意利用前完成修补。反之，如果运营方毫无回应渠道，研究者要么放弃告知，要么直接公开披露（Full Disclosure），后者对服务安全而言风险更大。security.txt 存在的核心价值，正是填补了这一沟通缺口。

现实中的采纳情况

讨论中提到的一个现实是：security.txt 虽然已成为 RFC 标准，但在个人托管圈子里的采纳率并不高。大多数 self-hosting 用户更关注功能可用性与访问安全（如反向代理、HTTPS、双因素认证），而对「被外界联系」这一被动场景考虑较少。

这其实反映了一种普遍心态：个人服务规模小、影响面窄，似乎不值得为安全披露渠道费心。但正是这种「无所谓」的态度，让许多小型服务在遭遇问题时缺乏及时响应机制。

实践建议

如果你决定为自己的公开服务添加 security.txt，可以参考以下要点：

1. 放对位置：优先使用 /.well-known/security.txt，确保通过 HTTPS 可访问
2. 至少填写 Contact 和 Expires：这是标准要求的最低配置
3. 设置合理的过期时间：建议不超过一年，并养成到期更新的习惯
4. 考虑隐私：如果不想暴露个人邮箱，可使用专门的安全联系别名
5. 搭配安全政策：即便是简短的一句话说明你欢迎负责任披露，也能提升沟通效率

对于使用 Caddy、Nginx 等服务器的用户，通常只需几行配置就能将该文件对外提供。

小结

security.txt 是一个低成本、高价值的实践。它不会让你的服务更安全，但会让「发现问题」到「解决问题」的链路更顺畅。对于任何托管公开服务的人——无论是企业还是个人 self-hosting 玩家——花几分钟部署这个文件，都是值得的举手之劳。