security.txt 驗證工具
貼上 security.txt（RFC 9116）內容即可檢測語法錯誤。檢查 Contact、Expires 等必填欄位是否存在及其取值格式是否正確，確認檔案已正確釋出在 /.well-known/security.txt。
驗證 security.txt 的格式
security.txt 是網站用來告知發現漏洞的人該往何處聯絡的文字檔，其格式由 RFC 9116 所定。把內容貼進來，本工具便會檢驗語法，確認 Contact、Expires 之類必填欄位是否齊備，取值的形式是否得當。
此處最易被漏看的，是 Expires 的處置。 它不僅是必填欄位，而且一旦過了所寫的時刻，該檔案便應被視為過時（stale），其內容不宜再用。 釋出之後便撒手不管，幾年後它雖在卻已失靈，故須連同更新的打算一併經營。它的位置也是定死的，應置於 /.well-known/security.txt。 若為檔案署名，便以 Canonical 欄位言明權威的網址，好讓讀者確信檔案不曾被竄改。
使用方法
- 貼入 security.txt 的內容 把整份檔案照原樣放進去。
- 先試一試範例 正常的例子與含有錯誤的例子都已備好。
- 閱讀所提出的各點 缺失的必填欄位與格式有誤的取值，都會被報出。
-
核對
Expires所寫的時刻 確認它並未落在過去，並預先定下何時更新。
用好本工具的小技巧
- security.txt 的正式釋出位置是
/.well-known/security.txt。出於相容性考慮，建議同時在網站根目錄的/security.txt也釋出一份。 - Contact 應寫成帶協議字首的 URI，例如 mailto:、https: 或 tel:。僅寫純文本郵箱地址不符合 RFC 9116，自動化解析工具可能無法識別。
- Expires 建議設定為不超過一年後的日期，並在每次續期時延長。過期的檔案可能被視為無人維護的聯絡方式。
- 本工具的所有驗證均在瀏覽器內完成，輸入內容不會發送到任何伺服器，可以放心貼上上線前的檔案進行檢查。
這些情境會用到
明示安全聯絡的窗口
發現者不必四處尋覓地址，報告便更容易送達。
檢視已釋出的內容
格式有誤的檔案在外觀上毫無異樣，非經驗證便無從察覺。
防範失效
可定期查看 Expires 是否已然過期。
統一組織內的標準
同時營運數個網站時，可確認它們是否都遵循同一格式。
security.txt 的術語
- Contact
- 必填欄位，給出聯絡的途徑：電子郵件地址、電話號碼，或報告表單的網址。
- Expires
- 必填欄位，過了所寫的時刻，該檔案便應被視為過時，不宜再用。
- Encryption
- 指向一把公鑰，報告可藉它加密。
- Policy
- 一個頁面的網址，其上載明漏洞揭露的方針。
- Canonical
- 本檔案本應安放的權威網址。署名正是照著它來核驗的。
- Preferred-Languages
- 言明可以接收報告的語言，以逗號羅列，如
en, ja。
常見問題
https://example.com/.well-known/security.txt。由於許多實現也會檢查舊路徑 https://example.com/security.txt，建議為相容性同時釋出在兩處。mailto:[email protected]。沒有協議字首時，自動化解析工具可能無法正確識別。
閒話 ― security.txt 的誕生背景 ― 僅靠漏洞懸賞計劃無法解決的“第一聯絡視窗”問題
security.txt 由安全研究員 Ed Overflow 與 Kagan Baytas 於 2017 年提出。當時，發現漏洞的研究人員常常找不到明確的報告渠道，只能通過通用客服表單或社交媒體私信聯絡企業，報告經常輾轉多時才能送達正確的人，甚至被直接忽視。
該提案被提交至 IETF（網際網路工程任務組），經過多年討論與修訂，最終在 2022 年正式成為 RFC 9116 標準。其機制非常簡單：網站運營者只需在 /.well-known/security.txt 釋出一個文本檔案，研究人員即可機械化地瞭解應聯絡誰、使用何種語言以及遵循何種披露政策。
GitHub、Google、Facebook、LinkedIn 等眾多大型科技公司均已採用 security.txt，並常通過 Policy 欄位連結到漏洞披露或漏洞懸賞計劃頁面。它相當於一個“前門”，能夠觸達那些原本可能永遠發現不了漏洞懸賞平臺的研究人員。
作為 RFC 9116 的自然延伸，越來越多組織通過 CSAF 欄位連結到 CSAF（通用安全公告框架）文件，用以標準化漏洞公告的交換方式。security.txt 已不再只是一個聯絡方式檔案，而是持續演變為組織整體安全響應流程的入口。