security.txt バリデーター
security.txt（RFC 9116）の内容を貼り付けて構文エラーを検出。Contact・Expiresなど必須フィールドの有無や値の形式を検証し、/.well-known/security-textへ正しく設置できているか確認できます。
Tips
- security.txtは
/.well-known/security-textへの設置が正式な仕様です。互換性のため/security.txt（サイトのルート直下）へも設置しておくと安心です。 - Contactはmailto:・https:・tel:などスキーム付きのURIで記述しましょう。平文のメールアドレスだけではRFC 9116準拠にならず、自動解析ツールに認識されない場合があります。
- Expiresは長くても1年以内の日付に設定し、更新の都度延長する運用が推奨されています。期限切れのファイルは「もう見られていない連絡先」とみなされるリスクがあります。
- このツールの検証はすべてブラウザ内で完結し、入力内容は外部送信されません。実運用前のファイルを安心して貼り付けて確認できます。
よくある質問
https://example.com/.well-known/security-textです。ただし多くの実装が旧仕様のhttps://example.com/security.txtも参照するため、互換性のために両方に設置しておくことが推奨されます。mailto:[email protected]のようにスキームを付けることが必須です。スキームがないと機械的な解析ツールが正しく認識できない場合があります。
余談ですが ― security.txtが生まれた背景 ― バグバウンティだけでは足りなかった「最初の連絡窓口」
security.txtは2017年、セキュリティ研究者のEd Overflow氏とKagan Baytas氏によって提案されました。当時、脆弱性を発見した研究者が企業に報告しようとしても、適切な連絡先が見つからず、一般問い合わせ窓口やSNSのDMで報告せざるを得ないケースが多発していました。担当者に届くまでに時間がかかったり、そもそも黙殺されたりすることも珍しくありませんでした。
この提案はIETF（Internet Engineering Task Force）に持ち込まれ、長い議論と改訂を経て2022年にRFC 9116として正式な標準になりました。仕組みは非常にシンプルで、Webサイト運営者が/.well-known/security-textにテキストファイルを1つ公開するだけで、研究者は誰に・どの言語で・どのような方針で報告すべきかを機械的に把握できます。
GitHub・Google・Facebook・LinkedInなど多くの大手テック企業がsecurity.txtを採用しており、脆弱性開示プログラム（バグバウンティ）へのリンクをExpiresやPolicyフィールド経由で案内する例も一般的です。バグバウンティのプラットフォームだけでは見つけてもらえない研究者にもリーチできる、いわば「最初の窓口」としての役割を果たしています。
RFC 9116の後継として、脆弱性情報の交換形式を標準化するCSAF（Common Security Advisory Framework）へのリンクをCSAFフィールドで示す拡張も広がりつつあります。security.txtは単なる連絡先ファイルにとどまらず、組織のセキュリティ対応体制全体の入り口として進化を続けています。