← 返回工具箱

安全 / 漏洞披露

security.txt 生成与校验

按 RFC 9116 生成标准安全联系人文件，区分会让文件无效的错误和需要维护的提醒，并直接下载带 CRLF 换行的 UTF-8 文本。

标准地址是 https://你的域名/.well-known/security.txt。必须通过 HTTPS 提供，并返回Content-Type: text/plain; charset=utf-8；只把文件放在根目录不能替代这个位置。

PUBLISH CHECKLIST

部署后再检查三件事

标准路径可直接访问浏览器无登录状态也能打开 /.well-known/security.txt，最终响应为 200，不重定向到 HTML 错误页。

响应头与正文一致返回 text/plain; charset=utf-8，不要让框架用 text/html 包装文件，也不要被 CDN 改成过长缓存。

联系人真的有人处理定期测试邮箱、表单和公钥，并在 Expires 前更新文件。格式正确但无人接收的联系方式没有实际价值。

Content-Type: text/plain; charset=utf-8
Cache-Control: public, max-age=3600

标准依据：RFC 9116。

RELATED TOOLS

接着处理

查看全部工具 →
HTTP Header 解析器检查线上 Content-Type、缓存与安全响应头。SSL 证书检查核对 HTTPS 证书、域名和有效期。邮件认证检查检查安全联系邮箱域名的 SPF、DKIM 与 DMARC。Hash 计算器计算公开公钥或下载文件的校验摘要。

USE & REVIEW

security.txt 生成与 RFC 9116 校验常见问题

查看全部工具指南 →

security.txt 中哪些字段是必填的？

RFC 9116 要求至少一个 Contact，并且必须有且只有一个 Expires。Contact 可以重复提供邮箱、HTTPS 报告页或电话；Canonical、Policy、Encryption、Acknowledgments、Preferred-Languages 和 Hiring 都是可选字段。可选不等于没有价值，漏洞政策页和加密公钥通常能减少来回确认。

security.txt 应该放在根目录还是 .well-known 目录？

标准位置是 https://你的域名/.well-known/security.txt，并且必须通过 HTTPS 提供。只放在 /security.txt 不能替代标准入口；如需兼容旧扫描器可以额外保留根目录副本，但应让 Canonical 指向标准地址，避免维护两份不同内容。

Expires 应该设置多远？

它必须是未来的 RFC 3339 日期时间，例如 2027-01-15T00:00:00Z。RFC 9116 建议距离当前时间少于一年，让组织定期确认联系人仍有效。不要在每次请求时动态改成“当前时间加一年”，应设固定日期和更新提醒，这样缓存与审计记录才稳定。

可以在 Contact 中直接写 security@example.com 吗？

应该写成完整 URI，例如 mailto:security@example.com。也可以提供 HTTPS 报告表单或 tel: 电话。工具会把缺少方案的裸邮箱标为错误，因为自动扫描器需要知道该怎样处理这个值；正式发布前还应实际发送一次测试邮件。

为什么文件能打开，扫描器仍说没有 security.txt？

检查最终 URL 是否返回 200、有没有跳到登录页或 HTML 错误页、Content-Type 是否为 text/plain; charset=utf-8，以及 Expires 是否已经过期。CDN 重定向、WAF 阻止扫描器、Canonical 指向错误域名和部署后仍命中旧缓存也很常见。

security.txt 可以写内部人员姓名或私人邮箱吗？

文件是公开的，不要放不准备长期公开的个人资料、内部工单地址或需要保密的密钥。更稳妥的做法是使用角色邮箱、公开报告页和专门维护的公钥，并在政策页说明测试范围、响应时间和安全港规则。