security.txt作成
脆弱性の報告窓口を知らせるsecurity.txtをRFC 9116の形式で作成
特徴
規格どおりの形式で生成
RFC 9116のフィールド名と並び順で出力
必須項目の抜けを防止
連絡先と有効期限の未入力をその場で表示
有効期限の初期値つき
今日から1年後が最初から入り超過時は注意
コピーとダウンロード
生成結果をそのままsecurity.txtとして保存
使い方
連絡先を入力
メールアドレスかhttpsのURLを入力し、必要なら追加する
有効期限を確認
今日から1年後が入っているので、必要に応じて変更する
任意項目を入力
詳細設定を開き、対応言語やポリシーページのURLを入れる
生成して保存
生成ボタンを押し、コピーまたはダウンロードする
ユースケース
初めての設置
自社サイトに脆弱性の報告窓口を公開する
有効期限切れ前の更新
期限が近づいたファイルを同じ内容で作り直す
複数窓口の掲載
メールとフォームのURLを優先順に並べて示す
セキュリティ診断の指摘対応
監査で求められた設置要件を満たす
基礎知識
security.txtとは
security.txtとは、Webサイトの脆弱性を見つけた人がどこへ報告すればよいかを、機械にも人にも読める形で書いたテキストファイルのことです。RFC 9116という規格が、書き方と置き場所を定めています。
- Contact:報告を受け取る窓口を書く必須のフィールドで、メールアドレスは「mailto:security@example.com」、Webフォームは「https://」で始まるURLの形で書きます。
- Expires:この内容がいつまで有効かを書く必須のフィールドで、「2027-03-31T00:00:00.000Z」のように日付と時刻を組み合わせた形式で書きます。
なぜ/.well-known/に置くのか
報告したい人が置き場所を探さずに済むよう、規格が場所を1つに決めているためです。正式な設置場所は「https://example.com/.well-known/security.txt」になります。
- .well-knownフォルダ:サイトに関する情報を決まった名前で置くための共用フォルダで、証明書の発行やアプリ連携の設定ファイルも同じ場所に置かれます。
Expiresを1年以内にする理由
古い連絡先が残り続けると、報告が届かないまま放置される恐れがあるためです。RFC 9116は有効期限を1年以内にすることを推奨しており、期限が切れたsecurity.txtは無効なものとして扱われます。
- 期限が切れたとき:内容を見直したうえで新しい期限を入れたファイルに置き換えるので、連絡先が変わっていなくても設置し直す運用になります。
安全性とプライバシー
ブラウザ完結
入力データはお使いのブラウザ内だけで処理され、外部に送信されません。
ブラウザ内のみで処理
security.txtの組み立てはすべてお使いのブラウザ内で行われ、入力データはサーバーに送信されません。
通信はHTTPSで暗号化
ページの読み込みもTLSにより暗号化され、第三者から内容を読み取られません。
第三者への送信なし
広告ネットワークやトラッカーなど外部サービスへ入力内容を送信しません。
結果の自動保存なし
入力した連絡先やURLや入力候補をサーバーに保管することはありません。
更新情報
- update #249
security.txt作成を追加、連絡先と有効期限から規格どおりに生成




















