security.txt 驗證工具
貼上 security.txt（RFC 9116）內容即可檢測語法錯誤。檢查 Contact、Expires 等必填欄位是否存在及其取值格式是否正確，確認檔案已正確釋出在 /.well-known/security-text。
小貼士
- security.txt 的正式釋出位置是
/.well-known/security-text。出於相容性考慮，建議同時在網站根目錄的/security.txt也釋出一份。 - Contact 應寫成帶協議字首的 URI，例如 mailto:、https: 或 tel:。僅寫純文本郵箱地址不符合 RFC 9116，自動化解析工具可能無法識別。
- Expires 建議設定為不超過一年後的日期，並在每次續期時延長。過期的檔案可能被視為無人維護的聯絡方式。
- 本工具的所有驗證均在瀏覽器內完成，輸入內容不會發送到任何伺服器，可以放心貼上上線前的檔案進行檢查。
常見問題
RFC 9116 規定的正式位置是
https://example.com/.well-known/security-text。由於許多實現也會檢查舊路徑 https://example.com/security.txt，建議為相容性同時釋出在兩處。檔案不會因此自動失效，但安全研究人員和自動化工具會將其視為陳舊、無人維護的資訊，從而降低可信度。建議至少每年延長一次日期。
不是。security.txt 是一個說明應聯絡誰、如何聯絡的檔案，並不規定是否提供獎金或金額多少。你可以通過 Policy 或 Hiring 欄位連結到懸賞計劃頁面。
可以寫，但 RFC 9116 將 Contact 定義為 URI，因此必須帶有協議字首，例如
mailto:[email protected]。沒有協議字首時，自動化解析工具可能無法正確識別。並非強制要求，但 RFC 9116 將 OpenPGP 簽名列為推薦做法。簽名後，研究人員可以驗證檔案內容是否被第三方篡改。
閒話 ― security.txt 的誕生背景 ― 僅靠漏洞懸賞計劃無法解決的“第一聯絡視窗”問題
security.txt 由安全研究員 Ed Overflow 與 Kagan Baytas 於 2017 年提出。當時，發現漏洞的研究人員常常找不到明確的報告渠道，只能通過通用客服表單或社交媒體私信聯絡企業，報告經常輾轉多時才能送達正確的人，甚至被直接忽視。
該提案被提交至 IETF（網際網路工程任務組），經過多年討論與修訂，最終在 2022 年正式成為 RFC 9116 標準。其機制非常簡單：網站運營者只需在 /.well-known/security-text 釋出一個文本檔案，研究人員即可機械化地瞭解應聯絡誰、使用何種語言以及遵循何種披露政策。
GitHub、Google、Facebook、LinkedIn 等眾多大型科技公司均已採用 security.txt，並常通過 Policy 欄位連結到漏洞披露或漏洞懸賞計劃頁面。它相當於一個“前門”，能夠觸達那些原本可能永遠發現不了漏洞懸賞平臺的研究人員。
作為 RFC 9116 的自然延伸，越來越多組織通過 CSAF 欄位連結到 CSAF（通用安全公告框架）文件，用以標準化漏洞公告的交換方式。security.txt 已不再只是一個聯絡方式檔案，而是持續演變為組織整體安全響應流程的入口。