security.txtを公開するには？RFC 9116の書き方・設置場所・診断基準

security.txtを公開するとは

security.txtを公開するとは、Webサイトの脆弱性を見つけた人（研究者、利用者、セキュリティ企業）が「どこに連絡すればよいか」を、機械的にも人間にも分かる形で示すテキストファイルを置くことです。RFC 9116（2022年4月）で標準化され、https://ドメイン/.well-known/security.txt に置きます。

Contact: mailto:security@city.example.lg.jp
Contact: https://www.city.example.lg.jp/security/report.html
Expires: 2027-03-31T14:59:59.000Z
Preferred-Languages: ja, en
Canonical: https://www.city.example.lg.jp/.well-known/security.txt
Policy: https://www.city.example.lg.jp/security/policy.html

自治体サイトでは、問い合わせフォームや代表電話はあっても、「脆弱性の報告」を受け付ける窓口が明示されていないことが多くあります。その結果、善意の報告者が連絡先に迷って報告を諦めたり、一般の問い合わせ窓口に送った報告が担当部署に届かなかったりします。security.txtはこのすれ違いを減らすための低コストな仕組みです。

この項目は、security.txtが所定の場所に、連絡先（Contact）を含むテキストとして公開されているかを確認します。Expiresの期限は「security.txtの有効期限」、Content-Typeや重複など形式面は「security.txtのRFC 9116形式」で別に評価します。

security.txtの書き方と設置場所（RFC 9116の要件）

ファイルの要件

• 置き場所は /.well-known/security.txt（MUST）。後方互換のためサイト直下 /security.txt に置く（またはリダイレクトする）ことも認められますが、両方ある場合は .well-known が優先されます。
• HTTPSで配信します（MUST）。
• Content-Type: text/plain; charset=utf-8 で配信します。
• 必須フィールドは Contact（1つ以上）と Expires（ちょうど1つ）です。
• 推奨・任意のフィールド: Encryption（暗号化鍵の場所）、Acknowledgments（謝辞ページ）、Preferred-Languages、Canonical（このファイルの正規URL）、Policy（脆弱性開示方針）、Hiring。
• OpenPGPのクリアテキスト署名を付けることが推奨されています（RECOMMENDED）。
• 研究者は、取得時にリダイレクトがあれば記録し、攻撃者の管理する先へ誘導されていないか注意すべきとされています。

Contactの書き方

Contact には mailto:、tel:、https: のURIを書きます。メールアドレスだけでなく、報告フォームのURLを併記すると、添付や暗号化の扱いを案内しやすくなります。Contactを複数書いた場合は、記載順が優先順位を表します。

フィールドの選び方

コメント行は # で始めます。Policy のページには、報告の受付対象（本庁サイト、施設予約等の関連サイト）、受領確認の目安、報告者に求めること（実害を与える検証をしない等）を書いておくと、報告の質が上がります。

同じ組織の複数ドメインの扱い

security.txtはそのファイルを置いたホスト名に対して有効です。本庁サイト、観光サイト、施設予約などをサブドメインや別ドメインで運用している場合は、それぞれに置くか、主要なサイトに置いたうえで Policy に対象範囲を記載します。

security.txtについてよくある誤解

• 「security.txtを置くと攻撃を招く」：攻撃者は窓口の有無にかかわらず探索します。security.txtは善意の報告を受け取りやすくするための仕組みで、新たな攻撃面を開くものではありません。ただし掲載する連絡先は、迷惑メール対策と受付体制を前提に選びます。
• 「バグバウンティ（報奨金）を出さないと置けない」：報奨金の有無とは無関係です。Policy で「報奨金はありません」「報告の取扱い」を説明できます。
• 「HTMLの問い合わせページで代用できる」：人間には読めても、自動化ツールや研究者の標準的な確認手順では見つけられません。

security.txtを公開の診断基準（セキュリティAIチェッカー）

取得方法

• 診断の最終URLのオリジンに対し /.well-known/security.txt をGETします（リダイレクトは追跡しない、タイムアウト4秒、最大100,000バイト。上限を超える応答は先頭部分で打ち切って判定）。
• 次のすべてを満たすものを「有効なsecurity.txt」とみなします。
  1. ステータス200
  2. 本文がHTMLではない（先頭1,000文字に <!doctype html>、<html>、<head>、<body>、<div>、<script> がない）
  3. 行頭（空白可）に Contact: があり、その後に値が続く（大小文字を区別しない）

判定条件

対象外（na）と × 要改善（fail）はありません。security.txtはすべての公開Webサイトに適用できる推奨事項であるため、ない場合は △（改善余地）とします。

判定の補足

• ソフト404（存在しないURLにもHTMLを200で返すCMS）では、HTML判定により「security.txtあり」と誤判定しないようにしています。
• リダイレクトは追跡しないため、/.well-known/security.txt を別URLへ転送している構成は △ になります。RFC 9116は .well-known への設置をMUSTとしているため、ファイルを直接置く構成を推奨します。
• サイト直下の /security.txt だけを置いている場合も △ です（後方互換の位置であり、正規の位置は .well-known）。
• 有効期限（Expires）は「security.txtの有効期限」で別に評価します。

自治体サイトでの判定例

security.txtがないとどんなリスクがあるか

• 報告の取りこぼし：脆弱性を見つけた第三者が窓口を見つけられず、報告されないまま放置される、あるいはSNS等で公開されてしまうおそれがあります。
• 報告の遅延：一般の問い合わせフォームに届いた報告が、情報システム担当に回るまでに時間がかかり、その間に悪用されるおそれがあります。
• 偽の窓口：security.txtが改ざんされると、報告が攻撃者に流れる可能性があります。Canonicalや署名、ファイルの変更監視で対策します。

security.txtがないこと自体が直接の脆弱性になるわけではないため、重大度はlowです。

security.txtの設置方法（Apache・nginx・IIS・Next.js・CMS）

1. 受付体制を決める

• 受付アドレス（例: security@ や情報政策課の共有アドレス）またはフォームを決め、受領確認・調査・委託事業者への連絡・回答までの流れを定めます。
• 必要に応じて、IPAの届出制度（情報セキュリティ早期警戒パートナーシップ）経由の連絡も受けられることを Policy で案内します。

2. ファイルを設置する

Apache（静的ファイルとして設置）:

# /.well-known/security.txt を置いたうえで、Content-Typeを明示
<Files "security.txt">
  ForceType "text/plain; charset=utf-8"
</Files>

nginx:

location = /.well-known/security.txt {
    alias /var/www/security/security.txt;
    default_type text/plain;
    charset utf-8;   # Content-Typeに charset=utf-8 を付ける
}

IIS：.well-known フォルダを作成してファイルを置き、拡張子 .txt のMIMEが text/plain であることを確認します。ドットで始まるフォルダをリクエストフィルタリングで拒否している場合は、.well-known を除外します。

Next.js（Vercel）：public/.well-known/security.txt に置くと静的配信されます。App Routerの Route Handler（app/.well-known/security.txt/route.ts）で Content-Type を付けて返すこともできます。

CMS（WordPress等）：プラグインではなく、Webサーバーのドキュメントルートに直接ファイルを置くのが確実です。CMSのルーティングが全URLを捕捉する設定では、.well-known を除外します。

3. 設置後の確認方法

curl -sI https://www.city.example.lg.jp/.well-known/security.txt
curl -s  https://www.city.example.lg.jp/.well-known/security.txt

ステータス200、Content-Type: text/plain; charset=utf-8、本文に Contact: と Expires: があることを確認します。あわせて、curl -sI の結果に Location: ヘッダー（リダイレクト）が含まれていないこと、掲載したアドレスへ試験メールを送り担当者に届くことも確認してください。最後にセキュリティAIチェッカーで再診断し、○ になることを確かめます。

設置時の注意点（ガードレール）

• ドットファイルを拒否するWebサーバー設定（.git 対策など）を入れている場合、/.well-known/ を例外にしないと404/403になります。管理ファイルの拒否設定は「代表的な管理ファイルが公開されていない」で解説しています。
• 掲載したアドレスは公開されるため、スパムが増える前提で迷惑メールフィルタと担当者の確認手順を用意します。個人名のアドレスは避けます。
• Expiresは必須です。期限切れのファイルは信頼性が下がるため、更新日を年間スケジュールに組み込みます。

よくある質問（FAQ）

参考資料

• RFC 9116 A File Format to Aid in Security Vulnerability Disclosure
• OWASP WSTG-INFO-03 Review Webserver Metafiles for Information Leakage
• securitytxt.org（RFC 9116の作成支援サイト）
• IPA 脆弱性関連情報の届出受付（情報セキュリティ早期警戒パートナーシップ）

「security.txtを公開」と関連する診断項目

• security.txtの有効期限low
• security.txtのRFC 9116形式low
• 代表的な管理ファイルが公開されていないcritical
• サーバーバージョンを露出していないlow
• 秘密情報らしき文字列がないcritical
• ソースマップ参照を公開していないmedium
• 生成ツール情報を露出していないlow
• 本番HTMLにconsole.logを残していないlow