security.txt チェッカー
security.txt（RFC 9116）の内容を貼り付けて構文エラーを検出。Contact・Expiresなど必須フィールドの有無や値の形式を検証し、/.well-known/security.txtへ正しく設置できているか確認できます。
security.txtの書式を検証する
security.txt は、脆弱性を見つけた人がどこへ連絡すればよいかをサイト側から示すためのテキストファイルで、RFC 9116 で書式が定められています。このツールは内容を貼り付けるだけで構文を検証し、`Contact` や `Expires` といった必須フィールドの有無と値の形式を確認します。
**ここで見落とされがちなのが `Expires` の扱いです。** これは必須フィールドであるうえ、**指定した日時を過ぎたファイルは有効でないものとして扱われます。** 一度設置して放置すると、何年か後には「あるのに効いていない」状態になるため、更新の予定とあわせて運用する必要があります。**置き場所も決まっていて、`/.well-known/security.txt` に配置します。** 署名を付ける場合は `Canonical` フィールドで正規のURLを示し、改ざんされていないことを確かめられるようにします。
使い方
- security.txt の内容を貼り付ける ファイル全体をそのまま入れてください。
- サンプルで挙動を確かめる 正常な例とエラーを含む例が用意してあります。
- 指摘された項目を読む **必須フィールドの欠落と、値の形式の誤りが示されます。**
- `Expires` の日時を確認する **過去の日時になっていないか、いつ更新するかを決めておいてください。**
使いこなすためのヒント
- security.txtは
/.well-known/security.txtへの設置が正式な仕様です。互換性のため/security.txt（サイトのルート直下）へも設置しておくと安心です。 - Contactはmailto:・https:・tel:などスキーム付きのURIで記述しましょう。平文のメールアドレスだけではRFC 9116準拠にならず、自動解析ツールに認識されない場合があります。
- Expiresは長くても1年以内の日付に設定し、更新の都度延長する運用が推奨されています。期限切れのファイルは「もう見られていない連絡先」とみなされるリスクがあります。
- このツールの検証はすべてブラウザ内で完結し、入力内容は外部送信されません。実運用前のファイルを安心して貼り付けて確認できます。
活用シーン
脆弱性の窓口を明示する
発見者が連絡先を探し回らずに済み、報告が届きやすくなります。
設置内容を点検する
**書式の誤りがあっても画面上は何も起こらないため、検証しないと気づけません。**
失効を防ぐ
`Expires` が切れていないかを定期的に確かめられます。
社内の基準を揃える
複数サイトを運用している場合、同じ書式で揃っているかを確認できます。
security.txtの用語
- Contact
- **必須フィールド**です。メールアドレス・電話番号・報告フォームのURLなど、連絡手段を書きます。
- Expires
- **必須フィールド**で、この日時を過ぎるとファイルは有効でないものとして扱われます。
- Encryption
- 報告を暗号化するための公開鍵の在り処を示します。
- Policy
- 脆弱性の開示に関する方針を書いたページのURLです。
- Canonical
- このファイルが置かれるべき正規のURLです。**署名の検証に使われます。**
- Preferred-Languages
- 報告を受け付けられる言語を示します。`en, ja` のようにカンマで並べます。
よくある質問
https://example.com/.well-known/security.txtです。ただし多くの実装が旧仕様の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.txtにテキストファイルを1つ公開するだけで、研究者は誰に・どの言語で・どのような方針で報告すべきかを機械的に把握できます。
GitHub・Google・Facebook・LinkedInなど多くの大手テック企業がsecurity.txtを採用しており、脆弱性開示プログラム（バグバウンティ）へのリンクをExpiresやPolicyフィールド経由で案内する例も一般的です。バグバウンティのプラットフォームだけでは見つけてもらえない研究者にもリーチできる、いわば「最初の窓口」としての役割を果たしています。
RFC 9116の後継として、脆弱性情報の交換形式を標準化するCSAF（Common Security Advisory Framework）へのリンクをCSAFフィールドで示す拡張も広がりつつあります。security.txtは単なる連絡先ファイルにとどまらず、組織のセキュリティ対応体制全体の入り口として進化を続けています。