security.txt 作成ツール — RFC 9116 準拠のファイルを作成・検証
連絡先、有効期限、暗号化、ポリシーの各フィールドを備えた有効な security.txt（RFC 9116）を作成し、既存のファイルもチェックして、/.well-known/ 用にダウンロードできます。
メールアドレス、https:// の報告フォーム、電話番号。メールアドレスだけの場合は mailto: が付加されます。優先する連絡先を先頭に書いてください。
RFC 3339 形式の日時で、1 年未満先の日付にします。期限切れになる前に更新できるよう、カレンダーにリマインダーを登録しておきましょう。
PGP 公開鍵の URL（https://、dns:、openpgp4fpr:）。鍵そのものではありません。
カンマ区切りの言語タグ。例：ja、en、pt-BR。
このファイルが置かれている https:// の URL。署名する場合は事実上必須です。
脆弱性開示ポリシー：対象範囲、セーフハーバー、対応方法。
問題を報告してくれた研究者への謝辞ページ（殿堂）。
セキュリティ関連の求人。
機械可読なアドバイザリーを公開するベンダー向け：provider-metadata.json の URL。
有効：必須フィールドがすべて揃っており、すべての値が RFC 9116 に準拠しています。
…
- HTTPS で
https://yourdomain.com/.well-known/security.txtにtext/plain; charset=utf-8として配信します。必要に応じて/security.txtからリダイレクトしてください。 - Next.js、Astro、Vite やほとんどの静的ホスティング：
public/.well-known/security.txtとして保存します。WordPress、Apache、nginx：Web ルートに.well-knownフォルダーを作成します。 - 独自のサイトを配信するサブドメインには、それぞれ専用のファイルを置きます（またはコメントでメインのファイルを案内します）。
- 任意：
gpg --clearsign security.txtで署名し、署名済みの出力を公開します。署名が設置場所も保証するよう、Canonical を含めてください。
すべてブラウザ内で動作します。入力内容が送信・保存されることはありません。 すべての無料ツールを見る.
不具合や改善できそうな点を見つけましたか？いただいたメッセージはすべて読み、すぐに対応します。
この無料の security.txt 作成ツールは、RFC 9116 として標準化された小さなテキストファイルを作成します。このファイルは、サイトの脆弱性をどう報告すればよいかをセキュリティ研究者に伝えるものです。連絡先と有効期限、そして任意で暗号鍵、開示ポリシー、謝辞ページ、対応言語、正規 URL を入力します。ファイルは入力に合わせて RFC に照らして検証され、security.txt としてダウンロードでき、そのまま /.well-known/security.txt にアップロードできます。
このファイルがないと、サイトの脆弱性を見つけた人はどこに送ればよいか推測するしかなく、報告はサポートの受信箱や SNS に届くか、どこにも届きません。作成は 5 分で済み、多くのセキュリティスキャナーやバグバウンティの研究者がチェックしています。2 つ目のタブでは、すでに公開しているファイルを検証できます。このツールはファイルに署名せず（署名には gpg を使ってください）、公開中のファイルを取得することもありません。このページはネットワークリクエストを一切行わないためです。
使い方
- Contact を少なくとも 1 つ入力します。セキュリティ用のメールアドレス、報告フォームの URL、電話番号のいずれかです。優先するものを最初に置きます。
- ボタンのいずれかで Expires を設定するか（6 か月が無難な初期値です）、RFC 3339 の日時を入力します。
- 用意できる任意のフィールドを追加します。PGP 鍵の URL、開示ポリシー、謝辞ページ、読める言語、ファイルの正規 URL です。
- 赤で示された項目を修正します。黄色の項目は推奨事項です。
- security.txt をダウンロードし、https://yourdomain.com/.well-known/security.txt に text/plain として公開します。Expires を更新するためのリマインダーを設定しておきましょう。
よくある質問
security.txt とは何ですか？
/.well-known/security.txt に置くプレーンテキストのファイルで、Web サイトや製品のセキュリティ脆弱性をどう報告すればよいかを記載します。2022 年 4 月に IETF から RFC 9116 として公開されました。必須のフィールドは Contact と Expires の 2 つだけで、残り（Encryption、Acknowledgments、Preferred-Languages、Canonical、Policy、Hiring）は任意です。
security.txt ファイルはどこに置けばよいですか？
https://yourdomain.com/.well-known/security.txt に、コンテンツタイプ text/plain; charset=utf-8 で HTTPS 経由で配信します。ルートの /security.txt という旧来の場所も一部のツールでは今も読まれるので、そこにコピーを置くかリダイレクトしても構いません。Next.js、Astro、Vite や多くの静的ホスティングでは、ファイルを public/.well-known/ に置きます。独立したサイトであるホスト名には、それぞれ専用のファイルが必要です。
Expires フィールドが必須なのはなぜですか？
古くなった連絡先がいつまでも信頼されないようにするためです。RFC 9116 は Expires を必須とし、1 年未満先の日付を推奨しています。期限が過ぎたら、研究者やスキャナーはそのファイルを古いものとして扱うべきです。6 か月にして更新用のカレンダーのリマインダーを設定するのが現実的なリズムで、日付が過去だったり 1 年以上先だったりすると、作成ツールが警告します。
security.txt に署名すべきですか？
署名は任意ですが推奨されています。公開鍵を公開している鍵（Encryption フィールドでその場所を示せます）で gpg --clearsign security.txt を実行し、署名済みの出力を代わりにアップロードします。署名する場合は Canonical フィールドを含めてください。そうすれば、ある URL から取得した署名済みのコピーを、別の URL で有効なものとして悪用されることがありません。
バグバウンティのプラットフォームのリンクを連絡先にできますか？
はい。Contact には https:// の URI なら何でも使えるので、HackerOne、Bugcrowd、Intigriti、YesWeHack のプログラムページや、自社の報告フォームでも有効です。多くの組織は、プラットフォームのリンクとメールアドレスの両方を優先順に記載しています。
RFC 9116 のフィールド一覧
• Contact（必須、複数可）：mailto:、https:、tel: の URI。順序が優先度を表します。
• Expires（必須、1 回のみ）：2027-04-30T23:59:59Z のような RFC 3339 の日時。1 年未満先を推奨。
• Encryption（複数可）：公開鍵の取得場所。https://、dns:（OPENPGPKEY レコード）、openpgp4fpr:（フィンガープリント）で指定します。鍵そのものは決して貼り付けないでください。
• Acknowledgments（複数可）：報告者への謝辞ページ。
• Preferred-Languages（1 回）：カンマ区切りの言語タグ。例：en, fr。
• Canonical（複数可）：このファイルを置くべき URL。
• Policy（複数可）：脆弱性開示ポリシー。
• Hiring（複数可）：セキュリティ関連の求人。
• CSAF（複数可、OASIS が登録）：CSAF アドバイザリーフィードの provider-metadata.json。
Web の URI には https:// を使う必要があります。# で始まる行はコメントです。
開示ポリシーに書くべきこと
Policy のリンク先は、報告しても安全かどうかを研究者が確認する場所です。対象範囲（どのドメインやアプリか）、対象外のもの（サービス拒否、ソーシャルエンジニアリング、自動スキャナーの出力）、報告にどれくらいの速さで受領連絡と修正を行うか、報奨金を出すかどうか、そしてポリシーに従った善意の調査に対して法的措置を取らないというセーフハーバーの声明を記載しましょう。短くわかりやすいページのほうが、長い法律文書より役に立つ報告が集まります。
security.txt と robots.txt
2 つは並んで置かれますが、役割は異なります。robots.txt はクローラーに取得しないでほしいものを伝え、security.txt は人にセキュリティ担当への連絡方法を伝えます。security.txt や /.well-known/ を Disallow に記載しないでください。研究者やスキャナーはこれを読む必要がありますし、robots.txt でブロックしてもどのみち隠せません。
関連する無料ツール
- robots.txt ジェネレーター — すべて許可、ステージング、WordPress のプリセット、AI クローラーのセクション（学習はブロック、AI 検索は維持）、インデックスから消えるミスへの警告付きで robots.txt を作成します。
- パスワード生成 — 強力なランダムパスワード、覚えやすいパスフレーズ、PIN を生成します。すべてブラウザ内で動作し、何も送信・保存されません。
- メタタグ生成 — ページのタイトル、ディスクリプション、SNS カードの情報を入力すると、文字数カウンター付きで、正しくエスケープされた完全な <head> ブロックを生成します。
- JWT デコーダー — JWT のヘッダーとペイロードをデコードし、有効期限をわかりやすく表示し、HS・RS・PS・ES の署名を検証したり、新しいトークンに署名したりできます。何もブラウザの外に出ません。