security.txt とは — 脆弱性の連絡先を公開する（RFC 9116）

security.txt は、あなたのサイトに脆弱性を見つけた人が「どこへ報告すればいいか」を伝えるための標準ファイルです（RFC 9116）。/.well-known/security.txt に置き、報告先の Contact と有効期限の Expires を必ず書きます。連絡先を公開するだけでなく、報告を受け取って対応する体制まで用意して初めて意味を持ちます。

執筆: JIT株式会社公開: 2026年7月17日

security.txt とは何ですか？

security.txt は、Web サイトの脆弱性を見つけた人に「どこへ報告すればよいか」を伝える、RFC 9116 で標準化されたテキストファイルです。セキュリティ研究者が報告先を機械可読な形で見つけられるようにし、連絡経路の行き違いを防ぎます。設置は義務ではありませんが、報告を受け付ける意思の表明になります。

Web サイトを運用していると、外部のセキュリティ研究者や善意の利用者が、思わぬ脆弱性に気づくことがあります。ところが多くのサイトには「セキュリティに関する連絡先」が明示されていません。発見者は問い合わせフォームや代表メールに手探りで報告するしかなく、その報告は営業窓口で埋もれたり、誰にも届かないまま放置されたりします。

security.txt は、この「報告先が分からない」問題を解決するために生まれた、ごく小さなテキストファイルです。 2022 年に RFC 9116 として標準化され、決められた場所に決められた書式で置くだけで、人にも機械にも「脆弱性はここへ報告してください」と伝えられます。中身は特別なものではなく、連絡先を数行書いたプレーンテキストにすぎません。

なぜ security.txt が必要なのですか？

脆弱性を見つけた人が連絡先を探して迷わないようにするためです。報告先が不明だと、善意の発見者が問い合わせフォームから届かなかったり、最悪は報告を諦めて公開されてしまいます。連絡経路を 1 か所に定めておけば、報告が正しい担当へ最短で届き、悪用される前に修正する時間を確保できます。

脆弱性の報告は、時間との勝負です。発見者が報告先を見つけられずに迷っている間にも、同じ穴が別の誰かに悪用されるかもしれません。報告経路が明示されていれば、発見から修正までの時間を短くできます。これは攻撃者に先を越されないための備えです。

もう 1 つの効果は、発見者との関係づくりです。連絡先を公開しておくことは、「脆弱性の報告を歓迎します」という姿勢の表明になります。窓口が用意されていないサイトでは、発見者は「報告しても無視される」「下手に連絡すると不正アクセスを疑われる」と感じ、報告そのものを諦めがちです。security.txt は、こうした心理的なハードルを下げる役割も果たします。

security.txt はどこに置きますか？

ドメイン直下の /.well-known/security.txt に置き、HTTPS で配信します。歴史的にはルート直下の /security.txt も使われましたが、RFC 9116 が定める正規の場所は .well-known 配下です。研究者やツールはまずこのパスを見に来るため、決められた場所に置くことが「見つけてもらう」ための前提になります。

置き場所は 1 か所に決まっています。https://あなたのドメイン/.well-known/security.txt です。.well-known は、こうした「サイトのメタ情報」を集めるために定められた標準ディレクトリで、証明書の自動発行などでも使われています。歴史的な経緯からルート直下の /security.txt に置く例も残っていますが、正規の場所は .well-known 配下だと覚えておけば十分です。両方に置いて構いませんが、少なくとも .well-known 側は必ず用意します。

必須のフィールドは何ですか？

必須は Contact と Expires の 2 つです。Contact は報告先で、mailto: か https:// の URL を書き、複数指定もできます。Expires はこのファイルの有効期限を ISO 8601 の日時で書き、未来の日付にして切れる前に更新します。この 2 つが揃っていないと、RFC 9116 に準拠した security.txt とは見なされません。

書式は「フィールド名: 値」を 1 行に 1 つ、というシンプルなものです。行頭が # の行はコメントとして無視されます。必須は次の 2 つで、どちらか一方でも欠けると準拠したファイルにはなりません。

Contact — 報告先。mailto:security@example.com のようなメール、またはhttps://example.com/security/report のような報告用ページの URL を書く。複数行に分けて複数指定でき、上に書いたものほど優先度が高いとみなされる
Expires — このファイルの有効期限。2027-01-31T23:59:59.000Z のような ISO 8601 形式の日時で書く。必ず未来の日付にし、期限が切れる前に更新する

最小構成（この 2 行でも RFC 9116 準拠）

# まずはこの 2 行だけでも RFC 9116 に準拠する
Contact: mailto:security@example.com
Expires: 2027-01-31T23:59:59.000Z

Expires がわざわざ必須になっているのは、放置を防ぐためです。連絡先は組織の変化で古くなります。有効期限を書かせることで「このファイルはいつ時点のものか」を明確にし、期限が来たら見直す習慣を促しています。

任意のフィールドには何がありますか？

Contact と Expires 以外はすべて任意です。よく使うのは、PGP 公開鍵の場所を示す Encryption、謝辞ページの Acknowledgments、対応方針を書いた Policy、優先言語の Preferred-Languages、正規 URL を示す Canonical、採用情報の Hiring です。必要なものだけ書けばよく、無理にすべて埋める必要はありません。

必須の 2 つ以外は、必要に応じて足します。よく使われるフィールドを次の表にまとめます。すべてを埋める必要はなく、自分の運用で意味を持つものだけを書けば十分です。

security.txt の主なフィールド
フィールド	必須	意味	値の例
`Contact`	必須	脆弱性の報告先	`mailto:security@example.com`
`Expires`	必須	このファイルの有効期限	`2027-01-31T23:59:59.000Z`
`Encryption`	任意	報告を暗号化するための PGP 公開鍵の URL	`https://example.com/pgp-key.txt`
`Acknowledgments`	任意	報告者への謝辞を載せたページ	`https://example.com/security/thanks`
`Policy`	任意	脆弱性開示の方針ページ	`https://example.com/security/policy`
`Preferred-Languages`	任意	報告で使ってほしい言語	`ja, en`
`Canonical`	任意	このファイルの正規 URL	`https://example.com/.well-known/security.txt`
`Hiring`	任意	セキュリティ人材の採用情報	`https://example.com/careers`

任意フィールドまで含めた例（/.well-known/security.txt）

# https://example.com/.well-known/security.txt
# 行頭が # の行はコメント。フィールドは「名前: 値」で 1 行ずつ書く

Contact: mailto:security@example.com
Contact: https://example.com/security/report
Expires: 2027-01-31T23:59:59.000Z
Encryption: https://example.com/pgp-key.txt
Acknowledgments: https://example.com/security/thanks
Policy: https://example.com/security/policy
Preferred-Languages: ja, en
Canonical: https://example.com/.well-known/security.txt
Hiring: https://example.com/careers

Encryption で PGP 公開鍵を示しておくと、発見者は脆弱性の詳細を暗号化して安全に送れます。また RFC 9116 では、ファイル自体に PGP の電子署名を付けることも認められていますが、署名は必須ではありません。まずは平文で 2 つの必須フィールドを正しく書くことを優先してください。

運用で気をつけることは何ですか？

連絡先を公開したら、報告を受け取って対応する体制まで用意することです。置くだけで返信しないのは、かえって不誠実な印象を与えます。あわせて Expires が切れないよう定期的に更新してください。期限切れのファイルは放置された連絡先と見なされ、研究者に「この窓口は生きていない」と判断される原因になります。

security.txt は「置いて終わり」のファイルではありません。連絡先を公開するということは、そこへ届いた報告を受け取り、確認し、対応する体制を持つという約束です。報告に一切反応しない連絡先は、無いよりも印象を悪くします。まずは、書いたメールアドレスが確実に人へ届き、誰かが読む運用になっているかを確かめてください。

セキュリティは 1 つの施策で完結するものではありません。security.txt は「報告を受ける入口」であり、攻撃を実際に防ぐレスポンスヘッダや、なりすましメールを防ぐ送信ドメイン認証と組み合わせて、はじめてサイト全体の守りになります。

正しく設置できたかどう確認しますか？

ブラウザで自分のドメインの /.well-known/security.txt を開き、HTTPS で表示されるか、Contact と Expires が正しく書かれているかを確認します。securitytxt.org のフォームに貼れば書式の検証もできます。Expires が過去になっていないか、報告先のアドレスが実際に受信できるかも必ず確かめてください。

設置したら、次の順で確認すると確実です。機械的に見られるのは「ファイルがあるか・書式が正しいか」までで、報告が実際に人へ届くかは、自分でテスト送信して確かめるのが安全です。

ブラウザで https://あなたのドメイン/.well-known/security.txt を開き、HTTPS で本文が表示されるか
Contact と Expires の 2 行が揃っていて、Expires が未来の日付になっているか
securitytxt.org のバリデータに内容を貼り、書式のエラーや警告が出ないか
Contact に書いたメールアドレスへ試しに送り、受信・気づける運用になっているか

ここまで確認できれば、脆弱性を見つけた人があなたの窓口へ迷わずたどり着き、悪用される前に知らせてくれる可能性が高まります。小さなファイル 1 つですが、「報告を歓迎する」という姿勢を機械可読で示す効果は決して小さくありません。