security.txtのRFC 9116形式とは？Contact・Expiresの書き方と配信要件・診断基準

security.txtのRFC 9116形式とは

security.txtのRFC 9116形式とは、脆弱性の報告窓口を示す security.txt を、RFC 9116が定める「置き場所・配信方法・項目の書式」のとおりに公開することです。

Contact: mailto:security@city.example.lg.jp
Expires: 2027-03-31T23:59:59+09:00

security.txt は、Webサイトの脆弱性を見つけた人が「どこへ報告すればよいか」を機械的にも人間にも分かる形で示すテキストファイルです。2022年4月にRFC 9116（Informational。インターネット標準化過程の文書ではありません）として公開されました。ファイルは https://<ホスト>/.well-known/security.txt に置くことが義務付けられ（MUST）、報告窓口を示す Contact と、内容の有効期限を示す Expires が必須項目です。

セキュリティAIチェッカーのこの項目は「security.txtが存在すること」ではなく、「存在するsecurity.txtがRFC 9116の形式要件を満たしているか」 を評価します。ファイルを置いていても、期限切れ・Content-Type誤り・Contactの書式誤りがあると、報告者や自動収集ツールが正しく扱えず、窓口として機能しません。自治体サイトでは、情報システム担当課の連絡先を記載する公式な脆弱性受付窓口として活用できます。

ファイルの有無は「security.txtを公開」、有効期限の残り日数は「security.txtの有効期限」の各項目で評価します。このページは書式と配信形式に集中して解説します。

security.txtはRFC 9116でどう決められているか

配置場所と配信方法（RFC 9116 §3）

• /.well-known/security.txt に置かなければなりません（MUST）。後方互換のため、トップレベルの /security.txt に置くこと、または /.well-known/security.txt へリダイレクトすることも認められていますが、両方にある場合は /.well-known/ のものを使わなければなりません（MUST）。
• アクセスには https スキームを使わなければなりません（MUST）。
• Content-Type は text/plain で、charsetパラメーターを utf-8 にしなければなりません。
• リダイレクトは認められますが、報告者側はリダイレクト先が悪意あるものでないか確認すべきとされています。

security.txtの主な項目と書き方（RFC 9116 §2.5）

RFC 9116 §2.5は「特に記載のない限り、すべての項目は任意とみなさなければならない」と定めています。Canonical は任意項目ですが、記載する場合は取得したURIがその一覧に含まれていることで「このファイルがこの場所に適用される」ことを示します。OpenPGPによる電子署名は推奨（RECOMMENDED）です。

なぜ形式まで守る必要があるのか

security.txtは、人が読むだけでなく、脆弱性報告を支援するツールや収集サービスが機械的に読み取ることを前提にしたファイルです。Contact がURIでない、Expires が読めない・切れている、HTMLが返っている、といった状態では、ファイルが「ある」ように見えても窓口情報として採用されません。形式を守ることは、報告を確実に受け取るための最低条件です。

security.txtの書き方でよくある誤解

• Contact: security@example.jp と書けばよい：URI形式が必要なので Contact: mailto:security@example.jp と書きます。
• Expiresは任意：必須です。一度置いて更新しないと、期限切れのファイルは信頼されません。
• CanonicalはWebサーバーのホスト名だけ書けばよい：ファイルのURI全体（https://www.example.jp/.well-known/security.txt）を書きます。
• HTMLのエラーページが200で返っても置いたことになる：CMSのソフト404がHTMLを200で返すと、形式が満たせず無効です。

security.txtのRFC 9116形式の診断基準（セキュリティAIチェッカー）

取得対象

<最終URLのオリジン>/.well-known/security.txt をGETで取得します（リダイレクト最大3回、タイムアウト7秒、最大500,000バイト）。取得後の最終URLを「取得URL」として扱います。

対象外とする条件

ファイルの有無は別項目「security.txtを公開」で評価するため、本項目では二重に減点しません。

形式チェック（いずれかに該当すれば要確認）

Canonical が無いことは減点対象にしません（RFC上任意のため）。項目名は大文字小文字を区別せず、行頭一致で判定します。

判定と得点

• 形式の不備は窓口機能を弱めるものの、直ちに攻撃を招くものではないため、不合格ではなく要確認とします。
• 要確認の場合、根拠欄に「形式上の注意:」に続けて該当した指摘文言をすべて表示します。
• 重大度はlow、重みは1です。

自治体サイトでの判定例

security.txtの形式が不十分だとどんなリスクがあるか

• 脆弱性情報が届かない：報告者が連絡先を見つけられないと、代表メールや問い合わせフォームに送られて担当部署に届かない、あるいは報告そのものを断念され、脆弱性が放置されます。
• SNS等での公開：適切な窓口が無いと、発見者がやむを得ず公開の場で指摘し、修正前に攻撃者へ情報が伝わるおそれがあります。
• 古い連絡先への送信：期限切れのsecurity.txtに残る退職者や廃止アドレスに報告が送られ、受け手不在になります。Expiresによる鮮度管理はこれを防ぐ仕組みです。
• 改ざん・転用：署名やCanonicalが無いと、第三者が別サイトにコピーしたファイルや改ざんされたファイルとの区別がつきにくくなります。

日本では、ソフトウェア製品・Webサイトの脆弱性関連情報はIPAとJPCERT/CCによる「情報セキュリティ早期警戒パートナーシップ」でも受け付けています。security.txtはこれを置き換えるものではなく、サイト運営者への直接連絡経路を補うものです。

security.txtをRFC 9116形式で公開する方法（Apache・nginx・IIS・Next.js）

security.txtの記載例

Contact: mailto:security@city.example.lg.jp
Contact: https://www.city.example.lg.jp/contact/security.html
Expires: 2027-03-31T23:59:59+09:00
Preferred-Languages: ja, en
Canonical: https://www.city.example.lg.jp/.well-known/security.txt
Policy: https://www.city.example.lg.jp/about/vulnerability-policy.html

文字コードはUTF-8、改行はCRLFまたはLFとします。作成には securitytxt.org の作成支援も利用できます。

Apache（.htaccess）

<Files "security.txt">
  ForceType "text/plain; charset=utf-8"
</Files>
# /security.txt を /.well-known/ へ転送（任意）
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteRule ^security\.txt$ /.well-known/security.txt [R=301,L]
</IfModule>

.well-known ディレクトリへのアクセスを別の設定（隠しファイル遮断など）で拒否していないか確認します。RewriteRule "(^|/)\." - [F] や RedirectMatch 404 "/\." のように . で始まるパスを一律拒否している場合、.well-known が巻き込まれるため、.well-known を除外する条件を加えます。ForceType はコア機能のディレクティブで、.htaccess では AllowOverride FileInfo が必要です。

nginx

location = /.well-known/security.txt {
    default_type text/plain;
    charset utf-8;
    charset_types text/plain;
    try_files $uri =404;
}

IIS（web.config）

<location path=".well-known/security.txt">
  <system.webServer>
    <staticContent>
      <remove fileExtension=".txt" />
      <mimeMap fileExtension=".txt" mimeType="text/plain; charset=utf-8" />
    </staticContent>
  </system.webServer>
</location>

Next.js（Vercel）

public/.well-known/security.txt に置き、next.config.ts でヘッダーを指定します。

async headers() {
  return [{
    source: "/.well-known/security.txt",
    headers: [{ key: "Content-Type", value: "text/plain; charset=utf-8" }],
  }];
}

運用のポイント

1. 期限は1年未満（例: 年度末）に設定し、更新日を年間業務計画に組み込みます。
2. Contactには個人ではなく部署の共有アドレスを使います。
3. 受け付けた報告の対応手順（受領連絡の期限、関係部署・委託先への連絡）を決めて Policy で公開します。
4. 可能であればOpenPGPで署名し、Canonicalを記載します。

設定後の確認方法

curl -sI https://www.city.example.lg.jp/.well-known/security.txt | grep -i '^content-type'
curl -s  https://www.city.example.lg.jp/.well-known/security.txt

1行目で text/plain; charset=utf-8 が返ること、2行目で Contact と Expires が期待どおりに表示されることを確認し、セキュリティAIチェッカーで再診断します。

サイトを壊さないための注意点（ガードレール）

• .well-known 配下には他の重要ファイル（ACMEのHTTP-01認証、MTA-STSなど）も置かれます。アクセス制御を変更するときは既存のファイルを壊さないよう、security.txt に限定したルールにします。
• Contactに記載したアドレスが外部からのメールを受信できるか、迷惑メールフィルタで落とされないかを試験送信で確認します。

よくある質問（FAQ）

参考資料

• RFC 9116「A File Format to Aid in Security Vulnerability Disclosure」
• securitytxt.org（作成支援）
• OWASP Web Security Testing Guide v4.2 Information Gathering
• IPA「情報セキュリティ早期警戒パートナーシップガイドライン」

「security.txtのRFC 9116形式」と関連する診断項目

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