Security.txt 生成器
security.txt 生成器
按 RFC 9116 标准输出，可直接部署到 /.well-known/security.txt。
披露信息配置
声明 security.txt 的规范URL，防止在其他路径伪造该文件
生成结果
在线生成符合 RFC 9116 标准的 security.txt 文件，为安全研究者提供正式的漏洞上报入口。实时预览，一键复制，直接部署到 /.well-known/security.txt 即可生效。
按 RFC 9116 标准输出，可直接部署到 /.well-known/security.txt。
声明 security.txt 的规范URL，防止在其他路径伪造该文件
在线生成符合 RFC 9116 标准的 security.txt 文件，为安全研究者提供正式的漏洞上报入口。实时预览，一键复制，直接部署到 /.well-known/security.txt 即可生效。
security.txt 是 IETF 在 RFC 9116 中定义的一项web安全标准，目的是给网站提供一个标准化的方式来公开安全联系信息。当安全研究者（白帽黑客）在你的网站发现安全漏洞时，他们需要知道该联系谁、怎么加密发送报告、遵循什么披露政策。如果没有 security.txt，研究者可能找不到正确的人，漏洞可能被公开披露甚至被恶意利用。Google、GitHub、Facebook/Meta、英国政府、美国CISA、法国/意大利/荷兰/澳大利亚政府都已经采用了这个标准。
按照 RFC 9116 标准，security.txt 必须放在 /.well-known/security.txt 路径下（也就是网站根目录的 .well-known 文件夹里）。同时也可以在网站根目录放一份 /security.txt 作为fallback兼容。必须通过HTTPS访问，Content-Type必须是text/plain。不能放在其他路径，否则自动化安全扫描工具无法识别。
支持三种格式：邮箱地址必须用 mailto: 前缀（如 mailto:security@example.com）、网页URL必须用 https:// 前缀（如 https://example.com/security-report）、电话号码必须用 tel: 前缀（如 tel:+1-201-555-0123）。可以填写多个联系方式，每个一行，安全研究者可以选择最方便的渠道联系你。建议至少提供一个邮箱和一个网页表单链接。
Expires 是必填字段（Contact也是必填的，其他都是可选）。Expires表示security.txt内容的过期时间，必须使用ISO 8601格式的UTC时间，例如 2027-12-31T23:59:59Z（Z表示UTC时区）。建议设置为创建后6-12个月过期，提醒自己定期更新安全联系信息。过期后自动化工具会认为该文件信息可能已失效。
Encryption字段用来指向你的PGP公钥位置，安全研究者可以用这个公钥加密漏洞报告后再发送，避免漏洞细节在邮件传输过程中被截获泄露。这不是必填字段，但强烈建议配置——因为漏洞信息非常敏感，明文邮件可能被ISP、邮件服务器管理员或攻击者窃听。你可以把PGP公钥放在 /.well-known/pgp-key.txt，然后把这个URL填到Encryption字段。
Acknowledgments字段指向一个公开致谢页面（也叫安全名人堂/Hall of Fame），列出曾经向你报告过安全漏洞的研究者名字或ID。这是一种对安全研究者工作的公开认可，也是吸引更多白帽研究者来帮你找漏洞的有效方式。很多安全研究者会优先选择有公开致谢机制的网站进行测试，因为这意味着他们的贡献会被认可。
Policy字段应该链接到你的漏洞披露政策（Vulnerability Disclosure Policy, VDP）页面。这个页面应该清楚说明：哪些测试行为是允许的（哪些是禁止的，比如不允许DDoS、不允许访问用户数据）、漏洞上报的响应时间承诺、你是否会提供赏金、你对合法安全研究的法律承诺（如不起诉善意研究者）等。一个清晰的Policy能给安全研究者法律上的安全感，让他们放心给你报告问题。
Canonical字段用来声明security.txt文件本身的规范URL。一个网站可能在多个域名或路径下都能访问到security.txt（比如example.com和www.example.com），Canonical字段告诉研究者哪个URL是官方的、可信的版本。这可以防止攻击者在某个路径下放一个伪造的security.txt，诱骗研究者把漏洞报告发给攻击者。建议填写你的正式域名URL，如 https://example.com/.well-known/security.txt。
Preferred-Languages 告诉安全研究者你的安全团队能处理哪些语言的报告，用逗号分隔的语言代码表示（如 en, zh-CN, ja）。本生成器会根据你当前使用的页面语言自动设置这个字段。这很重要，因为安全研究是全球性的，研究者可能在任何国家，提前说明你支持的语言可以避免语言不通导致沟通失败。
是的，Hiring 是 RFC 9116 标准定义的可选字段之一。这个字段指向你的安全团队招聘页面。安全研究者本身就是优秀的安全人才候选人——他们能发现你网站的漏洞说明他们有很强的安全能力，在security.txt里放招聘链接是非常精准的安全人才招募方式。很多知名公司（包括Google）都在security.txt里放了招聘链接。
这是网站方最常见的担忧。有几种方案可以减少垃圾邮件：第一，不要直接放邮箱地址，而是放一个安全报告网页表单的URL（https://前缀），这样可以加验证码过滤机器人；第二，使用专门的安全邮箱别名（如security@），并配置好垃圾邮件过滤；第三，提供PGP公钥加密方式，自动化垃圾邮件发送者不会用PGP加密；第四，明确在Policy中说明你只接受安全漏洞相关报告。实际上大多数实施了security.txt的网站反馈垃圾邮件增加并不明显，但漏洞报告却显著增加了。
RFC 9116 推荐（但不强制）使用OpenPGP明文签名（cleartext signature）对security.txt进行数字签名，这样研究者可以验证文件确实是网站官方发布的，没有被攻击者篡改。方法是用GPG工具对文件进行 clearsign：gpg --clearsign -o security.txt.sig security.txt，然后把签名后的内容（以-----BEGIN PGP SIGNED MESSAGE-----开头）作为最终的security.txt内容。不过这是进阶操作，大多数网站不做签名也能正常使用。
核心配置要求：确保 /.well-known/security.txt 路径可以访问，Content-Type 返回 text/plain，必须使用HTTPS，不要对这个路径做重定向（特别是不要重定向到其他域名）。Nginx可以用location精确匹配：location = /.well-known/security.txt { default_type text/plain; alias /path/to/security.txt; }；Apache确保.htaccess没有阻止.well-known目录访问；Caddy用handle_path直接指定即可。
非常推荐放。不管网站大小，只要有用户数据或在互联网上提供服务，就有可能存在安全漏洞。security.txt 的部署成本极低——用本工具生成只需要2分钟，放一个文件就行。Google、GitHub等大公司用它，个人开发者和开源项目同样能用。这是一个性价比极高的安全实践：几乎零成本，却能让发现漏洞的善意研究者有渠道告诉你问题，而不是默默离开或公开披露。
两者都是放在/.well-known/（或根目录）下的标准文本文件，但用途完全不同：robots.txt是给搜索引擎爬虫看的，告诉它们哪些路径不要抓取；security.txt是给安全研究者看的，告诉他们发现漏洞后怎么联系你。一个面向搜索引擎，一个面向安全研究者，两者互补不冲突，可以同时部署。
security.txt 是由 IETF（互联网工程任务组）在 RFC 9116 中正式标准化的一项web安全最佳实践，旨在为网站提供一个统一、标准的方式来公开安全联系信息。简单来说，它就是一个放在网站固定路径下的文本文件，告诉安全研究者（白帽黑客）："如果你在我的网站发现了安全漏洞，这里是联系我们的方式，这是我们的加密公钥，这是我们的披露政策，我们欢迎你的报告。"
在 security.txt 标准出现之前，网站的安全联系信息是杂乱无章的。有的网站根本没有任何安全联系方式，有的藏在某个角落的页面里，有的只留了一个没人看的info@邮箱，有的需要在LinkedIn上费尽周折才能找到安全团队。这导致一个严重问题：当善意的安全研究者发现了漏洞，他们往往找不到正确的渠道报告。结果就是——很多漏洞就这样被默默搁置，无人修复，直到被恶意黑客发现并利用。security.txt 就是为了解决这个"最后一公里"问题而诞生的。
security.txt 的概念最早由安全研究者 EdOverflow 和 Yakov Shafranovich 在2017年提出，迅速获得了行业广泛支持。2022年4月，security.txt 正式被 IETF 批准为 RFC 9116 标准，成为国际公认的web安全标准。如今，Google、GitHub、Meta（Facebook）、LinkedIn、Cloudflare 等大型科技公司，以及英国政府、美国CISA（网络安全和基础设施安全局）、法国政府、意大利政府、荷兰政府、澳大利亚网络安全中心等政府机构都已经在官方网站部署了 security.txt，并公开推荐其他组织采用。
security.txt 文件的核心设计非常简洁——就是一个纯文本文件，由一系列"字段名: 值"的行组成，类似HTTP头的格式。标准定义了两个必填字段：Contact（安全联系方式，可以有多个）和Expires（文件过期时间）；以及多个可选字段：Encryption（PGP加密公钥URL）、Acknowledgments（致谢页面URL）、Policy（漏洞披露政策URL）、Hiring（安全招聘URL）、Canonical（文件规范URL）、Preferred-Languages（支持的报告语言）、CSAF（安全公告框架元数据URL）。这种简单格式让人和机器都能轻松解析。
为什么部署 security.txt 如此重要？首先，它降低了漏洞报告的门槛。安全研究者不需要花费大量时间寻找联系方式，一键就能找到正确的报告渠道。其次，它展示了组织对安全的积极态度——有security.txt的网站相当于在说"我们重视安全，我们欢迎负责任的报告"。第三，它减少了漏洞被公开披露或利用的风险：研究者有了正规渠道，就不会因为联系不上而选择在Twitter或GitHub上直接公开漏洞。第四，在很多行业监管要求中（如金融、医疗、政府），建立漏洞披露渠道已经成为合规要求。
部署 security.txt 需要注意几个关键细节。第一，路径必须正确：标准路径是 /.well-known/security.txt，也可以在根目录 /security.txt 放一份作为fallback。这里的.well-known目录是RFC 8615定义的标准"已知资源"目录，robots.txt等其他标准文件也放在相关位置。第二，必须通过HTTPS提供，明文HTTP会被认为不安全。第三，Content-Type必须是text/plain，不能是text/html或其他类型。第四，不要对security.txt做跨域名重定向——如果 https://example.com/.well-known/security.txt 重定向到 https://other-domain.com/security.txt，研究者和自动化工具会认为这是可疑的。第五，记得设置Expires字段并定期更新，过期的security.txt会被认为信息不可靠。
Contact字段是security.txt中最重要的字段，也是唯一一个真正必不可少的字段（Expires同样必填，但只是时间戳）。Contact支持三种URI格式：mailto:用于邮箱地址，https://用于网页链接（如安全报告表单页面），tel:用于电话号码。强烈建议至少提供一个mailto邮箱和一个https表单链接——表单可以防止机器人垃圾邮件，邮箱则更方便研究者直接发送加密报告。多个联系人可以多行列出，比如同时提供安全团队邮箱、安全负责人邮箱、第三方漏洞平台链接等。
Encryption字段虽然是可选的，但在实际操作中非常重要。当安全研究者发现一个严重漏洞时（比如用户数据泄露、远程代码执行），他们绝对不希望用明文邮件发送漏洞细节——因为邮件在传输过程中会经过多个服务器，任何一环都可能被窃听。PGP（Pretty Good Privacy）公钥加密是业界标准的安全通信方式。你只需要生成一对PGP密钥对，把公钥放在网站上（比如 /.well-known/pgp-key.txt），然后把这个URL填在Encryption字段即可。研究者用你的公钥加密报告内容，只有持有对应私钥的人才能解密阅读。
Policy字段链接到你的漏洞披露政策（Vulnerability Disclosure Policy, VDP）页面，这是建立研究者信任的关键。一个好的VDP应该清楚说明：测试范围（哪些系统属于测试范围、哪些不在范围内）、允许的测试方法（如允许SQL注入/XSS测试但禁止DDoS/社工/访问真实用户数据）、承诺的响应时间（如"我们会在3个工作日内确认收到报告"）、是否提供漏洞赏金、法律安全港承诺（明确不会起诉遵循规则的善意研究者）等。国际上有很多VDP模板可以参考，美国CISA也提供了开源的VDP模板。
除了安全联系本身，security.txt 还有几个"惊喜"字段。Acknowledgments字段建立的是安全名人堂（Hall of Fame）——公开感谢那些帮助你发现漏洞的研究者，这是对他们工作的认可，也是一种社区建设。Hiring字段则是一个非常聪明的设计：能发现你网站漏洞的人本身就是优秀的安全人才，在security.txt里放招聘链接是最精准的安全人才招聘渠道。很多公司通过security.txt招聘到了优秀的安全工程师。Canonical字段则是安全考虑——防止攻击者在其他域名下伪造你的security.txt。
关于常见的垃圾邮件担忧，实际上大多数已经部署security.txt的组织反馈垃圾邮件增加并不明显。这是因为：第一，垃圾邮件发送者通常不靠爬取security.txt获取邮箱；第二，可以用https://表单链接代替直接放mailto邮箱，在表单上加验证码完全可以拦截机器人；第三，专门的安全邮箱（如security@）通常会配置严格的垃圾邮件过滤。相比之下，因为缺少安全联系渠道而错过的严重漏洞报告，其代价远远大于可能增加的少量垃圾邮件。
本生成器严格遵循 RFC 9116 标准构建，所有输出格式都经过规范化处理：Contact字段自动识别前缀，Expires字段使用标准ISO 8601 UTC时间格式，Preferred-Languages自动根据你使用的语言设置。生成的内容可以直接复制部署到 /.well-known/security.txt 路径，不需要任何修改。同时，所有配置都在你的浏览器本地完成，不会发送到任何服务器——你的安全联系信息始终保存在你的设备上。部署security.txt只需要5分钟，但它建立的安全沟通渠道可能在未来帮你避免一次严重的安全事件。
以下是security.txt标准定义的所有字段及其要求：
| 字段名 | 必填/可选 | 允许多个？ | 值格式 | 说明 |
|---|---|---|---|---|
| Contact | ✅ 必填 | ✅ 允许多行 | mailto:/https:/tel: URI | 安全联系方式，支持邮箱、网页URL、电话三种格式 |
| Expires | ✅ 必填 | ❌ 仅一个 | ISO 8601 UTC时间 | 文件内容过期时间，过期后信息被认为可能失效 |
| Encryption | ⬜ 可选 | ✅ 允许多行 | https:// URI | PGP公钥位置URL，用于加密发送敏感漏洞报告 |
| Acknowledgments | ⬜ 可选 | ✅ 允许多行 | https:// URI | 安全名人堂/致谢页面URL，公开感谢漏洞上报者 |
| Policy | ⬜ 可选 | ✅ 允许多行 | https:// URI | 漏洞披露政策（VDP）页面URL，说明上报规则和范围 |
| Hiring | ⬜ 可选 | ✅ 允许多行 | https:// URI | 安全团队招聘页面URL，向安全研究者招募人才 |
| Canonical | ⬜ 可选 | ✅ 允许多行 | https:// URI | security.txt文件本身的规范URL，防止伪造 |
| Preferred-Languages | ⬜ 可选 | ❌ 仅一个 | 语言代码(逗号分隔) | 安全团队支持的语言，如en, zh-CN, ja |
| CSAF | ⬜ 可选 | ✅ 允许多行 | https:// URI | Common Security Advisory Framework提供商元数据URL |
生成security.txt内容后，在服务器上配置正确的访问路径和Content-Type：
| Web服务器 | 配置要点 | 注意事项 |
|---|---|---|
| Nginx | location = /.well-known/security.txt { default_type text/plain; alias /var/www/.well-known/security.txt; add_header Cache-Control "public, max-age=3600"; } | 使用精确匹配（=），指定default_type为text/plain，避免Nginx把txt文件当二进制处理 |
| Apache | 确保.well-known目录不被.htaccess的Deny规则拦截，文件放置在网站根目录的.well-known文件夹下即可 | Apache默认对.txt文件返回text/plain，但需要确认mod_rewrite规则不会重写这个路径 |
| Caddy | handle_path /.well-known/security.txt { file_server { root /var/www } } | Caddy默认HTTPS且正确处理txt文件MIME类型，配置最简单 |
| Cloudflare Pages/Vercel/Netlify | 将security.txt放在public/.well-known/security.txt路径下，部署后静态服务即可正确访问 | 静态托管平台通常自动处理正确的Content-Type，确认.well-known目录以下划线开头时平台不会忽略 |
| CDN/反向代理 | 确保CDN或WAF不会拦截或缓存security.txt过久，建议Cache-Control设为max-age=3600（1小时） | 更新security.txt后记得刷新CDN缓存，否则研究者看到的可能是旧版本 |
本生成器所有配置操作完全在你的浏览器本地完成，你填写的安全联系邮箱、PGP密钥URL、招聘链接等所有信息都不会发送到任何服务器，也不会被收集或存储。页面刷新或关闭后，所有输入内容立即清除。生成的security.txt文件内容只存在于你的剪贴板和你部署的服务器上，GeekFormat不保留任何副本。
常见原因有三个：一是文件没有放在正确位置——确认路径是网站根目录下的.well-known文件夹内的security.txt文件（注意.well-known是点开头的隐藏目录）；二是Web服务器配置阻止了以.开头的目录访问（Apache的.htaccess或Nginx的deny规则可能拦截dotfile目录）；三是Nginx/Apache的重写规则（如前端路由history模式）把请求转发给了index.html。解决方法：检查文件路径、在服务器配置中显式添加/.well-known/security.txt的location规则。
很多单页应用（SPA）或带身份认证的网站会把所有未匹配路径重定向到首页或登录页。这会导致自动化工具无法找到security.txt。解决方法：在服务器配置中为/.well-known/security.txt路径添加例外，让这个路径直接返回文件内容，不经过SPA路由或认证中间件处理。这是部署security.txt最常见的坑。
这是因为服务器返回的Content-Type不正确，可能被设置为application/octet-stream或其他二进制类型，而不是text/plain。解决方法：在Web服务器配置中显式为security.txt设置Content-Type为text/plain; charset=utf-8。Nginx需要用default_type text/plain或add_header Content-Type text/plain；Apache通常自动处理，但如果有问题可用AddType指令强制指定。
Contact字段的值必须带URI前缀：邮箱地址必须用mailto:开头（如mailto:security@example.com，不能直接写security@example.com），网页URL必须用https://开头（不能只写example.com/security），电话号码必须用tel:开头。这是RFC 9116标准明确要求的——因为Contact字段支持多种联系方式，无前缀会导致解析器无法判断类型。
Expires必须使用ISO 8601格式的UTC时间，格式为YYYY-MM-DDTHH:MM:SSZ，末尾必须有Z表示UTC时区（不能写+08:00等本地时区偏移）。正确示例：2027-12-31T23:59:59Z。不要用其他格式如2027/12/31、Dec 31 2027或2027-12-31 23:59:59——这些都是不符合标准的。
检查以下几点：第一，确保使用HTTPS访问（HTTP访问不算数，RFC要求必须HTTPS）；第二，确保域名带www和不带www时都能正确访问（如果你的网站同时存在两个域名版本，建议在Canonical字段声明主域名，且在两个域名下都放security.txt或设置正确的301重定向）；第三，检查CDN缓存是否清除了旧内容；第四，确认服务器没有在security.txt路径上返回重定向（301/302）到其他URL——RFC规定重定向可能被工具拒绝。