security.txtの有効期限（Expires）とは？書式・推奨期間・更新手順・診断基準

security.txtの有効期限（Expires）とは

security.txtの有効期限とは、security.txtの Expires フィールドで示す「このファイルの内容をいつまで信頼してよいか」を表す日時です。RFC 9116では Expires は必須で、ちょうど1回だけ記載し、期限を過ぎたsecurity.txtは古い（stale）ものとして扱うべきとされています。また、内容の陳腐化を避けるため、1年未満先の日時にすることが推奨されています（RECOMMENDED）。

Expires: 2027-03-31T14:59:59.000Z
Expires: 2027-03-31T23:59:59+09:00

担当部署の改組やメールアドレスの変更は、自治体では毎年度の人事異動・組織改正で起こり得ます。Expiresは、「少なくとも年に一度は連絡先が正しいか見直す」ことを仕組みとして担保する役割を持ちます。

この項目は、有効なsecurity.txtが公開されている場合に、そのExpiresが将来かつ1年以内の日時になっているかを確認します。security.txt自体の設置は「security.txtを公開」、Expiresの重複やContent-Typeなど形式面は「security.txtのRFC 9116形式」で別に評価します。

Expiresの書式（RFC 3339）とよくある誤り

書式の要点

RFC 9116は、ExpiresをRFC 3339のdate-time形式（Internet Date/Time Format）で書くよう定めています。

• 日付と時刻の区切りは T、末尾はUTCを表す Z または +09:00 のような時差です。
• 2027/03/31 や 令和9年3月31日 は形式違反です。
• 1ファイルに Expires を2回以上書いてはいけません。

形式のよくある誤り

セキュリティAIチェッカーの日時解釈はRFC 3339以外の一部の形式も受け付けるため、上記の一部は期限判定上は ○ になることがあります。しかしRFC 9116に従った形式でないと、ほかの検証ツールで解釈できないおそれがあるため、RFC 3339形式で記載してください。

security.txtの有効期限はなぜ1年未満が推奨なのか

期限が意味するもの

• 期限切れのsecurity.txtは、研究者や自動化ツールに「管理されていない可能性があるファイル」と見なされ、記載の連絡先が使われないことがあります。
• 期限を極端に遠く（例: 10年後）に設定すると、必須要件は満たしていても、見直しの仕組みとして機能しません。RFC 9116が1年未満を推奨しているのはこのためです。

security.txtの有効期限についてよくある誤解

• 「Expiresはファイル自体の削除予定日」：削除の予定ではなく、内容の信頼期限です。期限前に内容を確認し、新しい期限で更新するのが正しい運用です。
• 「年度末に合わせると1年を超えてしまう」：年度当初に更新し、翌年度の同時期（1年未満）を期限にすれば、毎年度の見直しサイクルと一致します。
• 「Expiresがなくてもcontactがあれば十分」：RFC 9116ではExpiresは必須です。

security.txtの有効期限の診断基準（セキュリティAIチェッカー）

前提

「security.txtを公開」と同じ取得結果を用います。/.well-known/security.txt がステータス200で、本文がHTMLではなく、行頭に Contact: があるもの（有効なsecurity.txt）だけを評価対象にします。

取得・解釈

• 行頭（空白可）の Expires: の値を取り出します（大小文字を区別しない、最初の1件）。
• 値を日時として解釈し（JavaScriptの Date.parse）、診断時刻と比較します。RFC 3339形式は確実に解釈できます。解釈できない値は「解釈できない形式」として扱います。

判定条件

× 要改善（fail）はありません。1年の判定にはうるう年を考慮して366日を上限としています。根拠欄には、確認したExpiresの値（先頭60文字）を表示します。

判定の限界

• 診断はその時点の値だけを見ます。たとえば診断日の翌日に期限が切れるファイルも ○ になります。期限の1か月前には更新する運用にしてください。
• Expiresが複数行ある場合は最初の1行だけを評価します。重複やContent-Type等の形式面は「security.txtのRFC 9116形式」で別に評価します。
• OpenPGP署名の有無・正しさは確認しません。署名付きファイルでも、本文中の Expires: 行で評価します。
• 診断サーバーの時刻を基準にするため、期限の直前・直後では数秒から数分の差で結果が変わることがあります。

自治体サイトでの判定例

security.txtの有効期限が切れているとどんなリスクがあるか

• 古い連絡先への報告：組織改正で廃止したアドレスがsecurity.txtに残っていると、報告が誰にも届かない、あるいはエラーで返送され報告者が諦める原因になります。
• 信頼性の低下：期限切れのファイルは「管理されていないサイト」の兆候と受け取られ、報告者の信頼を損ねます。
• ドメイン・アドレスの再利用：使われなくなったドメインのメールアドレスが第三者に取得された場合、報告が第三者に届くおそれがあります。定期的な見直しはこの種の事故の予防にもなります。

いずれも直接の侵害ではなく、脆弱性対応の入口の品質に関わるため、重大度はlowです。

security.txtの有効期限の決め方と更新方法

1. 期限の決め方（年度サイクルに合わせる）

• 年度の業務サイクルに合わせ、毎年4月の組織改正後に内容を確認し、翌年3月末（1年未満）を期限にするのが運用しやすい方法です。
• 期限の1か月前に担当者へ通知が届くよう、庁内のスケジュール管理や監視ツールに登録します。

2. 更新手順

1. Contactの各アドレス・URLが現在も有効で、担当部署が受信できることを確認する。
2. Policy・Encryption等のリンク先が存在することを確認する。
3. Expires を新しい日時（1年未満先、RFC 3339形式）に書き換える。
4. 署名を付けている場合は署名し直す（署名後に本文を変えると検証が失敗します）。
5. 公開後、下記の確認方法で取得できることを確かめる。

日時文字列は、次のコマンドで生成できます。

# GNU date（Linux）: 360日後のUTC日時
date -u -d '+360 days' '+%Y-%m-%dT%H:%M:%SZ'

# PowerShell
(Get-Date).ToUniversalTime().AddDays(360).ToString("yyyy-MM-ddTHH:mm:ssZ")

# Node.js
node -e "console.log(new Date(Date.now()+360*864e5).toISOString())"

3. 自動更新（任意）とNext.jsの例

ファイルを動的に生成できる環境では、期限を自動計算する方法もあります。ただし、内容の見直しを伴わない自動延長は本来の目的（定期的な確認）を損なうため、確認作業とセットで運用します。

Next.js（App Router）の例:

// app/.well-known/security.txt/route.ts
export const dynamic = "force-static";
export function GET() {
  const expires = "2027-03-31T14:59:59.000Z"; // 年度ごとの見直し時に更新
  const body = [
    "Contact: mailto:security@city.example.lg.jp",
    `Expires: ${expires}`,
    "Preferred-Languages: ja, en",
    "Canonical: https://www.city.example.lg.jp/.well-known/security.txt",
  ].join("\n") + "\n";
  return new Response(body, { headers: { "content-type": "text/plain; charset=utf-8" } });
}

Apache・nginx・IISでは静的ファイルとして置き、上記の手順で年1回書き換えるのが最も簡単です。

CMSや静的サイトジェネレーターを使っている場合も、security.txtはCMSの記事ではなくサーバー上の固定ファイルとして管理し、更新履歴（いつ・誰が・何を変えたか）を残しておくと、監査や引継ぎの際に役立ちます。

4. 確認方法

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

表示された日時が、現在より後かつ1年以内であることを確認します。Windowsでは curl.exe を使い、findstr /i "^expires:" で同様に抽出できます。更新後はセキュリティAIチェッカーで再診断し、根拠欄に新しいExpiresの値が表示されることを確かめます。

更新時の注意点（ガードレール）

• Expiresを2行以上書かないでください（RFC違反）。
• タイムゾーンを省略しないでください。2027-03-31T23:59:59 だけでは時差が不明確です。
• OpenPGP署名を付けている場合、Expiresを書き換えたら必ず再署名します。
• CDNやキャッシュを使っている場合、更新後にキャッシュを削除して新しい内容が配信されていることを確認します。

よくある質問（FAQ）

参考資料

• RFC 9116 A File Format to Aid in Security Vulnerability Disclosure
• RFC 3339 Date and Time on the Internet: Timestamps
• securitytxt.org
• OWASP WSTG-INFO-03 Review Webserver Metafiles for Information Leakage

「security.txtの有効期限」と関連する診断項目

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