security.txtチェック

悪い知らせのための玄関

遅かれ早かれ、組織の外の誰かがあなたのサイトの不具合に気づきます。ほかの顧客の注文が見えるページ、忘れられた管理画面、繰り返し使えてしまうパスワード再設定などです。そうした人の多くは、あなたに知らせたいと思っています。難しいのは、誰に知らせればよいかを見つけることです。問い合わせフォームは営業部に届き、サポートのチャットは注文番号を求め、info@には誰も返事をしません。

security.txtファイルは、この1つの問題を解決します。決まったアドレス/.well-known/security.txtに置く数行のプレーンテキストで、報告の送り先と、その情報がいつまで有効かを書きます。この形式は2022年にRFC 9116として公開されました。スキャナー、バグバウンティのプラットフォーム、各国のセキュリティ機関は、伝えたいことがあるときにこのファイルを自動で読みます。

Contact: mailto:security@example.com
Expires: 2027-01-31T00:00:00.000Z
Preferred-Languages: en, de
Canonical: https://example.com/.well-known/security.txt
Policy: https://example.com/security-policy

このチェックが読むもの

当サーバーはhttps://your-host/.well-known/security.txtを要求し、何も返ってこなければ、ルートにある古いアドレス/security.txtを要求します。リダイレクトはたどります。ステータス200の応答でも中身がHTMLのページなら、ファイルなしとみなします。知らないアドレスにはすべてトップページで答えるサイトが多いからです。

ファイルがあれば、3つの点で判定します。

標準にない項目名は、拡張が認められているので、減点せずに一覧にします。テキストがOpenPGPのクリアテキスト署名で包まれているかどうかも表示します。その署名の検証はしません。

よく見かける間違い

期限切れの日付

誰かが一度ファイルを書いて、そのまま忘れたケースです。RFC 9116は期限切れのファイルを使うべきではないとしているので、報告者はまた推測に戻ることになります。更新は2分で済みます：連絡先を確認し、日付を延ばし、公開するだけです。

Expiresがまったくない

2022年より前に書かれたファイルは、この項目が任意だった草案に従っています。今は必須です。

Contact: security@example.com

値はURIでなければなりません。mailto:security@example.comと書いてください。

ルートにしかファイルがない

/security.txtは予備の場所です。ファイルは/.well-known/に置き、古いアドレスからそこへリダイレクトしてください。

ほかのサイトからコピーしたCanonical

この項目があるのに、ファイルを配信しているアドレスが入っていなければ、ファイルは自己矛盾しています。

維持し続けられるファイルを公開する

まず、誰がそのメールボックスを読むかを決めます。特定の個人より、2人に届くsecurity@のような共有アドレスのほうが確実です。次に、このページの作成ツールを使います。必要なところにmailto:を付け、日付を整え、1年後に初期設定します。

できたものを、ウェブのルートにある.well-knownという名前のフォルダーにアップロードします。ほとんどのサーバーは、何も指定しなくても.txtファイルをtext/plainで送ります。ドットで始まるフォルダーを隠す設定になっているなら、例外を加えてください。nginxなら次のとおりです：

location = /.well-known/security.txt {
    default_type text/plain;
    charset utf-8;
}

署名は任意です。GnuPGなら、gpg --clearsign security.txtで署名付きの版ができるので、元のファイルの代わりにそれを公開します。署名がアドレスも対象にするよう、署名する前にCanonicalの行を入れておいてください。